Most requirements in a design-leadership posting exist because something went wrong. Someone on the hiring committee watched a failure — or heard about one — and added a line to prevent recurrence.
Your job is to classify what kind of line you're reading. The positioning move depends entirely on the answer. Misclassify a preference as a gate and you walk away from a role you should pursue. Misclassify a gate as a preference and you spend hours narrativing around a hard stop — the committee will spot the stretch. Both cost time you don't have.
Three categories. Every requirement you encounter falls into one.
Gate
A binary eligibility check. You clear it or you don't. Framing cannot substitute for the thing itself. Adjacent experience does not satisfy a gate. Attempting to position around one signals you don't understand the role.
Recognition cue: the requirement describes a specific, testable capability that the role's daily deliverables depend on. Remove this capability and the job cannot be performed.
Preference
Something the company wants and will evaluate positively, but will accept adjacent or analogous evidence for. At Director+ level, most requirements are preferences, because rigid filtering at this seniority eliminates the entire candidate pool. The company knows this.
Recognition cue: the requirement describes an experience domain rather than a specific skill. The posting includes softening language ("not all candidates will meet every qualification"). The role could be performed by someone with adjacent experience, even with ramp-up time.
Proxy
Language that encodes an organizational problem or past failure rather than a literal skill need. Proxies are the most valuable requirements to identify because they tell you what the company is actually solving for — and who on the committee is worried about what.
Recognition cue: the language feels off for the level or role type. A VP posting emphasizing "hands-on" work. A design-leadership role specifying "shipped code to production." A director posting that says "player-coach." These phrases describe what the last person didn't do, or what the committee fears the next person won't.
The diagnostic
For every requirement: what failure caused this line to appear?
If the answer is "we need someone who can literally do this task every day," it's a gate. If the answer is "we'd prefer someone who has done this, but we'd accept proof they could," it's a preference. If the answer is "something went wrong and this language is supposed to prevent it from happening again," it's a proxy.
The posting's own labels are unreliable. "Minimum qualifications" sections regularly contain preferences. "Preferred" sections occasionally contain operative gates. Classification depends on what the requirement actually does in the evaluation, not where it sits on the page.
As I covered in Issue #11, what a company fears predicts what they screen for. This piece applies that logic at the individual-requirement level, where the gap between label and function gets wider.
Worked examples
Anthropic, Product Designer, Evals & Prompts — a gate
The Anthropic posting lists "Production-quality Python" under minimum qualifications. The role involves building graders, maintaining an eval harness across models, sandboxing tool calls, and distinguishing model regression from harness failure.
Classification: Gate. High confidence. This is not proxy language for "be technical." The role's daily output requires writing and maintaining Python that runs in production. The posting specifies experience with "test harnesses, sandboxing tool calls, and pinning the settings that make runs comparable."
The move: Skip. Juno, your published portfolio shows strong engineering collaboration and implementation-aware design, but no authored production code, no public repositories, no named coding tools. This is a qualification boundary, as I noted in Issue #6. Reframing systems-design experience as a substitute for production Python reads as a misunderstanding of what this role is. Time saved here goes to better-matched roles.
Adobe, Staff Product Designer, AI Foundation — honest labeling
Adobe's posting is unusually transparent. Enterprise software experience is "strongly preferred." Prototyping fluency is "a valued skill" but "not the primary measure of design ability." Accessibility experience sits in a separate preferred section.
Classification: Preference. High confidence — Adobe told you. The role spans design-time tools for configuring agentic systems and runtime surfaces used by customers. The posting warns that insufficient UX-architecture skill "can create a bottleneck" in horizontal, cross-product work. That warning is the real requirement.
The move: Adobe is enterprise. Case studies lead, not forward-looking artifacts. The Thermo Fisher and Red Cross work at BCG Digital Ventures — operational modules, design-system architecture, multi-surface coherence — maps to what Adobe describes as the primary capability. Prototyping fluency is worth mentioning but not leading with. Adobe already told you it's secondary.
Render, Staff Product Designer, Agent Experience — split levels
Render's posting places "Comfort near code — you can read it, prototype with it, and collaborate with engineers without a translation layer in between" in core qualifications. Specific technical domains — CLI, SDK, API, MCP, OAuth, coding agents, front-end engineering — all sit in nice-to-haves.
Classification: Preference. Moderate confidence. The failure this encodes is handoff latency. Previous designers (or designers Render observed elsewhere) needed engineers to mediate every conversation about API ergonomics or agent-facing surfaces, and that slowed the work down. Render wants someone who can work across GUI and non-GUI interfaces without a translator.
The move: The Alibaba cross-surface work and Thermo Fisher operational modules at BCG DV demonstrate designing across interface boundaries with engineering teams. Agentic Labs demonstrates direct building. Neither is CLI or SDK experience, but Render already told you specific technical-domain experience is optional. What they need is proof you won't create a translation layer. Show that.
Ramp, Director of Product Design — reading the proxy
The Ramp posting describes a leader who enters the details to unblock and teach, ships alongside Product and Engineering, and begins by owning one product area and team. Technical implementation comfort sits in nice-to-haves.
Classification: Proxy. High confidence. The failure this language encodes: Ramp has seen (or fears) design directors who manage from altitude — who run the org chart but don't touch the work, who can't unblock a team because they haven't looked at the file.
Who wrote this and why: This language almost certainly came from the VP of Product or the CEO — someone who managed or observed the previous design leader and watched what happened when that person stopped looking at the work. At a growth-stage fintech shipping at Ramp's velocity, a director who operates only through process and delegation creates a specific failure: teams wait for unblocking that never comes because the leader can't evaluate the work at the resolution required to make a call. The person who wrote "enters the details to teach" watched that dynamic play out. That person isn't listing a skill — they're describing what was missing.
The move: In outreach or a screen, name the problem. Something like: "I noticed the posting emphasizes entering the details and shipping alongside the team — I'd want to understand what the previous design leader's relationship to the work looked like, because in my experience that language signals something specific about what the org needs next." That question demonstrates you've read the proxy, not the surface. It tells the hiring manager you understand what they're solving for before they've had to explain it.
Juno, your BCG DV portfolio shows direct design contribution on shipped products while leading teams and managing cross-functional relationships. And your work at TinyFish — where you were simultaneously the strategic leader and the practitioner closest to the work — is the conversational proof that you don't default to altitude. Lead with the BCG DV evidence in the portfolio. Use TinyFish in conversation, past tense, to demonstrate the pattern: you lead and you make, and you don't treat those as separate modes.
Maven Clinic, Senior Staff Product Designer, Care Delivery — the hard classification
Maven's posting includes: "You've shipped code to production and can have an informed conversation about backend architecture, model behavior, and system constraints."
Read quickly, this looks like a gate — shipped code to production, binary check.
Classification: Proxy. Moderate confidence. Look at what surrounds it. The role involves defining how AI communicates uncertainty, when it defers to human care, how confidence indicators and human-AI handoffs become reusable design-system patterns. "Shipped code" sits alongside "working AI-assisted prototypes," "strategic ownership," and "cross-functional leadership." Maven's closing language explicitly invites candidates who don't cover every listed area to explain how their background is additive.
Who put "shipped code to production" in a design posting? Someone from the engineering or clinical-product side of Maven's hiring committee — someone who has lived with the cost of a designer who can't keep pace with conversations about model confidence thresholds in care delivery, where latency in design decisions about AI uncertainty has patient-safety implications. That line wasn't written by a design manager describing the craft. It was written by a technical collaborator describing the speed they need.
The move: Lead with the Trust essay's framework on AI uncertainty and human-AI decision boundaries, which addresses Maven's stated design problems in their own language. Agentic Labs demonstrates direct AI-product building. Be honest that your code contribution history isn't publicly documented. Frame the conversation around the capability Maven actually needs: designing AI behavior in close proximity to technical constraints, at the speed of the technical conversation.
One caveat. If Maven's interview loop includes a live coding exercise or code-review assessment, the requirement is functioning as a gate regardless of the posting language. The recruiter screen is where you verify. Ask about first-quarter priorities and listen for whether "shipped code" appears as a daily task or an organizational aspiration.
OpenAI, Product Design Lead, Growth-Codex — proxy with an escape clause
OpenAI's posting uses both "hands-on" and "player-coach" explicitly. It describes "a mix of team leadership and hands-on design execution" for a team of roughly two to five or more designers.
Classification: Proxy with a preference escape. High confidence. The player-coach language encodes a team-size reality: at two to five designers, a pure manager is overhead. But OpenAI also writes that direct experience in growth design, developer products, or people management is "welcome but not required" — and accepts either prior management or "senior-design leadership demonstrated through mentorship, complex initiatives, and team-level impact."
That escape clause is rare. OpenAI is telling you the player-coach requirement is a preference. They'll accept evidence of leading through influence and direct contribution even without a formal management title.
The move: Lead with evidence of direct design contribution on complex, multi-surface products while simultaneously leading teams or initiatives. The BCG DV portfolio shows this pattern. Agentic Labs shows hands-on AI-product building. OpenAI's own language gives you permission to position this way.
Identical words, different classifications
"Shipped code to production" is a gate at Anthropic and a proxy at Maven. At Anthropic, the role's daily output is code. The designer writes and maintains Python that runs in production eval pipelines. Remove the coding capability and there is no role. At Maven, the role's daily output is design decisions about AI behavior in care delivery. "Shipped code" is Maven's way of screening for designers who can participate in technical conversations about model behavior without needing translation. The code isn't the point; the fluency it implies is.
"Hands-on" is a proxy at OpenAI and a preference at Render (where it appears only in a nice-to-have concerning coding agents or LLM-driven tooling). The company type changes what the word means. At a growth-stage company shipping at high velocity, "hands-on" encodes a fear about leadership altitude: the previous design leader managed through process — ran critiques, set direction, approved work — but couldn't evaluate a specific interaction at the resolution needed to unblock a team before a release. At an infrastructure platform, "hands-on" more often encodes handoff latency: design specifications that engineering couldn't implement without extensive back-and-forth because the designer never worked close enough to the build. The word is the same, but the organizational problem behind it isn't.
"Enterprise experience" is a preference at Adobe (they said so) and could function as a gate at a company where the entire product surface is enterprise workflow and every design decision requires domain knowledge you can't acquire in the first quarter.
The same requirement at two different companies encodes two different problems. Name the failure the requirement is protecting against, and you stop matching a checklist.
Running the diagnostic
Before you apply or respond to a recruiter, classify every stated requirement. Gate, preference, or proxy. What failure caused this line to appear.
For gates you don't clear: walk away. The time you save goes to better-matched roles.
For preferences: identify the adjacent evidence from your portfolio that satisfies the underlying need. You don't need an exact match. You need proof the capability transfers.
For proxies: figure out who on the hiring committee wrote that line and what they were reacting to. Name the organizational problem in your outreach or your first conversation. Most candidates read proxies as literal requirements and either self-disqualify or build the wrong evidence. The candidate who says "I noticed the posting emphasizes X — I'd want to understand what that looked like with the previous leader" is working with different information.
Your classification is a hypothesis until the recruiter screen confirms it. Ask about first-quarter priorities. Listen for whether the requirement shows up as a daily task or an organizational aspiration. Daily task: gate. Organizational aspiration: proxy. That distinction tells you how to position for every conversation that follows.
- Anthropic's application essay: Anthropic says its "Why Anthropic?" response is valued highly and suggests 200-400 words, which means mission and motivation function as a screening gate before any portfolio review begins.
- Atlassian's published interview structure: Their design interview handbook separates Product Thinking from Craft Excellence into distinct sessions and adds a Product-Engineering-Design triad at senior levels, which tells you how the company distributes evaluative authority across functions.
- McKinsey on org structure: A study of roughly three million designers across more than 100,000 departments found no single reporting structure associated with stronger design-team integration, which means a CDO title or a direct-to-CEO line in a posting is not proof of operative design authority.
- Maven's dual mandate split: Maven is simultaneously hiring a consumer growth lead and the care-delivery Staff role analyzed above, and the two postings encode materially different feared failures — one about activation and retention, the other about AI uncertainty in clinical decisions.