Frame the problem
Hypothesis statement
Write an idea as a testable belief: what we'll build, for whom, the outcome we expect, and the signal that will show we were right.
- Time20 to 40 minutes
- People2 to 8 people
- Steps4
What it's for
Turning a feature request into a hypothesis changes the conversation from "should we build it" to "how will we know it worked". Writing the signal down before building stops the team from deciding what success looked like after the results are in.
Use it before an experiment, a prototype or a roadmap item big enough to deserve a measure.
How to run it
Write the belief5 min
We believe that this change…
Name who it's for4 min
For which users or customers?
State the outcome6 min
Will result in what change in behaviour?
Agree the signal8 min
We'll know we're right when we see which measure move, by how much?
Tips
- Name a number in the signal. "Engagement goes up" can't be wrong, so it can't be tested.
- Write several hypotheses for the same goal. Then test the cheapest one first.
Where it comes from
Adapted from the hypothesis format in Lean UX by Jeff Gothelf and Josh Seiden (2013), which brought the scientific method into product design.
Pairs well with
Assumption map
Place every assumption behind a plan by how important it is and how much evidence you have, to find what to test first.
Proto-persona
A quick persona built from what the team already believes, written down so the beliefs can be tested with research.
Objectives and key results
Set an ambitious objective and three or so measurable key results that would show you achieved it.