Experiment Canvas
Design one specific, rigorous test for a single assumption, with a clear pass/fail threshold set in advance.
15 min · Developed within Lean Startup practice to structure individual experiments
What is this framework?
Once you know which assumption to test, the Experiment Canvas forces you to design the test properly: who you will observe, what behaviour counts as success, what number you need to see, and how long you will run it. Deciding these details before you run the test stops you from moving the goalposts afterwards.
A common failure in early-stage testing is running an experiment loosely and then interpreting whatever happens as a success. The Experiment Canvas prevents this by requiring the team to write down, in advance, exactly what result would count as confirming or rejecting the assumption.
The canvas separates the assumption (the belief being tested) from the hypothesis (a specific, measurable prediction), from the test itself (the concrete action you will take), and from the threshold (the number that determines the outcome). This separation stops vague thinking such as 'let's see how it goes' from creeping into what should be a rigorous test.
It also requires naming the target customer and the specific behaviour to observe, because evidence from the wrong audience, or evidence based on stated opinions rather than actual behaviour, is weak evidence even if the numbers look encouraging. Filling in the canvas honestly, before running the test, is what makes the resulting learning trustworthy.
What problem does it help solve?
- Forces a clear, falsifiable prediction instead of a vague hope
- Prevents shifting the definition of success after seeing the results
- Makes sure you are observing real behaviour from the right customer segment
- Creates a documented, comparable record across multiple experiments
- Speeds up decision-making because the pass/fail rule is already agreed
The framework
Fill every column before running the test, not after seeing the outcome.
Every part explained
Assumption
The underlying belief being tested, taken from your assumption map.
Ask: Which specific assumption is this experiment meant to test?
Example: Students will pre-pay for a food order to guarantee a faster pickup.
Hypothesis
A specific, measurable prediction derived from the assumption.
Ask: What precise outcome do I expect if the assumption is true?
Example: At least 20% of students offered the option will pre-pay within one week.
Test
The concrete action you will take to generate evidence.
Ask: What exact action will I take to produce real evidence?
Example: Offer a WhatsApp pre-order form to students queuing at the canteen for five days.
Target customer
The specific segment you are testing with, not 'everyone'.
Ask: Whose behaviour, specifically, am I observing?
Example: Students with back-to-back lectures between 12pm and 1pm.
Behaviour to observe and success metric
The concrete action that counts as evidence, and the metric that summarises it.
Ask: What will people actually do that proves or disproves the hypothesis?
Example: Completing a paid pre-order; metric is the percentage who do so out of those offered.
Threshold and timeframe
The number that determines success, and the period over which you will measure it, both set before the test runs.
Ask: What result, by when, will I accept as confirming this hypothesis?
Example: 20% conversion within five lunch periods.
Result, learning and decision
What actually happened, what you learned from it, and the concrete next action.
Ask: Did we hit the threshold, what does that tell us, and what do we do next?
Example: 27% conversion achieved; learning is that pre-payment is acceptable; decision is to test repeat usage next.
Worked example — CampusEats pre-order pilot
The team wants rigorous evidence on whether students will pre-pay for guaranteed pickup, not just casual interest.
Assumption
Students will pay in advance for a guaranteed fast pickup slot.
Hypothesis
At least 20% of the 100 students we contact will complete a paid pre-order within the trial week.
Test
Share a WhatsApp pre-order form with a fixed pickup time slot and RM3 priority fee to 100 targeted students.
Target customer
Second-year students with classes ending right before the lunch break.
Behaviour to observe
Completing payment and submitting the pre-order form, not just clicking the link.
Success metric
Percentage of the 100 contacted students who complete a paid pre-order.
Threshold
20% conversion (20 out of 100) within the trial week.
Timeframe
Five lunch periods over one week.
Result
27 paid orders completed out of 100 contacted, exceeding the 20% threshold.
Learning
Willingness to pre-pay is real and slightly stronger than expected among this specific segment.
Decision
Persevere, and design the next experiment to test whether these same students re-order in week two without reminders.
Because the threshold was fixed in advance at 20%, the team could not later argue that a lower result 'still counted' as success.
How to use it
- 1Pull the assumption to be tested from your assumption map.
- 2Write it as a specific, measurable hypothesis with a number attached.
- 3Design the smallest concrete test that could produce real evidence.
- 4Name the exact target customer segment you will test with.
- 5Define the precise behaviour that will count as evidence, not stated opinions.
- 6Set the success threshold and timeframe before running the test.
- 7Run the test exactly as designed, without changing the rules midway.
- 8Record the result, extract the learning, and make a decision.
Try it yourself
Complete a full experiment design for one assumption from your venture.
Experiment design
Your work stays on this device. Nothing is uploaded, so use the same browser to come back to it.
When to use it
- After Assumption Mapping has identified which assumption to test first
- Whenever a team is tempted to run a loose, undefined test
- Before spending money or significant time on a specific test
- When comparing results across several experiments and needing consistent records
When not to rely on it
This framework does not prove:
- • A well-designed canvas does not guarantee a well-run test if execution is sloppy
- • Setting an arbitrary threshold without reasoning behind it can still mislead
- • It works best for one assumption at a time and can become cumbersome for testing many at once
- • Overly rigid thresholds can cause teams to miss valuable, unexpected qualitative signals
Common mistakes
- Setting the threshold after seeing preliminary results, defeating the purpose
- Testing with the wrong or overly broad target customer
- Measuring stated intentions ('I would probably buy this') instead of real behaviour
- Skipping the timeframe, so the test runs indefinitely without a clear decision point
Connections
Related concepts
Related frameworks
Quick check
Why must the success threshold be set before the experiment runs?
Remember this
Decide what counts as success before you run the test, not after.