Product Hypothesis Template for User Research

Write 3-5, one for each major assumption. But test them sequentially, not in parallel. Start with the riskiest assumption. If the value hypothesis fails, do not waste time on usability testing. The [RICE framework](/frameworks/rice-framework) can help you prioritize which hypotheses represent the biggest risks to address first.

A hypothesis is a prediction about cause and effect: "If we do X, then Y will happen, because Z." A success metric is just the Y part. Hypotheses include the mechanism (the "because") and the action (the "if"). This makes them more useful for learning because you know not just whether the metric moved but why you expected it to move.

Use baselines. If current Day 7 retention is 28%, a target of 90% is fantasy. A target of 35-45% is ambitious but grounded. Look at industry benchmarks, your own historical data, or results from similar experiments at other companies. When in doubt, aim for a 20-30% improvement over baseline. If you have no baseline at all, run a measurement-only sprint first.

Inconclusive usually means one of three things: sample size was too small, the experiment ran too briefly, or confounding factors muddied the results. Before rerunning, diagnose which issue caused the ambiguity. Increase sample size by 2x, extend duration by 50%, or isolate the variable more carefully. If three experiments on the same hypothesis are all inconclusive, the effect is probably too small to matter.

Yes. Failed hypotheses are some of the most valuable product artifacts because they prevent the team from revisiting the same bad idea six months later. Document them in a shared "Experiment Log" that anyone can reference. When a stakeholder proposes a feature you have already invalidated, you can point to the experiment results instead of having the same debate again. ---