Why most product teams cannot tell a dead project from an early one, and the three tests that separate a clean kill from a case worth tabling.
Shownotes
You have rebuilt the business case three times, the customer calls went fine, and it still feels like you are polishing a tombstone. The problem is rarely the kill decision or the budget. A dead project and an early one look identical from the outside.
Who this is for: Product managers, R and D leads and gate committee members deciding whether to kill, fund or table a business case in life science tools and diagnostics.
Jasmine Gruia-Gray gives Matt Wilkinson a three-test diagnostic for telling a genuinely dead case from one that is merely early: is the data gap objective or epistemic, what does your most resistant buyer say, and is this a product problem or a timing problem. She then defends the framework against three sharp objections, including the honest admission that tabling a case can quietly become a way to never decide. The episode closes with the two moves a nervous product manager can make on Monday and the one question that exposes a narrative dressed up as data.
Key idea: Most teams do not have a kill problem or a funding problem; they cannot tell a dead project from an early one, and three tests separate them.
What you will learn:
- How to tell an objective data gap, which belongs in an assumption log, from an epistemic one, which means nobody has asked the right question yet
- Why running the case against your most resistant buyer surfaces adoption costs a favourable panel will never show you, using concordance data as the worked example
- How to separate a product problem from a timing problem, and when tabling with a dated re-entry trigger beats killing
- Why the synthetic buyer panel replaces the broken step of rebuilding the model rather than adding a fourth checkpoint
- Where the framework is exposed: a tabled case with no external owner tends to fade rather than die
- The two Monday moves and the one-sentence evidence test that tells you whether you have a business case or a story
Watch, subscribe and go deeper: Read the full piece, When to Walk Away: Kill the Business Case or Just Table It. If you want help running this diagnostic on your own pipeline, including the synthetic buyer panel, Strivenn offers a free thirty minute PersonaAI consultation with concrete next steps either way.
You can subscribe to A Splice of Life Science Marketing here
Transcript
Matt Wilkinson and Jasmine Gruia-Gray work through a practical question every product manager eventually faces: how do you tell a business case that is genuinely dead from one that is only early, and what do you do once you know. The full conversation follows.
The diagnosis nobody says out loud
Speaker: Matt Wilkinson
You've rebuilt the business case model three times. The customer conversations went fine, the bottom-up numbers finally clear the bar on attempt number three, and your VP of R and D still believes in this, bless him. So why does it still feel like you're polishing a tombstone?
Here's the diagnosis nobody says out loud in a gate review, mostly because it's a little embarrassing. Most teams don't actually have a kill problem and they don't have a funding problem either. They have a problem telling the difference between a project that's genuinely dead and one that's just early. From the outside those look identical.
The uncomfortable part is that most organizations are built to never find out which one they're looking at. Stage-Gate kill rates run lower than the actual data on project outcomes would justify, which means the whole system quietly rewards stubbornness over honesty. So let's ask the person who's spent years inside RUO innovation pipelines watching this exact slow motion car crash. Jasmine, how do you actually tell a dead case from an early one?
Test one: objective or epistemic
Speaker: Jasmine
You run three tests before you let yourself touch that model again. First, is the gap in your data objective or epistemic. Objective means the data genuinely cannot exist yet at this stage, and that's fine, that goes in an assumption log and you move on with your life. Epistemic means your team just hasn't asked the right question yet, which is a completely different and far more annoying fix.
Speaker: Matt Wilkinson
Give me a real example of epistemic, because that one's slippery and people love hiding in it.
Speaker: Jasmine
A team building a qPCR reagent kit for pharma R and D had great voice of customer on assay sensitivity and throughput. Zero data on how method transfer works between their dev labs and GMP manufacturing. Nobody had asked. That's a question sitting right there, completely unasked.
Test two: run it against your most resistant buyer
Speaker: Matt Wilkinson
Test two.
Speaker: Jasmine
Run the business case against your most resistant buyer, not your favorite cheerleader. We use a synthetic buyer panel for this, built from existing voice of customer data and persona work, and you deliberately point it at the buyer with zero appetite to switch. A team building an automated sample prep platform asked their synthetic buyer panel what would stop adoption even with great throughput data. The core facility director persona came back with something the team hadn't modeled at all: concordance data. Proving the new method matches their validated one before they're allowed to publish results for their own researchers. That's three to six months and headcount they don't have. The instrument got priced. The actual cost of adopting it did not.
Test three: product problem or timing problem
Speaker: Matt Wilkinson
And test three.
Speaker: Jasmine
Whether it's a product problem or a timing problem, and these two wear the exact same disguise. Voice of customer confirms real pain but not real urgency, early adopters can't produce reference customers, the market needs eighteen to twenty four months to catch up to you. That's not a reason to kill the business case. That's a reason to table it with an actual date stapled to it, not a vague "we'll revisit someday."
Objection: isn't this just more process
Speaker: Matt Wilkinson
Objection one, and I think a lot of PMs are yelling this at their car speakers right now. This is just more process. We already have Stage-Gate, finance review, and now a synthetic buyer panel sounds like checkpoint number four nobody asked for.
Speaker: Jasmine
I'll take that one head on, because it's not additive, it's a replacement. It replaces the part of the process that's already broken, which is rebuilding the financial model a third time and hoping the inputs land somewhere more flattering. The synthetic panel test in that example took an afternoon and surfaced a six-figure adoption cost nobody had priced in. Compare that to finding it in a failed launch eighteen months from now, in front of your entire leadership team. The process isn't longer, it's a way to keep the customer in the room.
Objection: does tabling just mean never
Speaker: Matt Wilkinson
Objection two, and honestly, this is the one I think pokes a real hole in your whole framework. You've built this careful, tidy distinction between killing something and tabling it. But "table it" is also the single easiest way for an organization to never kill anything ever again. You write a re-entry trigger, you pick a nice round date, and then the date arrives and nobody revisits it, because the person who tabled it has changed teams or just really, really does not want to have that meeting. What actually stops "table it" from becoming corporate speak for "we'll never discuss this again"?
Speaker: Jasmine
Honestly? Nothing in the framework enforces that on its own. The diagnostic tells you which decision you're facing. It doesn't make the organization show up on the date. What's supposed to happen is someone outside the project owns the re-entry trigger, not the PM who tabled it, so there's no built-in incentive to let it quietly expire in a drawer somewhere. But plenty of organizations don't build that ownership in, and a lot of tabled cases just fade out slowly instead of dying cleanly. That's actually the worse outcome, because a slow fade teaches nobody anything.
Speaker: Matt Wilkinson
So the framework is brutally honest about diagnosis and a little exposed on follow through.
Speaker: Jasmine
That's fair, and I'd rather say that out loud than pretend a flowchart can fix an organization's discipline problem.
Objection: garbage in, garbage out
Speaker: Matt Wilkinson
Objection three. The synthetic buyer panel runs on your own voice of customer data and your own personas. Garbage in, garbage out. How do you know the panel isn't just confirming whatever the team already wanted to believe?
Speaker: Jasmine
That's precisely why you point it at the most resistant persona on purpose, not the one who's easiest to please. Run it against your biggest fan and sure, you'll just get a very expensive echo of your own optimism. Pointing it at the QC director with a validated workflow and zero patience for revalidation costs is what forces out a real objection instead of a comfortable one. Is it only as good as the underlying VOC? Completely, no argument there. But a few hours stress testing against imperfect data is still a lot cheaper than building a whole financial model on top of it and finding out the hard way in a gate review.
Your first move on Monday
Speaker: Matt Wilkinson
First move. What does a PM do Monday morning with a case they're already nervous about?
Speaker: Jasmine
Name which uncertainty you're actually dealing with before you touch that model again. Objective, epistemic, or your own attachment to the outcome. Say the word out loud, even if it's a little uncomfortable. Most people skip straight to rebuilding the spreadsheet without ever naming which problem they're actually solving.
Speaker: Matt Wilkinson
Second move.
Speaker: Jasmine
Before you rebuild the case a third time, run it against your most resistant buyer persona first. Whatever objection shows up there should change the model. It should not get quietly patched around.
The question that cuts across it all
Speaker: Matt Wilkinson
And the question that cuts across this entire conversation.
Speaker: Jasmine
What's the actual evidence, not the story you've been telling yourself, that would make you kill this case today. If you can't answer that in one sentence, you don't have a business case yet. You have a narrative you've repeated to yourself enough times that it started to sound like data.
Close and call to action
Speaker: Matt Wilkinson
The full piece is "When to Walk Away: Kill the Business Case or Just Table It," on strivenn.com under Thinking. Link's in the show notes.
Speaker: Jasmine
And if you want help running this diagnostic on your own pipeline, including the synthetic buyer panel piece, Strivenn offers a free thirty minute PersonaAI consultation. No obligation, you'll leave with concrete next steps either way. Details at strivenn.com.
Speaker: Matt Wilkinson
Tabling a case with a real owner and a real date is discipline. Tabling it with neither is just a kill decision hiding in a hoodie.
Speaker: Jasmine
Kill it clean or table it with precision. Either one beats rebuilding it a fourth time and calling that strategy.
Q&A
How do I run the resistant-buyer test if I don't have a synthetic buyer panel?
You do not need software. Take your existing voice of customer notes and personas, pick the buyer with the least appetite to switch, and spend an afternoon writing down every objection they would raise to adoption, not to the science. One colleague role-playing that persona for an hour will surface the adoption costs your model ignored. The point is to interrogate the reluctant buyer, not the enthusiast.
How do I know if my data gap is objective or epistemic?
Ask whether the data could exist yet at this stage. If it genuinely cannot, log it as an assumption and move on. If it could exist and nobody has gathered it, that is epistemic, and it is usually a question sitting unasked, like how method transfer works between your dev labs and manufacturing. Name which one you are facing out loud before you touch the model again.
We table cases and never revisit them. How do we fix that next week?
Assign the re-entry trigger to someone outside the project, not the PM who tabled it, and put a real date on it. Pick one currently tabled case, name an owner today, and diarise the review. Ownership is what stops a tabled case fading in a drawer. Without an external owner and a date, you have not tabled it, you have killed it quietly and told nobody.
My VP still believes in the project. How do I raise killing it without it feeling personal?
Separate the case from the person. Put one question on the table: what evidence, not the story we keep telling, would make us kill this today? Frame the resistant-buyer test as protecting the team from a failed launch in front of leadership. You are not judging anyone's judgement, you are pricing the cost of adoption before the market does it for you.
What is the smallest thing I can do Monday morning?
Before you reopen the spreadsheet, write one sentence naming the uncertainty you are actually dealing with: objective, epistemic, or your own attachment to the outcome. Then write the single piece of evidence that would make you kill the case today. If you cannot write that sentence, you do not have a business case yet, you have a narrative you have repeated until it sounds like data.
