A precise, falsifiable statement of what will happen, why, and how you'll know. It's the bridge from understanding a problem to testing a solution — and turns a vague belief into something evidence can settle.
▸ Try the interactive toolA testable hypothesis is a precise, falsifiable statement that predicts what will happen when a specific change is made, why it will happen, and how the team will know whether the prediction was right. It's the bridge between discovery (understanding the problem) and delivery (building the solution) — and the thing that makes an experiment interpretable.
The defining property is falsifiability: a good hypothesis can be proven wrong. “Users will like the new design” can't fail (you can always find someone who likes it); “reducing the form to three fields will increase completion from 40% to 55%” either happens or it doesn't. A well-formed hypothesis names the change, the predicted effect with a number, the reasoning, and the success criterion — converting a vague belief into a prediction evidence can settle.
We believe [change] will cause [measurable effect] because [reasoning]. We'll know we're right if [specific, measurable success criterion]. — It must be possible to be wrong.
An untestable hypothesis can't lose, which means it can't teach. Vague predictions produce experiments whose results everyone interprets to confirm what they already believed.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Unfalsifiable claims | “Users will like it” can never be proven wrong, so it teaches nothing. | Falsifiable hypotheses can fail — which is what makes results meaningful. |
| No predicted magnitude | “It'll improve things” gives nothing to measure against. | A numeric prediction gives a clear pass/fail bar. |
| Missing the why | A prediction with no reasoning can't generalise to the next decision. | Stating why builds transferable understanding, not just a result. |
| Post-hoc interpretation | Without a pre-set success criterion, any result confirms the belief. | A pre-defined criterion prevents reading the result to suit the bias. |
Name exactly what you'll change and what measurable effect you predict — with a number. “Increase completion from 40% to 55%,” not “improve completion.”
Say why you expect the effect, grounded in research or insight. The reasoning is what lets you learn something transferable whether the test passes or fails.
State the specific, measurable result that would confirm the prediction — before running anything. This is what stops post-hoc rationalisation.
Ask: what result would prove this wrong? If you can't answer, the hypothesis isn't testable — rewrite it until a clear failure is possible.
A falsifiable hypothesis points to its test — a numeric behavioural prediction suits an A/B test, a demand prediction suits a fake door. The hypothesis comes first; the method follows.
A team's experiment plan read: “we think a redesigned onboarding will improve the user experience.” They ran a change, the numbers wobbled slightly, and everyone interpreted the ambiguous result as vindication — because the hypothesis couldn't fail, any outcome could be read as success.
Reframed as a testable hypothesis — “we believe cutting onboarding to three steps will raise first-week activation from 40% to 55%, because the current fourth step is where most users drop, and we'll know we're right if activation reaches 50%+” — the experiment suddenly had a clear pass/fail bar and a reason. The result either cleared 50% or it didn't, and either way the team learned something they could carry forward.
The deliverable is the structured hypothesis — change, predicted effect, reasoning, success criterion — written before the experiment runs.
| Element | Untestable | Testable |
|---|---|---|
| Prediction | “Users will like it” | “Completion rises 40% → 55%” |
| Reasoning | (none) | “…because step 4 is the drop point” |
| Success criterion | Decided after | Pre-set: “≥50% = confirmed” |
| Can it fail? | No | Yes — if it stays below 50% |
The test of a good hypothesis is whether it can be wrong. Falsifiability isn't academic pedantry — it's the practical property that lets an experiment change your mind instead of just confirming it.
The deepest function of a well-formed hypothesis is defeating confirmation bias before it strikes. When the success criterion is vague and set after the fact, any wobble in the metrics can be — and will be — read as vindication of what the team already wanted to believe. Pre-committing to a specific number and a clear pass/fail bar removes that escape hatch: the result is what it is, and “no effect” becomes a real, learnable outcome rather than a disappointment to massage. And the ‘because’ clause is what makes the learning compound — a hypothesis with reasoning teaches you something transferable about your users whether it passes or fails, while a bare prediction only ever tells you about that one change.
If no result could prove it wrong, it can't teach. Make failure possible.
“It'll improve” has no pass/fail bar. Predict a magnitude.
Post-hoc criteria let any result confirm the bias. Set the bar in advance.
Without reasoning, you learn a result but not a transferable lesson. Always state why.
Every A/B test (Tool 12) starts from a falsifiable hypothesis — no hypothesis, no interpretable test.
The riskiest assumptions (Tool 14) become the hypotheses worth testing first.
The hypothesis defines what a lean experiment (Tool 15) is trying to confirm or kill.
Like a problem statement (Tool 04 / Module 1), its power is precision and falsifiability over vague good intentions.
Take a vague product belief (“users would love a dark mode,” “this will boost engagement”). Rewrite it as: we believe [change] will cause [numeric effect] because [reason]; we'll know if [criterion].
Then check: what specific result would prove your new hypothesis wrong? If you can't name one, keep rewriting.
The moment you can state exactly what failure looks like, you've turned a belief you could never lose into an experiment that can actually teach you something.