How to Write a Hypothesis: Building Testable Assumptions
An experiment's quality cannot exceed its hypothesis's quality. A test run on "let's see what happens" gets interpreted as "not bad, keep going" no matter the result because what counts as success was never written down. The hypothesis is the contract that stops you from deceiving yourself: written before the experiment, carrying a measurable threshold, and falsifiable.
The Formula
"We believe [segment] will show [behavior/problem/response]. We'll consider it validated if [experiment] produces [measurable result + threshold]."
Examples:
- "We believe boutique fashion e-commerce stores rank return costs among their top 3 problems. Validated if at least 10 of 15 store-owner interviews put returns in the top 3."
- "We believe busy professionals will pay for weekly meal planning. Validated if 300 targeted landing page visitors produce an 8%+ email signup rate."
- "We believe operations managers spend 4+ hours a week on shift planning. Validated if at least 8 of 12 conversations report over 4 hours."
The Hypothesis's Four Mandatory Properties
- One assumption: "Customers have this problem AND will pay for our solution" is two hypotheses; test them separately. A compound hypothesis hides which part collapsed
- A measurable threshold: Not "if we see interest" but "8% signups" / "10 of 15 interviews" / "5 pre-payments". A threshold-free hypothesis gets fitted to any result afterward
- Falsifiability: "Some users may find it useful" can't be falsified it's compatible with every outcome. A good hypothesis carries its collapse condition explicitly
- Experiment match: The hypothesis type determines the evidence tool: problem hypothesis → interviews; demand hypothesis → landing page; payment hypothesis → pre-sales; usage hypothesis → prototype/MVP
Where Do Thresholds Come From?
Setting a threshold feels arbitrary at first; use three anchors: industry references (rough bands like 5%+ signups on cold traffic being good, 20% B2B demo→close being healthy), business model requirements (the minimum conversion your unit economics need computed backward from your CAC target), and comparative baselines (the first experiment's result becomes the floor for the next). There is no perfect threshold; a written, reasoned threshold beats an unwritten perfect one. Defining a grey zone below the threshold is legitimate too: 8% target, 5-8% means "revise and retry," below 5% means "pivot signal."
Extracting Assumptions: Where Do Hypotheses Come From?
Hypotheses are mined from your business model: every box of the Business Model Canvas is scanned with "how do I know this is true?" Every item without evidence for an answer is an assumption; assumptions are scored on the criticality (does the model collapse if wrong?) × uncertainty (is there evidence?) matrix, and the top-right corner (critical + uncertain) enters the test queue. The typical early-stage order: segment reality → problem severity → solution acceptance → willingness to pay → channel → unit economics. Skipping steps (testing payment before validating the problem) renders results uninterpretable.
FAQ
My hypothesis was proven wrong is that failure?
The opposite it's the experiment working exactly as designed: a falsified hypothesis is the cheapest information that ever saved you from months of building the wrong product. Lean startup accounting changes here: progress is validated learning, not code written. The critical discipline is the step after the collapse: why was it wrong (segment, problem, or solution?), what new hypothesis emerges, pivot or revision? Ignoring the falsified hypothesis and "just trying the experiment again" is data denial the most expensive founder mistake.
We nearly hit the threshold but missed (8% target, 7% result) now what?
Check sample size first: at small samples the 7-vs-8% gap is statistical noise extending the experiment with a bigger sample is legitimate (retroactively lowering the threshold to 7% is not). Second, read the qualitative layer: who signed up, which message variant did better, what were the objections? A borderline result is usually "hypothesis right, execution weak": one revision round of segment narrowing or message sharpening is the grey zone's standard answer. If you're still borderline after three revision rounds, read that as a strong no, not a weak yes.
How many hypotheses can I test at once?
Parallel experiments are tempting, under two conditions: the hypotheses must be independent (one's result shouldn't change the other's design), and each needs separate, non-contaminating measurement. The practical early-stage limit is 2-3: one qualitative track (interviews) + one quantitative track (landing page) is the classic, efficient pair. A team running five experiments simultaneously usually fills none of the samples and gets "inconclusive" from all few experiments, full samples, clear decisions.
Writing hypotheses feels bureaucratic is it really necessary in a small team?
The reverse: it's more necessary in a small team a big company has the resources to march months in the wrong direction; you don't. The practical format is one sentence + one threshold + one date a five-minute task. The return comes in three layers: decision clarity (when results land, there's a decision instead of a debate), team alignment (everyone knows what's being tested), and learning memory (the "we tried this, here's what happened" record six months later). The bureaucracy isn't the written hypothesis; it's the experiment repeated three times because it never was.