The consulting objection is two different objections that happen to share a trigger word. They form at different stages, they test different things, and they require different responses.
Form 1 — "BCG means slide decks, not shipped products." Forms at resume scan. Perception gap. You have the evidence. The fix is attribution discipline applied consistently before anyone asks.
Form 2 — "She hasn't owned one product inside a company for multiple years." Forms at interview stage. Sometimes a perception gap you can reframe. Sometimes a real boundary on fit. The work here is detecting which one you're facing before you commit to an answer.
Form 1 is mechanical. Form 2 is where candidacies are won or lost, so spend your preparation time accordingly.
Form 1 — "BCG means slide decks"
Classification: Perception gap. Confidence in reframe: High.
The grain of truth. Most people who have encountered BCG encountered strategists delivering recommendations. The assumption that your role was the same is wrong, but it's reasonable pattern recognition from someone scanning forty résumés.
BCG Digital Ventures was an embedded venture-building operation. You were not advising a client on what to build. You were building it — standups, engineering collaboration, shipped product. Issue #6 established the defensible claim: build ownership through launch, with the transfer boundary stated honestly. Four products shipped and reached the adoption outcomes documented in your portfolio.
One move, applied everywhere, prevents this form from reaching a conversation: use "Product Design Director at BCG Digital Ventures" as your attribution every time your BCG DV work appears. Outreach, résumé, portfolio case headers, LinkedIn messages. "Ventures" and "Director" both do real work in that string. "BCG" alone triggers the strategy assumption before you get a conversation.
Three specifics:
- In portfolio case introductions, lead with the product and the outcome. "Thermo Fisher mySupply — a 12-month zero-to-live build across six pharmaceutical partners and nine sites" is a product sentence. "A project I did for Thermo Fisher while at BCG" is a strategy sentence. Same work, but only one survives the slide-deck filter.
- In verbal introductions, use build verbs. "Built," "shipped," "launched." Not "consulted on," not "advised." The verbs carry the frame.
- In outreach copy, never abbreviate to "BCG." If a recruiter's first encounter with your background is the three letters B-C-G without "Digital Ventures," the perception gap forms before you exist as a candidate.
This form rarely survives first contact when the attribution is consistent. If it does surface — "So you were at BCG, that's more strategy work, right?" — correct briefly and move to something else:
"BCG Digital Ventures was the venture-building arm. Embedded product teams, not strategy engagements. I was Product Design Director. We built and shipped products — four shipped products, each with documented adoption."
Then stop. The longer you spend on this correction, the more it sounds like you're managing a real problem rather than clearing up a naming confusion.
Form 2 — "She hasn't owned one product for multiple years"
Classification: Depends on the role. Confidence in reframe: Varies — read below.
The grain of truth. Your BCG DV engagements were time-bounded builds. Twelve months for mySupply. Six months for the Red Cross platform. Three months to Equinox+ MVP. Those are build-and-launch intervals. They are not proof that you operated a product through subsequent annual planning cycles, accumulated design debt, retention optimization, or multi-year roadmap evolution. Issue #6 made this concession explicitly: build versus advisory, you win outright; build versus operate, part of this you lose.
That concession stands. The question is whether it matters for the role in front of you, and you can tell, if you listen for the right cues.
How to detect which scenario you're in
The interviewer's probe pattern will tell you. Two distinct patterns, distinguished mainly by temporal language.
Stewardship probes ask about what happened after shipping:
- "Take me past launch. What happened over the next several releases?"
- "Tell me about a product you inherited. What existing decisions did you preserve or unwind?"
- "How did the product strategy change across successive planning cycles?"
- "What did you learn in the second year that you couldn't have learned in the first?"
- "Describe a decision that looked right at launch but proved wrong in production over time."
Listen for time horizons beyond launch: "next releases," "successive cycles," "year two," "over time." The interviewer is testing for pattern recognition that only comes from living with a product long enough to see your own decisions age.
0→1 probes concentrate on decision quality before and through launch:
- "Walk me through a product you took from an undefined problem to first release."
- "Describe a consequential decision you made before you had complete information."
- "Tell me about a launch where constraints forced a scope choice. What did you cut?"
- "How did you align design, product, and engineering when no established playbook existed?"
Here the keywords cluster around ambiguity, constraint, speed, and the absence of precedent. The interviewer wants evidence that you can build from nothing under pressure.
Watch for ambiguous language. "End-to-end," "ownership," and "product impact" do not by themselves tell you which construct is being tested. If you hear those words without the temporal cues above, ask directly: "When you say ownership, are you asking about repeated zero-to-one builds or about operating the same product through multiple post-launch cycles?" That question is precise without being defensive. It signals that you understand a distinction most candidates at this level don't articulate.
In panel interviews, you may hear both patterns from different evaluators — stewardship probes from the hiring manager, 0→1 probes from a product partner. That's two people testing two different things, not ambiguity to resolve into a single diagnosis. Respond to each evaluator's actual probe pattern. If the stewardship probes come from the person with hiring authority, weight your preparation toward Response Path B regardless of what the other panelists asked.
Response path A: The role values repeated 0→1
Confidence in reframe: High.
When the probe pattern signals 0→1 evaluation, your BCG DV history is a direct strength. You built four products from zero to live, each in a different industry context, with a different corporate partner, a different technical stack, and a compressed delivery window. That is a higher density of founding-phase product decisions than most in-house designers accumulate in a decade.
The venture model produced that density by design. You weren't at one company long enough to shift from building to maintaining — you were rotating through founding-phase builds where every engagement required standing up a product organization's worth of decisions under a hard deadline. A single-company designer who built one product over four years made founding-phase decisions once. You made them four times, each time with different domain constraints.
Lead with the constraint, not the count:
"I've built four products from zero to launch, each in a different domain, each with a founding-phase team and a hard delivery window. The Red Cross platform went from nothing to national deployment in six months. Equinox+ reached MVP in three months. That pace forces a specific kind of decision-making — you scope aggressively, you test before you're comfortable, and you build transfer-ready systems because the team that operates the product after you isn't the team that built it."
That last clause — transfer-ready systems — preempts the follow-up about what happened after launch without pretending you stayed. You designed for handoff. That's a real capability, and framing it this way lets you own it rather than apologize around it.
At TinyFish, you were Head of Product and took an agentic platform from concept to functional product in three months. That bridges the BCG DV narrative into a context where you weren't building inside a corporate-venture structure but inside a startup with no established design function. Use it for the bridge, not as portfolio proof.
Response path B: The role genuinely requires multi-year stewardship
Confidence in reframe: Use with caution. This may be a fit boundary.
When stewardship probes dominate — repeated questions about post-launch evolution, inherited decisions, year-two learning, accumulated debt — you are being evaluated on a capability your operating history does not directly demonstrate. The BCG DV model embedded you in ventures during the founding and build phase. A separate function built the permanent teams that owned ventures after graduation.
You can offer adjacent evidence. You designed systems intended to survive your departure. You structured documentation and design-system foundations for teams you wouldn't lead. You made decisions whose consequences would unfold on someone else's watch and thought carefully about that transfer. That evidence is real and defensible.
What you should not do is stretch it into a claim of multi-year product stewardship. The interviewer asking about year two is asking because year two taught them something they believe is essential. If you haven't had that experience, say so:
"I built and shipped those products, but I transferred them. I didn't operate them through multi-year growth. If this role's core need is someone who's lived with a product long enough to see their own decisions compound, that's a different operating history than mine. What I bring is repeated founding-phase ownership under hard constraints. Whether that's what you need depends on what problem you're actually hiring for."
That answer states the boundary without apology, names what you do bring, and puts the evaluation question where it belongs — on whether the role's actual need matches your actual history.
Ending the wrong candidacy early is a better outcome than spending two years in a role that needed a different profile. Issue #10 covered this exit condition in detail. If stewardship probes dominate the interview, treat that as diagnostic information about the role, not as a test you're failing.
Where the current targets land
Among your active targets, none explicitly requires multi-year single-product tenure in their posted qualifications.
OpenAI's Codex designer posting says "much of the work is 0→1." Anthropic's Safeguards role accepts execution on "a series of products." Ramp prefers founder or early-stage experience. Your operating history is structurally aligned with what these postings describe.
Two roles worth flagging separately:
Vanta's Head of Design requires five-plus years scaling a large design organization. That's an org-stewardship signal, not a product-stewardship signal — a different objection, which Issue #8 addressed.
Anthropic's Evals & Prompts role requires maintaining evaluation pipelines across model launches. That's closer to sustained technical-system operation than the other postings, though it's a specialized construct rather than a general tenure requirement.
For the rest of the set — OpenAI Growth, OpenAI Engineering Acceleration, TRM Labs — the Form 2 objection is most likely to surface as a private interviewer concern, not a posted gate. Listen for the probe pattern. Respond to what you hear, not to what you're afraid they're thinking.
Pre-interview reference
Scan this before the conversation. Three things to find: what you're hearing, what to say, what to ask when you can't tell.
Detection cues
You're facing stewardship probes if you hear: "past launch," "next releases," "successive cycles," "year two," "inherited," "over time," "what changed," "debt," "deprecation," "retention." The interviewer wants evidence of living with a product long enough to see your own decisions age.
You're facing 0→1 probes if you hear: "from scratch," "first release," "undefined problem," "incomplete information," "what did you cut," "no playbook," "early team," "concept to launch." The interviewer wants evidence of building under ambiguity and constraint.
Mixed panel: Different evaluators may test different constructs in the same loop. Respond to each person's actual probe pattern. Weight your preparation toward whichever pattern comes from the person with hiring authority.
Response language
Path A — role values 0→1 (high confidence):
"I've built four products from zero to launch, each in a different domain, each with a founding-phase team and a hard delivery window. The Red Cross platform went from nothing to national deployment in six months. Equinox+ reached MVP in three months. That pace forces a specific kind of decision-making — you scope aggressively, you test before you're comfortable, and you build transfer-ready systems because the team that operates the product after you isn't the team that built it."
Path B — role requires multi-year stewardship (use with caution — may be a fit boundary):
"I built and shipped those products, but I transferred them. I didn't operate them through multi-year growth. If this role's core need is someone who's lived with a product long enough to see their own decisions compound, that's a different operating history than mine. What I bring is repeated founding-phase ownership under hard constraints. Whether that's what you need depends on what problem you're actually hiring for."
Clarifying question for ambiguous signals
When you hear "end-to-end," "ownership," or "product impact" without clear temporal cues:
"When you say ownership, are you asking about repeated zero-to-one builds or about operating the same product through multiple post-launch cycles?"
- BCG DV venture transfers: The Talent Architect cohort description distinguishes the build team from the permanent founding team recruited to own ventures after graduation, which means your exact post-launch involvement on each case may need case-specific confirmation before an interviewer asks.
- Stewardship language in postings: OpenAI's Engineering Acceleration role asks for the full instrument-launch-observe-evaluate-iterate loop, which is the closest any current target comes to sustained post-launch operating language without explicitly requiring multi-year tenure.
- GitLab's published evaluation model: Their product-designer hiring handbook distinguishes stage-aligned roles with sustained domain depth from project roles centered on ambiguity and cross-team influence, a structural distinction worth studying before any interview where you can't tell which construct is being tested.
- Anthropic's "series of products" language: The Safeguards posting explicitly accepts execution on "a series of products" as equivalent to one large complex product, which is the strongest current posted signal that repeated 0→1 builds are a recognized alternative to single-product tenure.
