Every sprint review I've attended at a product-led company has at least one moment where someone asks: "Wait, why did we build this again?"
The feature ships. The metrics don't move. Retrospectives identify "scope creep" or "unclear requirements." But the actual root cause is almost always the same: the team built something before the decision was clear.
After 10+ years in product across iQIYI, NIO, Alibaba, and consulting for startups, I've developed a 4-question checklist I run through before any sprint begins. It's prevented more wasted cycles than any process tool I've ever used.
The 4-Question Pre-Sprint Checklist
1. Can you name the actual decision in one sentence?
Not the feature. The decision.
"Should we add social sharing or focus on improving the onboarding flow first?" is a decision.
"Build social sharing" is a task.
If your sprint goal is phrased as a task, stop. You've skipped the decision layer. Naming the decision forces you to articulate the trade-off and why you're making it now.
2. What does success look like — and when?
Write this down before the sprint starts, not after.
"DAU increases by 8% within 30 days of launch" is success criteria.
"Users like the new feature" is not.
Without a pre-committed success definition, teams unconsciously move the goalposts after launch. You can't learn from a result you haven't defined in advance.
3. What is the one assumption that could kill this?
Every sprint is a bet. Every bet has one load-bearing assumption — if it's wrong, the whole thing collapses.
For a retention feature: "Users who churn in week 2 are churning because of missing feature X."
If that assumption is untested, you're spending sprint capacity on a hypothesis, not a validated problem. Name it explicitly, and state what evidence you have (or plan to get).
4. What's the review date?
When will you know if the decision was right? Set the date before you ship.
This is the most skipped step and the most valuable. A pre-set review date does two things:
- It reduces the emotional cost of committing (because you're not committing forever, just until the review)
- It creates a forcing function to actually measure results rather than moving on
Why This Works
Most PM frameworks focus on prioritization — deciding what to build from a list. This checklist focuses on decision quality — making sure the list item you picked actually has a clear problem statement, testable hypothesis, and success definition attached to it.
Teams that skip this end up with full sprints and empty metrics.
Teams that use it ship less and learn more.
I formalized this into a full decision framework for product managers: The PM Decision Framework Handbook — a 4-step system for making faster, better product decisions with stakeholder alignment built in.
