The backlog item says 'Add dark mode.' The team builds it, ships it, and moves on to the next item. Three months later, someone asks whether dark mode was worth the investment. Nobody knows. There was no success metric defined, no baseline captured, and no review scheduled. The feature exists, but whether it delivered value is a mystery.
Hypothesis-driven development prevents this by treating every feature as an experiment. Before writing a single line of code, the team states what they believe will happen, how they will measure it, and what threshold constitutes success. It is the scientific method applied to product development, and it transforms how teams prioritise, build, and learn.
The Core Idea
A product hypothesis is a testable statement with three components. First, who is affected: which user segment will experience the change. Second, what will happen: what specific behaviour or metric will change. Third, why it will happen: the causal mechanism that connects the feature to the expected result. The standard format is: 'We believe [user segment] will [specific behaviour] because [reason].'
For example, instead of 'Add dark mode,' the hypothesis becomes: 'We believe power users who work evening sessions will increase their average session length by 15 percent because dark mode reduces eye strain during extended use.' This is testable. You can measure session length for the target segment before and after the change. You have a clear threshold for success. And if the hypothesis fails, you have learned something specific rather than just 'dark mode did not work.'