Validate a belief with the minimum possible investment. Assumption mapping says what to test, hypotheses say what counts as proof — the lean experiment is how you get the evidence cheaply.
▸ Try the interactive toolThe Lean Experiment Framework is a structured approach to validating assumptions with the minimum possible investment of time and engineering. Where assumption mapping (Tool 14) identifies which beliefs to test, and testable hypotheses (Tool 13) define what each test must establish, the lean experiment is how you get the evidence — as cheaply as possible.
The guiding principle is to spend the least required to learn the most. Each experiment pairs a falsifiable hypothesis with the cheapest method that could disprove it and a clear success criterion set in advance. The framework forces you to ask “what's the smallest thing we could build or do to learn this?” — which is almost never “build the feature and see.” It connects the three experimentation tools into a loop: map → hypothesise → experiment → learn → re-map.
Hypothesis (falsifiable, with a success criterion) → cheapest test that could disprove it → run with a pre-set bar → learn (confirm/kill) → feed back into the assumption map. Minimise investment per unit of learning.
The default way to test an idea — build it and watch — is the most expensive possible experiment. Lean experiments exist to find a far cheaper path to the same learning.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Building to learn | Shipping the feature to test demand is the priciest experiment there is. | The framework finds the cheapest test that answers the same question. |
| No success criterion | Without a pre-set bar, any result confirms the bias. | Each experiment sets its pass/fail criterion in advance. |
| Testing the wrong thing | Experiments run on comfortable beliefs, not risky ones. | It's driven by the assumption map's danger quadrant. |
| One-off experiments | Tests that don't feed back into the plan waste their learning. | The loop feeds every result back into the assumption map. |
Take the highest-importance, lowest-evidence belief from the assumption map. That's what this experiment exists to test — not whatever's easiest.
State the prediction, the reasoning, and the success criterion in advance (Tool 13). The experiment is meaningless without a clear bar for what would confirm or kill the belief.
Match the method to the question and pick the lowest-cost option — a fake door for demand, a prototype for usability, a concierge test for value. Ask: what's the smallest thing that gives a real signal?
Execute the test as designed, to the pre-set sample or duration, without moving the goalposts. Resist the urge to read an early or ambiguous result as the answer you wanted.
Confirm or kill the assumption, then feed the result back into the assumption map — which usually surfaces the next belief to test. Discovery is a loop, not a one-shot.
A team wanted to know whether users would adopt a substantial new capability. The instinct was to build a working version and measure usage — weeks of engineering to get an answer. Running it as a lean experiment, they asked the cheaper question: what's the smallest thing that would give a real demand signal?
The answer was a fake door plus a brief concierge follow-up — a fraction of the cost, delivering a clearer signal in days. Demand turned out to be far weaker than assumed, and they'd learned it before writing production code. The expensive build-to-learn approach would have reached the same conclusion months later and far more painfully.
The deliverable is a one-card-per-experiment record: the assumption, the hypothesis, the chosen cheap method, the success criterion, and the result.
| Element | Purpose |
|---|---|
| Assumption tested | From the map's danger quadrant |
| Hypothesis + criterion | Falsifiable, with a pre-set bar |
| Method (cheapest viable) | Smallest test that gives a real signal |
| Result → next step | Confirm/kill, then re-map |
Learning is the goal; building is just one — usually the most expensive — way to learn. The lean experiment reframes every validation question as “what's the cheapest thing that could prove this wrong?”
The framework's power is that it connects the experimentation tools into a system rather than leaving them as isolated techniques. Assumption mapping supplies the what (the risky belief), testable hypotheses supply the standard of proof, and the lean experiment supplies the cheapest method — then the result loops back to update the map and surface the next test. A team running this loop continuously retires risk in order of lethality, at minimum cost, and never falls into the trap of building the thing just to find out whether the thing was worth building.
If the experiment costs as much as the feature, it isn't lean. Find the cheaper signal.
Without a pre-set bar, you'll read the result to suit your hopes. Set it first.
Let the assumption map, not convenience, choose what to test.
An experiment whose result doesn't update the plan wasted its learning. Re-map.
The map's danger quadrant (Tool 14) sets the experiment agenda.
Each experiment validates a falsifiable hypothesis (Tool 13).
Fake doors, prototypes, pretotypes, usability tests (Tools 16–19) are the cheap methods it deploys.
Choosing the cheapest viable method is the same instinct as matching prototype fidelity to the question (Module 1, Tool 10).
Take a product belief you'd normally validate by building something. Write it as a hypothesis with a success criterion.
Now brainstorm three ways to test it without building the real thing — a fake door, a manual concierge version, a prototype. Pick the cheapest that gives a genuine signal.
If one of your no-build tests would answer the question in days instead of weeks, you've just seen why “build it and see” is the most expensive experiment of all.