Every PM I know has experienced this: you ship the feature, it doesn't move the metric, and six weeks later you're in a retrospective trying to explain what went wrong.
The instinct is to blame execution. Wrong priorities. Engineers who missed requirements. A design that didn't land. But most of the time, the roadmap derailed before a single line of code was written.
Here's what actually causes it — and the framework that stops it.
The Real Problem: Undocumented Assumptions
When a product decision gets made, it carries invisible weight: a set of assumptions that everyone on the team believes to be true but nobody has written down.
"Users will adopt the new workflow."
"The integration will hold at scale."
"Our primary competitor won't ship this first."
These assumptions aren't wrong to make. Every product decision requires them. The mistake is treating them as facts instead of bets.
When one of those hidden assumptions turns out to be false — and it often does — the roadmap collapses. The feature ships but doesn't convert. The metric doesn't move. The business case evaporates.
The 4-Step Fix
I developed this framework after years of product work at iQIYI, watching decisions fail not because they were bad ideas, but because nobody forced the team to get explicit before committing.
Step 1: Name the decision
Write down exactly what decision you're making. Not "we're working on the checkout flow" — that's a project, not a decision. A decision sounds like: "We are investing 6 weeks of engineering to redesign the guest checkout flow in order to improve checkout conversion by 15%."
Specificity forces clarity. When you can't name the decision precisely, you don't understand it yet.
Step 2: Define success criteria
Before you build, write down what good looks like. Not in qualitative terms — in measurable ones. "Checkout conversion rate increases from 62% to 71% within 30 days of launch." That's a success criterion. "Users will like the new flow" is not.
This step is uncomfortable because it creates accountability. That's the point.
Step 3: Find the killer assumption
Ask: "What single belief, if wrong, would cause this project to fail — even if we execute perfectly?"
For the guest checkout example, the killer assumption might be: "Our current checkout drop-off is primarily caused by friction in the form — not by price sensitivity or trust concerns." If that's wrong, redesigning the form is a waste.
Once you name the killer assumption, ask: "What's the cheapest way to test it before committing?" A landing page. A user interview. Five sessions of usability testing. The answer is almost always cheaper and faster than the full build.
Step 4: Decide and set a review date
Make the call: go, no-go, or "test first." Then write down a review date — a specific day when you'll revisit the decision with fresh data.
Without a review date, decisions calcify. The market shifts. The assumption becomes false. The team keeps executing anyway because no one scheduled the moment to ask "is this still right?"
What This Looks Like in Practice
At iQIYI, we were evaluating whether to add a push notification feature to increase content discovery. The team was excited. The data showed engagement correlated with notification delivery.
Before committing to a 3-month build, we ran the 4-step process:
- Decision: Build a personalized push notification system to increase D7 retention by 12%
- Success criteria: D7 retention improves from 34% to 38% within 60 days of rollout
- Killer assumption: Users who don't engage with content recommendations aren't doing so because they forget the app — they're doing so because the recommendations aren't relevant
- Test first: Run a 2-week manual notification test with a small cohort using curated content from the editorial team
The test revealed the actual problem: recommendation relevance, not notification timing. We pivoted the roadmap before spending 3 months on the wrong solution.
That's the framework working.
The Pattern That Actually Causes Roadmap Derailment
Roadmaps don't derail because PMs are bad at prioritization. They derail because:
- Decisions get made in meetings, not documents
- Assumptions stay implicit instead of getting named
- Success criteria are vague enough to be unfalsifiable
- Nobody schedules the moment to ask "should we still be doing this?"
The 4-step framework is a forcing function. It doesn't make you smarter. It makes your thinking visible — which is the only way to catch the errors before they cost you a quarter.
If you want the full structured framework in a format you can use immediately, I built a decision handbook for exactly this: A 4-Step System for Analyzing Any Product Problem. It's the same process I use, written for PMs who need to make better decisions under uncertainty — not in theory, but in the middle of a real sprint.
Top comments (0)