Hypothesis-driven development (HDD) is an approach to building products where each piece of work is framed as a testable hypothesis instead of a fixed requirement. The team writes down what they believe, what they expect to see if that belief is true, and what they will actually measure — then they ship the smallest experiment that can confirm or kill the belief.
The shape of a typical hypothesis:
We believe [some change to the product] will result in [some change in user or business behaviour] for [a specific segment of users]. We will know we are right when [a measurable signal moves by a specific amount].
If the experiment supports the hypothesis, the team invests further. If it doesn’t, the team stops, learns and reframes the problem.
Why teams adopt it
- It exposes assumptions that would otherwise hide inside a feature spec.
- It makes “no” cheaper — killing a feature after a one-week experiment costs less than killing it after a quarter of build.
- It anchors the team to outcomes, not output: success is defined before the work starts.
- It defends against vanity metrics because the metric is named in the hypothesis, not chosen later to justify the work.
Where it fits
Hypothesis-driven development pairs naturally with minimum viable products, outcome-over-output thinking and lightweight discovery practices. It is most useful when the product team has real uncertainty about what will work — for problems with a known answer, a hypothesis is unnecessary ceremony.
Common pitfalls
- Hypotheses written after the fact to justify a feature already chosen. This is theatre, not learning.
- Vague success criteria like “users will love it” — if you can’t measure it, you can’t disprove it.
- Treating one experiment as the final word. A single A/B test rarely settles a strategic question; it moves the team’s confidence one way or the other.
Further reading
