Testable Hypotheses
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 toolThe framework
A 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.
Try it yourself
What it prevents
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. |
Step by step
State the change and predicted effect
Name exactly what you'll change and what measurable effect you predict — with a number. “Increase completion from 40% to 55%,” not “improve completion.”
Add the reasoning (the ‘because’)
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.
Define the success criterion in advance
State the specific, measurable result that would confirm the prediction — before running anything. This is what stops post-hoc rationalisation.
Check it can be falsified
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.
Match it to the right test
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 short illustration
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 hypothesis statement
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% |
Why it matters
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.
Common mistakes
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.
When not to use it
- Pure open exploration. Early generative research isn't hypothesis-testing — don't force premature precision onto discovery.
- Trivial, reversible changes. A tiny copy fix doesn't need a formal hypothesis.
- As bureaucracy. The hypothesis should sharpen thinking, not generate paperwork — keep it lean.
Where this sits in the toolkit
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.
Make an unfalsifiable belief testable
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.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.