Classification: Perception gap. The portfolio already contains the evidence — zero-to-live product builds, multi-stakeholder enterprise deployment, years of post-engagement product survival. Evaluators hear "BCG Digital Ventures" and file you under consultant before examining any of it.
Confidence level: High, for the reframe below, applied to Thermo Fisher mySupply specifically. The evidence is public, current, and corroborated by the client company's own product documentation.
Selected case: Thermo Fisher mySupply, built as Product Design Director at BCG Digital Ventures. Of your four BCG DV engagements, this one carries the deepest evidence across all three constructs — durability, ownership, and internal navigation — because Thermo Fisher still publicly documents the product using the same architectural logic you designed.
The objection, stated honestly
You will hear some version of this:
"Most of your product work was at BCG Digital Ventures. How is that different from building in-house?"
Peter Merholz described the belief underneath that question in a 2020 conversation with Jesse James Garrett: consulting designers create a concept, hand over a design, and leave — absent for the "thousand little decisions" that determine what actually ships and survives. He moved in-house partly for that reason.
That is the fear. Not that you can't design, but that you left before implementation compromises, post-launch feedback, and operational reality tested your original judgment.
The grain of truth
BCG DV engagements end. You built mySupply over twelve months, shipped it, and transferred it to Thermo Fisher's operating organization. You did not steer it through multi-year growth and iteration cycles. I said this in Issue #6 and it remains true.
Do not minimize this.
"I built and shipped, and then the product transferred to the partner. I didn't run any of them through multi-year growth." Say that, and then show what the twelve months actually contained.
Five and a half years of public operation
The first-turn claim: "The product I built at Thermo Fisher has been publicly operational for five and a half years. Their current product documentation still describes the same modular architecture I designed — orders, batches, forecasts, dashboards, exception routing."
Thermo Fisher's Patheon division currently markets mySupply as an end-to-end digital supply-chain platform. Their product documentation describes order management, batch tracking, forecasting, alerts, change requests, and dashboards — the same module families your case describes. A February 2021 fact sheet and the current product page use the same attention-routing premise: surface where action is needed rather than present a flat list.
The product has been publicly operational for approximately five and a half years since your engagement ended.
"But how do you know the product you built is still what's running? They could have rebuilt it twice."
"I can't speak to every interface change since 2021. What I can point to is that their current product documentation still describes the same modular architecture — orders, batches, forecasts, dashboards, alerts — and the same operating premise: route attention to exceptions rather than make users scan everything. That architecture was a design decision I made based on field research across nine manufacturing sites. If they had rebuilt the conceptual model, the product description would read differently."
You are claiming the architecture, not every pixel. The documentation corroborates architectural continuity, not feature-level preservation. Stay on that line.
Decisions that changed how six companies coordinate
The first-turn claim: "Two of the decisions I made changed how six pharmaceutical companies and nine manufacturing sites coordinate daily operations. Both are still structuring that coordination five and a half years later."
Your case describes 32 interviews that identified five operating failures, which you converted into five product modules. Two decisions matter most because they changed how the organization worked, not what the interface looked like.
Exception-first order management. Six pharma partners generated roughly 197 concurrent orders across nine manufacturing sites. The previous workflow treated every order equally. You made the default view surface only orders requiring action — delays, risks, deviations. That changed the working unit from "all orders" to "the twelve that need intervention today." Thermo Fisher's current documentation still describes the platform as highlighting where attention is most needed and exposing order risks.
Structured forecasting with approval state. Forecasts previously moved between Thermo Fisher and partners as emailed spreadsheets with filename-based version control. You replaced that with structured submission, explicit approval states, and automated SAP loading on approval. Once the approval-triggers-loading chain was live, reverting to email meant disconnecting the ERP integration.
These are operating decisions embedded in how six pharmaceutical companies and nine manufacturing sites coordinate production. They carry switching costs because they changed workflows, data flows, and approval chains — not because the interface was pretty.
"But couldn't the client just reverse those decisions after you left?"
"Technically, yes. But the exception-first model changed how operations teams across six partners structured their daily work — which orders to look at, when to escalate, what 'normal' meant. The forecast workflow replaced email attachments with approval-gated SAP loading. Reversing those means retraining operations staff across nine sites and disconnecting an ERP integration. Five and a half years of continued operation tells you the decisions were consequential enough that undoing them would cost more than living with them."
Operating inside someone else's organization
The first-turn claim: "I operated inside a stakeholder environment with six external pharmaceutical companies, nine manufacturing sites across three continents, and competing performance definitions — with no positional authority and a twelve-month window."
The product served six pharmaceutical companies — each with its own performance definitions, delivery expectations, and data sensitivity — and nine Thermo Fisher manufacturing sites across Europe, North America, and Australia. The underlying information lived in SAP, laboratory information management systems, manufacturing execution systems, spreadsheets, PDFs, email, and phone calls.
The core design problem was bilateral. Thermo Fisher needed to expose enough internal manufacturing state for partners to plan drug launches. Partners needed early visibility without receiving operational detail they couldn't act on. You designed a permission model where Thermo Fisher got an all-partner view and each partner saw only its own product and performance data. That is a governance decision — it determined what each organization could see about the other's operations, and getting it wrong in either direction would have killed adoption.
Then there's the performance dashboard. You put Thermo Fisher's internal delivery metrics next to each partner's definition of on-time delivery — side by side, in the same review surface. When those numbers disagreed, the disagreement became visible during quarterly strategic reviews. That forced a conversation the organization had been avoiding. When you build something that makes previously hidden disagreements visible to both parties in a room, you are making a choice about organizational politics, and you own the consequences of that choice for the duration of the engagement.
"How is navigating a client's org the same as navigating your own company's org? You could leave. An internal leader can't."
"The constraint is actually tighter. I had twelve months, a three-person delivery team, and no positional authority inside Thermo Fisher's organization. I couldn't escalate to my VP. I couldn't wait for the next reorg. I couldn't defer a hard stakeholder conversation to next quarter. Every decision about what to expose, what to restrict, how to handle conflicting performance definitions across six partners — those had to be resolved within the engagement window, with people who didn't report to me, inside an organization I didn't belong to."
What you should not claim
- Do not claim that the current product is unchanged from your version. The evidence supports architectural continuity, not feature-level preservation.
- Do not claim specific business outcomes (margin recovery, internal rate of return) unless asked. If asked, attribute them as results reported during the engagement period, not ongoing metrics you tracked. Issue #6 established this boundary: claim the mechanism, attribute the metric.
- Do not name the six pharmaceutical partners. Your portfolio doesn't name them, and claiming knowledge you can't source will invite a follow-up you can't answer.
- Do not extend the mySupply argument to cover your other three BCG DV projects unless asked about them specifically. One deep case is more persuasive than four shallow ones. If a second example is requested, per Issue #7, respond with a different evidence type — a decision rather than another duration claim — to avoid sounding rehearsed.
The position
You built a product under constraints most in-house designers never encounter in their first two years: six external organizations with competing interests, nine manufacturing sites across three continents, no positional authority, a fixed window, a three-person team. The architectural decisions you made are still structuring how a global pharmaceutical supply chain operates five and a half years later. Lead with that.
- RC Care identity gap: Your Red Cross disaster-relief platform shares features, timing, and Salesforce architecture with the currently active RC Care system, but no public source connects your name or BCG Digital Ventures to that product name — worth resolving before claiming it as a second durability example.
- Alle chronology conflict: Your case page says both "Shipped 2020" and relaunched as Alle in 2021, while external trade coverage places beta testing and provider onboarding in early 2020 — a small inconsistency an attentive evaluator could notice.
- The "thousand little decisions" source: Merholz's full conversation with Garrett in Consultancy Rat Blues is worth reading because he also describes what makes consulting backgrounds legible to in-house hiring managers — shipped products and continuing agency-of-record relationships that show a stream of released work.
- Second-turn preparation from hiring managers: Vlad Margulis's practitioner essay on agency-to-product transitions names the specific evidence product-design hiring managers look for — user understanding, metrics fluency, rapid iteration, and multiple shipped products — and is useful for anticipating what a second probe after your mySupply answer might target.