The Killer Assumption Test: How to Spot Doomed Product Decisions Before You Ship

Every product decision rests on at least one assumption that, if wrong, makes the entire effort pointless. I call this the "killer assumption."

Most PMs don't name it. They build, ship, and then explain why the metric didn't move.

Here's how to find the killer assumption before it finds you.

What Is a Killer Assumption?

A killer assumption is the single belief that has to be true for your product decision to be correct. Not all the assumptions — the one that matters most.

For example:

• You're building a notification feature to increase re-engagement. The killer assumption: "Users are disengaging because they forget about the product, not because they lost interest in it."


• You're redesigning onboarding to improve activation. The killer assumption: "Users who drop off during onboarding are doing so because the flow is confusing, not because the product doesn't match what they expected."

Notice how in both cases, if the killer assumption is wrong, the entire effort is wasted — regardless of how well you execute.

Why PMs Don't Surface It

There are a few reasons this happens:

1. Assumption naming feels like admitting uncertainty. Teams want to project confidence in their roadmap. Saying "here's the one thing we're betting on" feels like weakness. It's actually the opposite — it's intellectual honesty that enables faster learning.

2. The assumption is buried in the framing. When a PM writes "users need better search," the killer assumption ("search is what's blocking user success") is hidden inside the solution statement. If you never separate problem from assumption from solution, you never see it clearly.

3. Everyone already agrees on it. The most dangerous assumptions are the ones that feel obviously true to the whole team. Consensus doesn't validate assumptions. It just means nobody challenged them.

The 3-Question Test

Before committing to any significant product decision, answer these:

Q1: What would have to be true for this to work?

Write down everything. Then circle the one that, if false, would invalidate all the others.

Q2: How confident are we in that assumption, and why?

Not "pretty confident" — name the specific evidence. If you can't, name what evidence you'd need.

Q3: What's the cheapest way to test it before we build?

A customer interview, a landing page, a prototype, a manual experiment. The answer almost always exists. The question is whether the team is willing to slow down enough to run it.

The 4-Step Framework

This is one piece of a broader decision-making process I use with PM teams:

1. 
   Name the decision (not the feature, the actual decision being made)


2. 
   Define success criteria upfront ("We'll know this worked if X moves from A to B by date")


3. 
   Find the killer assumption (the one thing that has to be true)


4. 
   Set a review date (when will you revisit, and under what trigger conditions)

The killer assumption step is where most teams short-circuit. They move from step 1 directly to step 4, skipping the thing that would tell them whether step 1 was even the right question.

A Real Pattern I've Seen

At iQIYI, we had a team convinced that improving content discovery would increase weekly active usage. The killer assumption was: "Users who are inactive aren't finding content they want."

Running a 2-week test on a sample segment showed the actual pattern: users were finding content fine — they were just finishing their shows and not receiving a compelling "next series" recommendation at the right moment. Completely different problem. Completely different solution.

The original discovery feature would have taken a quarter to build. The recommendation timing fix took two weeks.

Naming the killer assumption before building saved about 10 weeks of engineering time.

The Discipline

The skill isn't finding the assumption — it's getting comfortable naming it out loud before you build, and being willing to run a cheap test before you commit.

Teams that do this ship less and learn more. That's not a bad trade.

If you want the full framework with templates for running this process on your team, I put it in a short handbook: A 4-Step System for Analyzing Any Product Problem