For life science PMs: at the gate, treat dissenting customers as evidence. Enthusiast quotes only confirm what you hoped.
Shownotes
Most stage gate reviews are built to help a product pass. Whether it should pass is a different question, and the gate rarely asks it. That design produces confident decks and expensive mistakes.
Who this is for: product managers, commercial leaders and gate committee members in life science tools and diagnostics companies.
Matt Wilkinson and Jasmine Gruia-Gray examine why gate processes reward building a strong case, and why that skill has little to do with whether the product should exist. They walk through a falsification approach that asks what would kill a programme, then get specific about revenue forecasts, customer research and the one question that exposes a weak case. The falsification shift changes the question the gate asks. It leaves the template alone.
What you will learn:
- Why a skilled PM can pass a gate the product should have failed
- How to apply a falsification test to technical claims and to revenue forecasts
- The three questions that decide whether a forecast survives the room
- What to write on Monday when your gate template has no field for failure conditions
- Why one customer who already solved the problem tells you more than ten enthusiasts
- The one question to ask R and D, and why a pause is the signal you want
Chapters:
- [00:18] How gates end up rewarding optimism
- [01:38] The system is working as designed
- [02:15] Can the committee catch a well-built case?
- [03:04] The falsification shift: prove yourself wrong
- [03:48] Technical claims and revenue forecasts
- [05:03] Experience does not immunise a committee
- [05:41] The transparency penalty for honest PMs
- [06:30] The culture problem and the post-launch debrief
- [07:35] One experiment before the feasibility gate
- [08:23] Getting R and D to test what they believe in
- [08:57] Your first move on Monday
- [09:31] Rethinking the customer research section
- [09:54] The one question that cuts across all of it
- [10:19] Where to go next
Watch the full episode and subscribe to A Splice of Life Science Marketing.
Jasmine's full article, including the two-track Evidence Tier Framework and the gate-by-gate evidence standards for Feasibility, Development, Launch and Lifecycle, is at https://strivenn.com/thinking/stage-gates-should-ask-for-evidence-not-optimism.
If you have a gate coming up, book a growth consultation at https://strivenn.com/contact or find Jasmine on LinkedIn.
View the Transcript
Matt Wilkinson and Jasmine Gruia-Gray work through why commercial stage gates tend to produce optimism rather than evidence, and what a product manager can do about it before the next gate opens.
Why gates produce optimism, not evidence
Speaker: Matt Wilkinson [00:18]
Hey Jasmine.
Speaker: Jasmine [00:19]
Hello Matt, how are you today?
Speaker: Matt Wilkinson [00:22]
I'm good thank you. And today we're talking about stage gates. Specifically, why the process most life science companies use to decide whether a product should move forward is structurally designed to produce optimism rather than evidence. Not because the people running it are doing anything wrong, but because the incentives, the templates, and the culture around the gate reviews reward building a strong case.
Speaker: Jasmine [00:28]
Indeed.
Speaker: Matt Wilkinson [00:49]
Rather than testing whether the case is true. Now, this matters more than it might sound. The commercial decisions made at stage gates, whether to proceed, whether to fund the next phase, whether to commit the team, are some of the highest stakes calls in life science product development. Get them wrong consistently, and you are not just losing individual programs. You are building a portfolio on foundations that were never properly tested. Now, you've just written a blog on this. And I found it pretty uncomfortable to read. Your argument is that the gate process is working exactly as designed. It just might be designed to answer the wrong question. I want to dig into this because if this is right, the fix isn't about a better template, it's about having a different conversation. Is that a fair reading of what you're arguing?
The system is working as designed
Speaker: Jasmine [01:38]
Yeah, it sure is. And the reason it matters is that the system is working as designed. A gate process that asks product managers to build a business case will produce product managers who are expert at building those types of cases. That's not the same as being good at testing whether the product should exist. A skilled PM knows which numbers the committee will accept and how to frame the competition in a way that doesn't invite hard questions. None of that tells you whether the market will buy the product.
Can the committee catch a well-built case?
Speaker: Matt Wilkinson [02:15]
Isn't the committee supposed to catch that? Isn't that the whole point of having a stage gate process?
Speaker: Jasmine [02:21]
Yes, but the committee can only probe what's in the room and what's being discussed. A skilled PM controls what's in the room, and the things most likely to kill the program are exactly the things most likely to be absent from the deck. At least that's been my experience both as a product manager and on the committee. A capital instrument program that should have been stopped early consumes two, maybe sometimes four million dollars in development spend before the evidence becomes impossible to ignore. And the gate didn't fail because it lacked data. It just asked the wrong question.
The falsification shift: prove yourself wrong
Speaker: Matt Wilkinson [03:04]
So your suggestion is to design the gate around proving yourself wrong, rather than proving yourself right?
Speaker: Jasmine [03:12]
Exactly. It's that falsification shift. Not what supports this argument, but instead what would kill this argument. And have we seriously tested it? Your R and D colleagues already operate this way, and a scientist doesn't just show the experiments that worked, they show the ones that failed because the boundary conditions tell you a lot. Those limits of what the data can claim are invaluable, and the commercial gate should hold itself to exactly the same standard.
Technical claims and revenue forecasts
Speaker: Matt Wilkinson [03:48]
So, in other words, what some people might call a stage gate pre-mortem? Nice. So your framework treats two types of claims very differently. You have technical claims that have to be tested against reality, and then revenue forecasts that just have to show they're working. Is that a bit of a generous standard for the number that matters most to the committee, which is always the money?
Speaker: Jasmine [03:52]
Yeah, exactly. Yeah, the alternative is worse. Demand the same standard from a revenue forecast as from a lab result, and you've created a process that kills almost every early stage program worth running. Nobody can run a controlled experiment on a market that doesn't exist yet. The standard I'm describing is not about how the document looks, it's about whether the committee can see the reasoning behind the number. Where did the revenue figure come from? Which specific customer is it based on? How many labs is it based on? What would have to be true for that projection to work? If a PM can't answer those three questions in the room, the forecast fails, regardless of how confident the presentation sounds.
Experience does not immunise a committee
Speaker: Matt Wilkinson [05:03]
Doesn't that assume the committee will push on those questions? All too often, the teams we've worked with who have had programs miss their launch targets by fifty, sixty percent, those committees are experienced too. Experience doesn't immunize a committee against a well constructed case. Is that true?
Speaker: Jasmine [05:19]
It is, which is why the standard has to be built into the template, not left to the judgment of whoever's in the room on that day. If the gate can't proceed without a written answer to those three questions, the committee has something concrete to interrogate. It doesn't replace their judgment, it gives their judgment something to work on.
The transparency penalty for honest PMs
Speaker: Matt Wilkinson [05:41]
But if I document everything that could go wrong and bring it to the stagegate meeting, I've handed the committee a list of reasons to say no. The product manager who stays quiet about the risks walks out with approval and I've been transparent about the risks and my projects get killed.
Speaker: Jasmine [05:58]
That's fair enough. That is a real risk. And I want to be honest about it. You can present failure cases carefully. Here's what we found, here's why it doesn't affect our target use case, here's what would actually stop this program. That gives the committee something precise to engage with rather than a reason to panic. But if the committee is still determined to treat evidence of careful testing as a sign the program's too risky, the framework alone will not save the product manager or the project.
The culture problem and the post-launch debrief
Speaker: Matt Wilkinson [06:30]
So that sort of speaks to the fact that really we need to work on maybe a bigger fix and fixing the culture problem first?
Speaker: Jasmine [06:39]
Yeah, it works better inside those organizations. It also surfaces the culture problem faster in the ones that haven't, which is its own kind of value. But yes, I'm not going to pretend that changing what goes in the gate pack fixes a committee that rewards optimism. It doesn't. I mean, we know that a typical stage gate process has the last stage post-launch, which is a debrief. And that debrief sure could happen right after the project closes, but typically also happens a couple of years later to assess how accurate the business case was. How well forecasted was year one of the launch and year two of the launch. So one way or another, this kind of discussion does need to surface.
One experiment before the feasibility gate
Speaker: Matt Wilkinson [07:35]
You also recommend running one targeted experiment before the feasibility gate. But teams raising this objection are often at the point where the feasibility gate is how they make the case for resources in the first place. They're asking for budget to do the work you were describing before they have the budget to do any work. How do we square that circle?
Speaker: Jasmine [07:55]
Yeah. The experiment I'm describing isn't a full validation study. It's one targeted test at the conditions most likely to break the technology. So a day of bench time, not a full-on program. If a team genuinely can't find a day of bench time before a gate that's asking for two to four million dollars in development commitment, that's a prioritization problem, not a resource problem.
Getting R and D to test what they believe in
Speaker: Matt Wilkinson [08:23]
Fair. I mean it does assume the R and D team agrees it's worth running. And even if the resources exist, convincing an R and D team to run a test designed to break something they believe in, isn't that a hard conversation for a PM to have?
Speaker: Jasmine [08:36]
It can be, and the resistance itself can be a signal as well. A scientist who can't quickly name the conditions under which their approach would fail either hasn't thought about it or has and doesn't want to say. Both are things you want to know before the gate, not after it.
Your first move on Monday
Speaker: Matt Wilkinson [08:57]
Now, for the product manager listening to this who goes back to their gate template on Monday and none of those fields exist, what's their first move?
Speaker: Jasmine [09:06]
Yeah, two sentences per claim. One stating the condition under which the claim fails, and one stating what you found when you looked for that condition. You're not redesigning the template, you're populating it differently. Most gate committees accept this immediately because it makes the program easier to defend, not harder to pass.
Rethinking the customer research section
Speaker: Matt Wilkinson [09:31]
And what about the customer research section?
Speaker: Jasmine [09:34]
So find at least one customer for whom this problem is already solved. Document what they used instead. If you can't find anyone, that's a signal worth surfacing at the gate, not after. Enthusiast quotes are confirmation. Dissenting voices are evidence.
The one question that cuts across all of it
Speaker: Matt Wilkinson [09:54]
And if somebody's looking for one question that just cuts across all of it.
Speaker: Jasmine [09:58]
Hmm. Ask your R and D partner, what did we design specifically to break this? A clean answer with data means you proceed with confidence. A pause is the most valuable signal you'll get before the gate opens. The pause tells you what the deck can't.
Where to go next
Speaker: Matt Wilkinson [10:19]
Thank you for digging into this for us all. I hope everybody found that useful. The full blog and a practical framework for what counts as good evidence at each stage of development, plus a helpful FAQ on what to do when your committee uses your own rigor against you, can be found at strivenn.com and we'll provide the link in the show notes. If you have a gate coming up and want to work through what this looks like in your program, find Jasmine on LinkedIn or book a growth consultation at strivenn.com.
Speaker: Jasmine [10:45]
Right. This was super fun. Thanks, Matt.
Speaker: Matt Wilkinson [10:48]
Thank you, soon.
Q&A
How do I bring the "dissenting voices are evidence" idea into a gate deck without looking like I am arguing against my own product?
Frame it as de-risking, not doubt. Add one line per claim: the customer for whom this problem is already solved, and what they used instead. Next week, call one lost or sceptical buyer, capture their objection verbatim, and place it beside your enthusiast quote. The committee sees you stress-tested the case. That reads as rigour, and it costs one conversation.
I run marketing, not the gate. What can I actually influence here?
You own the customer evidence that feeds the gate, so you control the quality of the input. Next week, brief your team to log dissent as carefully as praise in every call note. Bring one named account where the problem is already handled to the next gate review. You are not redesigning the process. You are changing what evidence reaches the room, which shifts the decision without needing the committee's permission first.
Where do I find the customer who already solved the problem, on a small budget?
Start with your own lost-deal list and your closed-won accounts who bought something adjacent. One afternoon on the phone with three of them will surface who solved it another way and what they used. No panel, no agency. Ask what they reached for and why it was good enough. If nobody solved it at all, that absence is itself a finding worth taking to the gate.
How do I present a failure condition without handing the committee a reason to kill the programme?
Give them the condition and the result together. State what would break the claim, then state what you found when you looked. One sentence each. A tested risk with a clear boundary reads as control. An unnamed risk reads as a gap. Next week, pick your single weakest claim and write those two sentences. You will defend it faster in the room than a PM who left it blank.
What is the fastest way to test this next week with one person?
Ask your R and D partner one question: what did we design specifically to break this? A clean answer with data means proceed. A pause tells you the claim has not been stress-tested yet, which is exactly what you want to know before the gate rather than after. It takes one conversation, no budget, and it gives you the most useful signal available before the gate opens.
