Most bad product decisions aren't made at the end of a decision process.
They're made at the beginning — when the team agrees on a direction without asking the one question that would have exposed the flaw.
That question is: "If this one thing turns out to be false, does the whole decision fall apart?"
What a Killer Assumption Looks Like
Every product decision rests on assumptions. Some are safe (users have smartphones). Others are fragile — and if they break, the entire decision breaks with them.
The fragile one is your killer assumption.
Example: You decide to build a social sharing feature. The killer assumption might be: "Users want to share this publicly." If users are actually private about this, the whole feature collapses. Not just underperforms — collapses.
Most teams don't name this assumption. They argue about execution when the real debate should be about whether the foundation is solid.
The Question to Ask
Before committing to any significant product decision, ask your team:
"What is the single assumption that, if wrong, makes this entire decision wrong?"
Force the group to name it. Write it down. Make it visible.
This one step separates teams that learn fast from teams that ship confidently and fail expensively.
What to Do With It
Once you've named the killer assumption, you have two options:
Option 1: Test it. Is there a cheap, fast way to validate or invalidate this assumption before you fully commit? A survey, a prototype, a quick interview, an A/B test?
Option 2: Acknowledge it explicitly. If you can't test it in time, at least document it. Write: "We are proceeding with the assumption that X is true. If we discover X is false by [date], we revisit this decision."
This is not weakness. This is how senior PMs operate.
Why Teams Skip This
Naming a killer assumption feels like doubt. Teams worry it will slow things down, create political tension, or make them look uncertain.
But the alternative is worse: you ship, you discover the assumption was wrong, and now you're explaining to stakeholders why the project failed on something that was knowable in advance.
The teams that name assumptions don't slow down. They speed up — because they stop wasting cycles on the wrong things.
The Framework Behind the Question
This question is Step 3 from a 4-step PM decision framework I've been using for years:
- Name the actual decision (not the symptom)
- Define success criteria before looking at options
- Find the killer assumption
- Decide, document your reasoning, and set a review date
If this resonates, I've put the full framework — with templates, worked examples, and decision logs — into a handbook: The PM Decision Framework ($19.90).
It's for PMs who want to make fewer regrettable decisions and build a traceable record of how they think.
Top comments (0)