Fix These Three Things First
1. The full case and teaser contradict each other on facts.
The most dangerous one is partner visibility. The full case says each partner sees only its own data; Thermo Fisher sees all partners. The teaser says all six pharma partners could see one another's delivery performance. These are different system architectures. An interviewer who opens the teaser during your walkthrough catches this in seconds, and the question it raises is whether you remember what you built. Pick the accurate version. Update the other.
The remaining discrepancies are lower risk but they compound: financial language ("margin recovered annually" vs. "margin opportunity"), adoption claims ("committed" vs. "100% adoption"), capacity horizon (18 months vs. 11 months vs. 6 months), platform URL (mysupply.thermofisher.com vs. mysupply.patheon.com). Once an interviewer finds one factual conflict, they go looking for more. Make every factual claim match across both surfaces before you present either one.
2. Draw the attribution boundary on the $20M margin claim. The full case puts "$20M+ margin recovered annually" on an outcome card next to your name with no baseline, causal model, or attribution scope. The teaser softens it to "margin opportunity," which is a different claim. Neither version tells the reader what your design work contributed versus what the commercial team, implementation team, pricing decisions, or market timing contributed. You designed the coordination layer. You did not close partnerships, set pricing, run implementation, or manage accounts. Apply the custody rule: claim the mechanism, attribute the metric to the program, same breath.
"The program's business case projected $20M+ in annual margin recovery; the platform I designed replaced the manual coordination layer that had been the primary source of exception cost."
That's bounded. That's defensible. An outcome card with a dollar figure and your title next to it is neither.
3. Show one step of the 32-interviews-to-5-failure-modes derivation. The entire case hangs from this link. Research produced five failure modes, which became five modules, which became the platform. If the derivation is credible, everything downstream inherits credibility. Right now the case states that 32 interviews identified a root cause and five failure modes, then jumps to the mapping table. The analytical work between those two points — pattern recognition, prioritization, what got excluded — is invisible. You don't need to publish the research repository. One artifact is enough: a condensed affinity map, a paragraph describing the clustering logic, a single example of a finding you excluded and why. Any of these converts the derivation from stated to demonstrated.
Link-by-Link Audit
Link 1: 32 Interviews → Root Cause + Five Failure Modes
The case claims thirty-two interviews across nine sites identified one root cause (no shared source of truth) and five specific failure modes, each becoming a design brief.
Evidence shown: a root-cause summary sentence, six operational baseline metrics (half of orders placed under 90 days, 5-10 hours of status chasing per batch, 63-99% OTD spread across sites, 45% of data outside PRISM, one-third of coordination time on manual calls, partner access to performance data at zero), and a five-row failure-to-module mapping table.
Evidence missing: interview dates, participant roles, site distribution, sample rationale, clustering method, contradictory findings, anything showing the analytical path from raw data to five named failures. The baseline metrics describe the problem space. They don't show how it got carved into five addressable failures.
The probe you'll get: "How did you get from 32 interviews to five failure modes? Were there six? Three? What did you leave out?" This is the most natural question a design leader asks another design leader about research-driven architecture. The case, as written, has no visible answer.
Add evidence. A condensed affinity map showing how themes clustered, a brief narrative on prioritization logic (frequency, severity, addressability), or one excluded finding with reasoning. Any of these closes the gap. The baseline metrics are strong — keep them — but they support the problem statement, not the derivation.
Link 2: Five Failure Modes → Five Modules
The mapping table, five annotated interface reconstructions, and narrative descriptions of how each module addresses its failure mode. The table-plus-interfaces show the correspondence between failure and response more concretely than most portfolio cases at this level manage. Annotations connect design decisions to operational problems. The logic of each module is visible.
Where it's vulnerable: a mapping table that says "this failure produced this module" with an interface showing how the module works is still an organized assertion about correspondence. It doesn't show the judgment that selected this particular response from the alternatives. The case presents five modules as the natural output of five failures, and that framing makes the work read as execution rather than decision-making. An interviewer asking "why a module and not a process change or a policy change?" is probing exactly this — whether you selected or just implemented.
One inconsistency to fix: the Orders narrative says managers needed to act on three of 197 orders. The Orders screen annotation shows four exceptions. The teaser says three. Pick one number.
Keep the mapping and interfaces as-is — they're doing real work. Add one sentence for at least one module about what alternative was considered and why this response was chosen. That converts the module from "the obvious answer" to "the selected answer," and selection is the stronger claim about design judgment.
Link 3: Modules → Partner Adoption
The full case says six of six pharma partners "committed." The teaser says "100% partner adoption." These are different claims about different things.
But is either one a design outcome? In a CDMO relationship, the platform may have been a contractual component of the service — partners use it because the agreement says they will, not because the design earned their adoption. If adoption was mandatory, then 100% tells the interviewer nothing about design quality. It tells them Thermo Fisher had the commercial leverage to require it. The case doesn't address this. An interviewer familiar with pharma services will think of it immediately.
The case doesn't define what committed or adopted means, doesn't provide partner names, launch dates, usage data, or testimony, and doesn't separate design's contribution from implementation, executive sponsorship, or contractual obligation.
Reframe around what design changed, not whether partners showed up. If adoption was contractually required, say so and shift the claim to what the design made possible once partners were on the platform — reduction in status calls, earlier exception discovery, changed quarterly-review conversations. If adoption was genuinely voluntary, say that and define what it meant (active daily use, executive sign-off, whatever is accurate). Either version is defensible. The current version, which claims adoption without addressing whether partners had a choice, is not.
Use the same term on both surfaces. If you have any usage signal — login frequency, task completion, reduction in manual coordination post-launch — add it.
Link 4: Adoption → Financial Outcomes
The most vulnerable link. Five figures across two surfaces, none fully supported.
$20M+ margin. Full case says "recovered annually." Teaser says "opportunity." Recovered implies realized. Opportunity implies projected. Thermo Fisher's public materials don't disclose this figure. No financial model, baseline, or attribution scope on either page. Covered in the priority fixes above.
83% IRR. The full case labels this a "business case" figure. The teaser drops the qualifier. A business-case IRR is a projection. An interviewer who reads "83% IRR" without the qualifier assumes it's a measured return and will feel misled when they learn otherwise. Put "business case" on the teaser. It's already on the full case.
42% overhead reduction. Full case only. No denominator, no baseline, no measurement method.
97.4% forecast accuracy and $2M capacity recovery. Teaser only. Not mentioned in the full case. No derivation for either.
Figures that appear on one surface but not the other suggest you aren't sure which claims to make.
Reconcile or remove. If the 42% overhead reduction is real and attributable, put it on both surfaces with a defined denominator. If the 97.4% forecast accuracy is a platform-measured outcome, put it on the full case with context. For the IRR, keep the business-case qualifier on both surfaces.
Link 5: Juno's Role → Project Results
The case says Juno was Product Design Director, leading one designer and two BCG Digital Ventures engineers, designing the system in twelve months.
The case does not identify Thermo Fisher's product, engineering, operations, quality, regulatory, commercial, or change-management contributors. For a platform deployed across nine manufacturing sites and six pharma partners, the absence of any other named contributor creates an implicit claim that Juno did everything. No interviewer will believe that, and the overclaim undermines the claims they might otherwise accept.
Add one sentence identifying the broader team structure. Who owned implementation. Who owned the commercial relationships. Who owned regulatory and quality requirements. This doesn't diminish your contribution — it makes your contribution credible by placing it inside a real organization.
Link 6: Shipped Work → Future-State Agentic Vision
The full case handles this well. The agentic architecture appears under a clear "If I were building this today" header. One human gate (QA release) is retained as a regulatory constraint. The separation between shipped and speculative is explicit.
The teaser handles it poorly. Agent Purple tokens, AI confidence values, and gate-review metrics appear among the 2021 project visuals without the full case's future-state boundary. A type-system example carries a 2024 timestamp inside a case framed as 2021 work. An "AI Gate Reviews" card shows 24 weekly reviews with 87% average confidence, presented alongside shipped interface components.
If the interviewer opens the teaser first — and many will, because it's the entry point — they may form a working theory that includes the agentic work as shipped. When they hit the full case's future-state separator, they have to revise. That revision creates friction, and friction creates doubt about what else might be mislabeled.
Add the future-state boundary to the teaser. Label agent-related components as speculative or conceptual, matching the full case. Remove the 2024 timestamp from the type-system example or label it as a later addition.
Consistency Table
Discrepancies between the full case and teaser that an interviewer could notice. Fix in priority order.
| Discrepancy | Full Case | Teaser | Risk | Fix |
|---|---|---|---|---|
| Partner visibility | Each partner sees only itself | All six see each other's performance | High — factual contradiction about architecture | Pick the accurate version; update the other |
| Financial framing | "Margin recovered annually" | "Margin opportunity" | High — recovered vs. projected are different claims | Use "margin opportunity" or "business-case projection" on both |
| Agentic boundary | Explicit future-state section | Mixed into shipped visuals | High — mislabeling risk | Add boundary to teaser |
| IRR qualifier | "Business case" | No qualifier | Medium — drops the hedge on the more-visible surface | Add "business case" to teaser |
| Adoption language | "Committed" | "100% adoption" | Medium — different claims about different things | Define and unify |
| Capacity horizon | 18 months (narrative), 11 months (screen) | 6 months, 6 lines | Medium — three numbers for the same feature | Pick the one the screen shows |
| Platform URL | mysupply.thermofisher.com | mysupply.patheon.com | Low — explainable (Patheon is the pharma services brand) but distracting | Unify or add a parenthetical |
What Holds Up
The problem framing is specific and operationally grounded. The baseline metrics — half of orders under 90 days, 5-10 hours of status chasing per batch, 63-99% OTD spread — give the interviewer concrete numbers to anchor on before you show a single screen. The failure-mode-to-module mapping is the clearest piece of design logic in the portfolio. Each module has a named problem, a visible interface response, and annotated decisions connecting the two. The dashboard's side-by-side KPI display (customer OTD at 94% vs. Thermo Fisher's 97%) is a design decision that changes a business conversation, and it reads that way on the page.
The retained QA release gate in the future-state section demonstrates regulatory judgment — exactly the kind of evidence that healthcare and regulated-industry roles test for.
The five modules correspond to functions that Thermo Fisher publicly describes as mySupply capabilities (forecasts, orders, batch tracking, dashboard reporting), which provides external corroboration that the platform exists and does roughly what the case says. Capacity planning doesn't appear in their public feature list. Worth knowing, not necessarily a problem.
The structural weakness across the case is a gap between the altitude of the evidence and the altitude of the claims. The interfaces prove design judgment at the module level. The outcome cards claim business results at the program level. Every probe will land in that gap. Close it by drawing attribution boundaries, not by removing the outcomes. The outcomes are why this case matters at Director+ level. What you need is one sentence at each outcome that says whose number it is, what the design work made possible, and where the program takes over.
- Gusto's send/review/never-send language: The Gusto Head of Design posting asks candidates to define when AI output is ready to ship, needs human review, or should not be sent — the same decision-gate judgment the mySupply QA release gate demonstrates, but applied to agent-generated content rather than batch release.
- OpenAI Engineering Acceleration's evaluation loop: The Engineering Acceleration role names instrument, observe, evaluate, decide, iterate, and rollback as the product design mandate, which maps almost exactly to the longitudinal control record this case currently implies but doesn't show.
- Thermo Fisher's own rollout timeline: A Pharmaceutical Technology interview with Jennifer Cannon said in November 2025 that mySupply had rolled out to customers roughly a year and a half earlier, creating a timing ambiguity with the case's 2021 framing that an interviewer with pharma-industry knowledge could surface.
- The CHI progressive-transparency finding: A peer-reviewed CHI 2026 study found that eight of twelve participants preferred contextually sufficient transparency over maximal process visibility, which bears directly on how much of the mySupply exception-detection and batch-status logic should be surfaced versus available on demand.