In 30 seconds
- Write features as hypotheses with measurable outcomes.
- Build the smallest thing that tests the hypothesis.
- Keep, change or drop the feature based on evidence.
A simple template
We believe that [building this] for [these users] will result in [this outcome]. We'll know we're right when we see [this measurable signal].
An example
We believe that adding saved addresses for returning customers will reduce checkout abandonment. We'll know we're right when abandonment drops by at least 5% within four weeks.
How it changes the work
- The backlog holds bets with expected outcomes, not just features
- Teams build the smallest slice that tests the bet, often via A/B tests
- Success is judged by outcomes, linking to outcome-based planning
Myth vs reality
Myth · Hypotheses are only for startups.
Reality · Any product with uncertain outcomes benefits.
Myth · Writing hypotheses is extra paperwork.
Reality · One sentence focuses the whole team.
Myth · If the hypothesis fails, the team failed.
Reality · The team learned cheaply; that's success.
The AI angle
AI lowers the cost of building experiments, so teams can test more hypotheses. The discipline of stating the expected outcome and measuring it matters even more when building is cheap.
FAQ
Does every story need a hypothesis?
Usually features or epics do; small stories inherit them.
How do we measure outcomes?
Analytics, experiments, surveys or support data, chosen up front.
How does this relate to the lean startup?
It applies the build-measure-learn loop to feature work.