Writing Hypotheses That Actually Produce Signal
A weak hypothesis produces a weak test, no matter how well it is executed. This reading covers how to write hypotheses that teach you something regardless of the result.
A Hypothesis Names a Mechanism, Not Just an Outcome
The difference between a guess and a hypothesis is the mechanism. "Changing the CTA color will improve conversion" names an outcome with no reasoning behind it — if the test fails, you learn nothing. "Users don't notice the CTA against the current background, so increasing contrast will improve visibility and clicks" names a mechanism you can evaluate even if the test doesn't move the metric.
A useful template: "Because [evidence/observation], we believe [change] will cause [effect], measured by [metric]." Every part of that sentence forces you to be specific before you write a single line of test code.
Where Good Hypotheses Actually Come From
The best hypotheses rarely come from brainstorming in a room. They come from evidence: session recordings showing users hesitating at a specific step, support tickets describing the same confusion repeatedly, funnel analytics showing a sharp drop at one point, or survey responses naming a specific objection. A hypothesis grounded in observed user behavior starts with a real chance of being right; one grounded in internal opinion is closer to a coin flip.
Scoping a Hypothesis to Be Testable
A hypothesis that's too broad — "improve the onboarding experience" — can't be tested cleanly because a dozen different changes could technically satisfy it. Scope hypotheses down to one variable wherever possible: one page, one step, one specific friction point. Broader redesign tests have their place, but they trade diagnostic clarity for speed, and you should choose that tradeoff deliberately rather than by accident.
A hypothesis you can't falsify isn't a hypothesis — it's a preference wearing a lab coat. If no possible test result would change your mind, you've already decided the answer and the test is theater.
Recording Hypotheses So the Backlog Compounds
An untested hypothesis backlog is a waste of the thinking that went into it. Log every hypothesis with its supporting evidence, the metric it targets, and — after the test runs — the actual result and what you learned, win or lose. Over a year, this log becomes one of the most valuable assets a growth team has, because it prevents the team from re-testing ideas that already failed and reveals patterns across tests that no single result would show.
Practical Review Checklist
Before launching your next test, confirm you can answer:
- What specific evidence led you to this hypothesis
- What mechanism you believe explains why the change would work
- What single metric will determine whether the test succeeded
- Whether the scope is narrow enough to isolate what caused the result
- Where this hypothesis and its result will be logged for future reference
Conclusion
A strong hypothesis makes every test valuable, whether it wins or loses, because it's built on a mechanism you can learn from. A weak one wastes the test regardless of the outcome. Spend the extra ten minutes writing the hypothesis properly before you spend two weeks running the test.