Hypothesis-Driven Development (HDD) treats every feature as a hypothesis to be validated, not a requirement to be fulfilled. Teams articulate what they believe, what behaviour change they expect, what outcome they anticipate, and what evidence will confirm or refute the hypothesis.
As a foundational practice for any team doing continuous discovery — replaces 'build it and see' with deliberate, structured learning.
- WE BELIEVE: what are you building? State the feature or change specifically.
- WILL CAUSE: what user behaviour change do you expect?
- RESULTING IN: what business or customer metric will improve?
- WE'LL KNOW WE'RE RIGHT WHEN: what specific, measurable evidence will confirm this?
- Also define: what result would tell you NOT to ship this feature?
- Build the minimum to test the hypothesis. Measure. Learn. Decide.
'We believe that showing a one-sentence context label under each recommended track will cause users to listen to more tracks before skipping, resulting in a 10% increase in track completion rate. We'll know we're right when: completion rate increases ≥8% in a 2-week A/B test with statistical significance. We'll stop if: no measurable difference after 4 weeks.'
Please contact the author for more information on these examples at linkedin.com/in/kshitijrege
- Writing vague hypotheses that cannot be falsified — if nothing could disprove it, it's not a hypothesis
- Not defining the failure condition upfront — deciding what 'bad' looks like after seeing results is biased
- Changing the hypothesis after seeing early results
- Lean UX — Gothelf & Seiden
- Continuous Discovery Habits — Teresa Torres