A product hypothesis is a bet written so that an experiment can show it is wrong: it states which change, for which audience, should produce which outcome, and how the team will know. The format "We believe that... We will know this is true when..." forces you to declare the metric, the expected change and the timeframe before building, separating learning from opinion.
How to use
- Describe the observation or evidence behind the hypothesis: data, an interview, a support ticket.
- Say who the audience is and what change you propose.
- Write the expected outcome as a change in behaviour, not as a deliverable.
- Enter the metric, the direction, the current value, the expected change and the timeframe.
- Review the quality check and take the hypothesis into experiment planning.
What each field asks for
| Field | What to enter |
|---|---|
| Observation or evidence | What you saw in the data, in interviews or in support that motivates the hypothesis. |
| Audience | Who the change affects, as specifically as possible. |
| Proposed change | What you will do, in a phrase starting with a verb in -ing form. |
| Expected outcome | The change in behaviour you expect, starting with a verb. |
| Metric (optional) | The number that will show whether the hypothesis holds. |
| The metric should | The direction the metric needs to move in. |
| Current value of the metric (optional) | As a percentage. With it, the tool works out the test sample. |
| Expected change (optional) | In % relative to the current value. It is what makes the hypothesis refutable. |
| Timeframe (optional) | How long the effect should take to show. |
Example
A fictional online shop saw that 6 in 10 mobile shoppers abandon the basket at the shipping step. The hypothesis generated: "We believe that showing the shipping cost on the product page for shoppers on mobile will reduce abandonment at the shipping step. We will know this is true when basket-to-purchase conversion rises from 4% to 4.6% (+15%) within 4 weeks." It passes all six quality criteria, and the minimum experiment is an A/B test with 17,943 people per variant.
When to use
- Before asking the team for time to build an idea, to declare what it needs to achieve.
- After a round of interviews, to turn observations into testable bets.
- To review a backlog full of solutions with no expected outcome.
- Before planning an A/B test, to fix the metric and the minimum change.
Frequently asked questions
What makes a good product hypothesis?
It is a sentence that could be wrong and that a test can knock down. It starts from evidence, names audience, change and outcome, and says in which metric, by how much and within what timeframe the outcome should appear.
What is the difference between a hypothesis and an idea?
An idea describes what to do; a hypothesis describes the expected effect and how to measure it. "Show shipping costs on the product page" is an idea. The hypothesis adds for whom, what should change in behaviour and which number would confirm it.
How do I choose the metric?
Use the metric closest to the behaviour the change should affect, one the team already measures and that reacts within the test period. Distant metrics, such as annual revenue, take too long and mix in other causes.
Why does the hypothesis need a number?
Without an expected change, any movement in the metric seems to confirm the bet. The number sets how much the metric must change to be worth the cost, and it is what lets you work out the test sample.
How many hypotheses should I have at once?
Few per objective: two or three under test, each with one primary metric. Many open hypotheses split traffic, lengthen tests and make it hard to know what caused each result.
How should I prioritise hypotheses?
Compare the size of the expected effect, the strength of the evidence and the cost of testing. Start with those that have reasonable evidence and a cheap test; weak hypotheses first need simpler discovery, such as interviews or a prototype.
What if the test refutes the hypothesis?
Record the learning: the change did not produce the expected effect for that audience and timeframe. That saves you from building something useless. Revisit the original evidence and decide whether a variation is worth testing or the bet should be dropped.