Production-Code History Either Exists or It Doesn't

The fact

You have not authored production code in a professional engineering capacity. You don't have an engineering title, a commit history in a shipping codebase, or deployment ownership as an engineer.

You've built live applications and shipped products alongside engineering teams at BCG Digital Ventures. You have real technical fluency and real prototyping capability. None of that is production-code authorship, and any evaluator who knows the difference will notice if you treat it as equivalent.

This is a history problem, and no artifact or reframe changes that.

A fifth category

Issue #8 established four objection types: perception gap, evidence gap, experience gap, fit boundary. Production-code authorship breaks all four. A perception gap means the evaluator misread something you did — a reframe fixes it. An evidence gap means you did the work but haven't shown it — an artifact fixes it. An experience gap means you haven't done the thing but could build toward it. A fit boundary means the role requires something structural that doesn't match.

A qualification boundary is different. It is a factual credential. You either have it or you don't, and no reframe, artifact, or weekend project creates the missing history.

Three moves remain: confirm the requirement doesn't actually apply, address the real concern when the stated requirement is proxy for something else, or exit before you waste time on both sides.

The reason this distinction matters operationally: if you misclassify a qualification boundary as an evidence gap, you will spend days building artifacts that cannot answer the question being asked. If you misclassify it as a perception gap, you will try to reframe your way through an interview and sound evasive to someone who asked a factual question. Both outcomes are worse than walking away.

The diagnostic question

Most postings that mention code are not asking whether you've shipped production software. Issue #9 separated three things that hide behind the word "code" in design-role postings: maker capability, technical fluency, and system-level judgment. You have evidence for all three.

The fourth thing — a professional history of writing and shipping production code — is what you need to surface early. In outreach, on a screening call, in the first ten minutes.

"Can you help me understand — does this role include writing production code as part of the regular work, or is the technical expectation more about prototyping fluency and engineering collaboration?"

Ask it directly. This is not positioning. It is a question that saves both sides time. A recruiter who hears this will either clarify that they want code-adjacent fluency (you have a conversation to continue) or confirm that the role's deliverables include production software (you have your answer).

If the response is vague — "we want someone technical," "you'd work closely with engineers" — that vagueness is informative. It usually means the requirement is soft. A role that genuinely requires production-code history will specify: languages, frameworks, deployment ownership, code review participation. Specificity is the signal. When the response stays vague, proceed into the proxy response below. You are almost certainly being screened for technical fluency or engineering credibility, not for a codebase you've committed to.

When it's a hard filter

Exit. Cleanly, quickly, preserving the relationship.

"Thanks for the clarity. That's not my background — I've led technical product work and I build functional prototypes, but I haven't held a production engineering role. I don't want to waste your time on a mismatch. If you're ever hiring for a design leadership role where the technical bar is deep collaboration and prototyping rather than code ownership, I'd be glad to talk."

Candidates who self-select out with this kind of clarity get remembered and called back when the next role opens.

When it's a proxy

When the diagnostic question reveals that "technical background" or "shipped code" is shorthand for engineering credibility, comfort with constraints, or the ability to make design decisions inside a deeply technical product — you have real evidence. Use it precisely, matched to the construct they're actually screening for.

Engineering credibility and technical collaboration. Your BCG Digital Ventures delivery work (attributed as Product Design Director at BCG DV) involved shipping products with engineering teams under real constraints. Name the constraint, name the decision you made because of it, name the outcome. API limitations, data architecture, system behavior — these are the specifics that answer the credibility question. The prototyping fluency and interaction judgment dossiers carry your strongest project-level examples; pull from those before a conversation where this construct is likely.

Hands-on building capability. Your Agentic Labs are live, functioning applications you built yourself. They show you can make things that work, not things that look right in a deck. The boundary to hold: these demonstrate maker capability, not production-engineering history. Do not overextend the claim.

AI systems judgment. Your TinyFish work (past tense, always) involved production AI systems — traces, auditability, attribution, governance. This is evidence of operating judgment in technical environments. It is not evidence of code authorship. Keep that line clean.

Match one proof carrier to the construct they're evaluating. If they're screening for engineering collaboration fluency and you start describing your Agentic Labs architecture, you've drifted into answering a question they didn't ask. Worse, you've moved toward the boundary where they might wonder whether you're implying production-code experience you don't have.

Where this shows up in your current pipeline

The reliable predictor is the role's work product, not the company's name or tier. When the designer's deliverable is software — code, evaluation infrastructure, internal tools for technical users — production-code history is a hard requirement. When the deliverable is design decisions, systems, and strategy that engineers implement, it is not. Render is a useful proof: a developer-infrastructure company building agent experiences for engineers, yet its Staff Product Designer posting asks for comfort reading and prototyping with code, not for prior production-code ownership.

You cannot write off an entire company based on one posting.

Hard boundary — the requirement is explicit:

• OpenAI, Product Designer, Codex: "Bring a strong technical background and have recently shipped code to production."
• Anthropic, Product Designer, Evals & Prompts: Minimum qualifications include "production-quality Python" and experience building evaluation pipelines, internal tools, and test harnesses.

Both roles produce software as their primary deliverable. The requirement is structural.

Diagnostic question needed — code-adjacent language, unclear threshold:

• Headway, Senior/Staff Product Designer, Provider: Designers use Claude Code and Cursor to prototype and ship improvements to the codebase. No prior production-code employment stated, but the language is close enough to ask.
• Capital One, Director, Product Design: Prefers familiarity with Claude Code, Windsurf, and related tools. Basic qualification is design experience, not engineering history.
• OpenAI, Product Design Lead, Growth–Codex: Expects fluency using AI tools to extend what you can build. Does not state the production-code requirement found in the other Codex role. Same company, different screen.

No production-code language in the posting:

Handshake, Vanta, Nubank, ServiceNow. These roles center design judgment, leadership, systems thinking, and AI collaboration. Absence of the requirement doesn't guarantee no interviewer will ask, but it establishes the company didn't consider it an entry filter.

Pre-conversation reference

Before any outreach or screening call, answer one question: Does this role's work product include production software?

Yes (the designer writes code that ships to users) → Qualification boundary. Ask the diagnostic question to confirm. If confirmed, use the exit line. Do not attempt to reframe.

Unclear (the posting mentions code in the context of prototyping, tools, or collaboration) → Ask the diagnostic question. Prepare both the exit and the proxy response. Let their answer determine which you use.

No (the posting describes design leadership, product strategy, systems thinking, or craft) → The boundary is unlikely to surface. If a coding question comes up in conversation, it is almost certainly screening for technical fluency or engineering credibility, both of which you can address directly.

The diagnostic question: "Can you help me understand — does this role include writing production code as part of the regular work, or is the technical expectation more about prototyping fluency and engineering collaboration?"

The exit: "That's not my background. I've led technical product work and I build functional prototypes, but I haven't held a production engineering role. If you're ever hiring for a role where the technical bar is collaboration and prototyping rather than code ownership, I'd be glad to talk."

The proxy response: Match your evidence to the construct they're actually screening for. Engineering credibility → BCG DV delivery work. Maker capability → Agentic Labs. AI systems judgment → TinyFish work, past tense. One construct, one proof carrier.