Skip to content
YibudYibud

Working document

Startup Validation Template — Fill It In Before You Build

Eleven sections, every field something you can fill in this week. Copy the page, work through it in order, and end with a documented go-or-stop decision.

Last updated · August 22, 2026

Run the free analysisOpen the checklist

Quick answer

What is a startup validation template?

A startup validation template is a fill-in document that turns a startup idea into a written record of its assumptions, evidence, experiments, and decisions. The reusable artifact at its core is a seven-column assumption table — one row per assumption, with the cheapest credible test, the evidence to observe, and the next decision — paired with a risk prioritization grid (impact × uncertainty), a five-question pre-commit checklist to run before each test, three labelled hypothetical examples, and a decision log that tracks every pass of the loop. The template is not a checklist (a list of yes/no questions) and it is not a report (a structured analysis of an idea). It is the working document you fill in yourself, the artifact your team, your investors, or your future self reads when you want to know what you thought was true and why.

Key takeaways

How to use this template

  • A template is a working document, not a checklist. Use it when you want to write down what you believe, what you have evidence for, and what you still need to test — not when you want a yes/no score.
  • The reusable assumption table is the main artifact. Each row is one assumption, the cheapest credible test, the evidence you expect to observe, and the next decision. The eleven sections below help you write the prose; the table is the working document you keep.
  • Risk comes from impact × uncertainty, not from how easy an assumption is to test. The riskiest assumption is the one whose failure would invalidate the rest of the plan — test that first.
  • Decide how to read the result before you run the test. Pre-commit to what counts as useful evidence, what would be inconclusive, what would trigger a re-run, and what would force a stop. A test without a decision rule is a launch in disguise.
  • End in the decision log. One row per decision, kept current: what you assumed, what you tested, what the evidence showed, what changed, and what to validate next. The template is reusable; the log is cumulative.

Template vs checklist vs report

Which one do I need?

Three tools, three jobs. Pick the one that matches what you are trying to do today.

Checklist

Use when you want to quickly verify that important validation areas have been considered. Read it once, tick the boxes, move on. Best for a sanity check before a build.

Open the checklist →

Template

Use when you want to document your assumptions, evidence, experiments, and decision. Read it once, then fill it in over days or weeks. Best for thinking through a new idea or pressure-testing an old one.

You are here

Report

Use when you want a structured analysis of one specific idea, with scores, named risks, and an MVP plan. Run a Startup MRI analysis in 60 seconds. Best for a defensible second opinion on a specific idea.

Run the analysis →

How to use this template

Work through it in this order

Validation is iterative. The loop below walks through one pass; the decision log at the end of the page tracks every pass after that.

  1. List assumptions

    Write every assumption the idea depends on into the reusable assumption table. One row per assumption.

  2. Rank by risk

    Score each row by impact and uncertainty. Test the high-impact, high-uncertainty row first — the one whose failure would invalidate the plan.

  3. Design the experiment

    Fill in the cheapest credible test, the evidence to observe, and the decision rule before you run anything. Use the eleven sections and the pre-commit checklist below.

  4. Run and record

    Run the experiment, log the evidence in the evidence log (section J), and write the learning as one falsifiable sentence.

  5. Update the decision log

    Append a row to the decision log: date, assumption tested, experiment, evidence, what changed, next decision. Start the loop again with the next assumption.

The reusable assumption table

One row per assumption, one decision per row

The table is the artifact the loop produces. Each row carries one assumption from hypothesis to decision. The eleven sections below help you write the prose inside each cell; the table is what you keep.

AssumptionWhy it mattersRisk if wrongCheapest credible testEvidence to observeResultNext decision
(your first assumption)(what depends on this being true)(what breaks if it is false)(smallest credible build)(behaviour, count, time window)(filled in after the test)(continue, change, or stop — written before the test)
(your second assumption)(what depends on this being true)(what breaks if it is false)(smallest credible build)(behaviour, count, time window)(filled in after the test)(continue, change, or stop — written before the test)
(your third assumption)(what depends on this being true)(what breaks if it is false)(smallest credible build)(behaviour, count, time window)(filled in after the test)(continue, change, or stop — written before the test)

The seven columns are a practical framework, not a universal standard. They work for any assumption; only the entries change.

1. Assumption

State the assumption in the form "we believe [customer] will [behaviour] when [condition]." If the sentence cannot be written, the assumption is not yet ready to test.

2. Why it matters

One sentence on what the rest of the plan depends on this assumption being true. The dependency, not the importance.

3. Risk if wrong

What breaks if this assumption turns out to be false. Be specific: which part of the plan fails, and how soon.

4. Cheapest credible test

The lowest-cost build that could realistically cause the named customer, in the named channel, to perform the named behaviour. A landing page, an interview, a concierge flow, a Wizard-of-Oz setup, a prototype, a paid pilot, or a small feature-scope MVP.

5. Evidence to observe

A specific action the customer takes — signing up, paying, returning, referring — that is countable and time-bounded. Opinion is not evidence.

6. Result

What the test actually showed, written after the fact. Strong evidence narrows the range of things you could still be wrong about; it does not predict success.

7. Next decision

What you will do next: continue with a narrower assumption, change the customer, change the channel, change the offer, or stop. Pre-commit to this before the test runs.

Risk prioritization

Test the assumption whose failure would invalidate the plan

Risk is impact multiplied by uncertainty. Two dimensions, not one. An assumption that is hard to test is not necessarily risky; an assumption that is easy to test is not necessarily safe. The framework below picks the next test by ranking every row in the assumption table on both axes.

Use this 2×2 to decide which assumption to test next. The quadrants are guidance, not a scoring formula; the call still depends on the context.

Uncertainty ·low
Uncertainty ·high
Impact ·high

High impact + low uncertainty

Verify efficiently. You believe it is true, but a small confirmation prevents a costly surprise later. One short test, not a multi-month study.

Test first

High impact + high uncertainty

Test first. This is the riskiest assumption — if it is false, the plan fails. The cheapest credible test is a short experiment, not a long build.

Impact ·low

Low impact + low uncertainty

Monitor. Move on; revisit only if a higher-impact assumption fails and forces a redesign.

Low impact + high uncertainty

Test later if relevant. Uncertain, but if wrong the plan still works. Return to it after the high-impact rows are settled.

The quadrant label is a direction, not a verdict. A solo founder with a $500 budget and a three-week runway treats the quadrants differently from a team with twelve months and $500,000. The label tells you what to test first; the size of the test is still up to you.

The validation framework

Eleven sections, one decision

The eleven sections below walk through one pass of the loop in order. Each section's output becomes the input to the next. By the time you reach section K, you have either documented enough evidence to decide to build, or a list of named unknowns to test next. The narrative explanation of the loop — Build → Measure → Learn and validated learning — lives in the Lean Startup Validation guide.

  1. A
  2. B
  3. C
  4. D
  5. E
  6. F
  7. G
  8. H
  9. I
  10. J
  11. K

  1. startupValidationTemplate.AEyebrow

    startupValidationTemplate.ATitle

    startupValidationTemplate.AIntro

    1. startupValidationTemplate.AQ1
    2. startupValidationTemplate.AQ2
    3. startupValidationTemplate.AQ3
    4. startupValidationTemplate.AQ4
    5. startupValidationTemplate.AQ5
    6. startupValidationTemplate.AQ6
    7. startupValidationTemplate.AQ7

  2. startupValidationTemplate.BEyebrow

    startupValidationTemplate.BTitle

    startupValidationTemplate.BIntro

    1. startupValidationTemplate.BQ1
    2. startupValidationTemplate.BQ2
    3. startupValidationTemplate.BQ3
    4. startupValidationTemplate.BQ4
    5. startupValidationTemplate.BQ5
    6. startupValidationTemplate.BQ6
    7. startupValidationTemplate.BQ7

    Problem-Solution Fit →

  3. startupValidationTemplate.CEyebrow

    startupValidationTemplate.CTitle

    startupValidationTemplate.CIntro

    1. startupValidationTemplate.CQ1
    2. startupValidationTemplate.CQ2
    3. startupValidationTemplate.CQ3
    4. startupValidationTemplate.CQ4
    5. startupValidationTemplate.CQ5
    6. startupValidationTemplate.CQ6
    7. startupValidationTemplate.CQ7

    Customer Discovery →

  4. startupValidationTemplate.DEyebrow

    startupValidationTemplate.DTitle

    startupValidationTemplate.DIntro

    1. startupValidationTemplate.DQ1
    2. startupValidationTemplate.DQ2
    3. startupValidationTemplate.DQ3
    4. startupValidationTemplate.DQ4
    5. startupValidationTemplate.DQ5
    6. startupValidationTemplate.DQ6
    7. startupValidationTemplate.DQ7

  5. startupValidationTemplate.EEyebrow

    startupValidationTemplate.ETitle

    startupValidationTemplate.EIntro

    1. startupValidationTemplate.EQ1
    2. startupValidationTemplate.EQ2
    3. startupValidationTemplate.EQ3
    4. startupValidationTemplate.EQ4
    5. startupValidationTemplate.EQ5
    6. startupValidationTemplate.EQ6
    7. startupValidationTemplate.EQ7

  6. startupValidationTemplate.FEyebrow

    startupValidationTemplate.FTitle

    startupValidationTemplate.FIntro

    1. startupValidationTemplate.FQ1
    2. startupValidationTemplate.FQ2
    3. startupValidationTemplate.FQ3
    4. startupValidationTemplate.FQ4
    5. startupValidationTemplate.FQ5
    6. startupValidationTemplate.FQ6
    7. startupValidationTemplate.FQ7

    Distribution Validation →

  7. startupValidationTemplate.GEyebrow

    startupValidationTemplate.GTitle

    startupValidationTemplate.GIntro

    1. startupValidationTemplate.GQ1
    2. startupValidationTemplate.GQ2
    3. startupValidationTemplate.GQ3
    4. startupValidationTemplate.GQ4
    5. startupValidationTemplate.GQ5
    6. startupValidationTemplate.GQ6
    7. startupValidationTemplate.GQ7

    Willingness To Pay →

  8. startupValidationTemplate.HEyebrow

    startupValidationTemplate.HTitle

    startupValidationTemplate.HIntro

    1. startupValidationTemplate.HQ1
    2. startupValidationTemplate.HQ2
    3. startupValidationTemplate.HQ3
    4. startupValidationTemplate.HQ4
    5. startupValidationTemplate.HQ5
    6. startupValidationTemplate.HQ6
    7. startupValidationTemplate.HQ7

    Product-Market Fit →

  9. startupValidationTemplate.IEyebrow

    startupValidationTemplate.ITitle

    startupValidationTemplate.IIntro

    1. startupValidationTemplate.IQ1
    2. startupValidationTemplate.IQ2
    3. startupValidationTemplate.IQ3
    4. startupValidationTemplate.IQ4
    5. startupValidationTemplate.IQ5
    6. startupValidationTemplate.IQ6
    7. startupValidationTemplate.IQ7

    MVP Validation →

  10. startupValidationTemplate.JEyebrow

    startupValidationTemplate.JTitle

    startupValidationTemplate.JIntro

    Evidence is useful when it reduces uncertainty. A customer interview reduces uncertainty by a small amount. A pre-order reduces it by a large amount. A second purchase reduces it the most. Stronger evidence narrows the range of things you could still be wrong about — it does not predict success, and no single signal guarantees an outcome.

    EvidenceSourceStrengthWhat it changes
    (your first claim and its evidence)(where the evidence came from)(weak / moderate / strong)(what this evidence forces you to update)
    (your second claim and its evidence)(where the evidence came from)(weak / moderate / strong)(what this evidence forces you to update)
    (your third claim and its evidence)(where the evidence came from)(weak / moderate / strong)(what this evidence forces you to update)
    (your fourth claim and its evidence)(where the evidence came from)(weak / moderate / strong)(what this evidence forces you to update)

  11. startupValidationTemplate.KEyebrow

    startupValidationTemplate.KTitle

    startupValidationTemplate.KIntro

    1. startupValidationTemplate.KQ1
    2. startupValidationTemplate.KQ2
    3. startupValidationTemplate.KQ3
    4. startupValidationTemplate.KQ4
    5. startupValidationTemplate.KQ5
    6. startupValidationTemplate.KQ6
    7. startupValidationTemplate.KQ7

Before you run the test

Define how to read the result before you see it

A test whose result cannot come back negative is not a test. Pre-commit to how each outcome would change the next decision. The five questions below turn an assumption into an experiment with a built-in decision rule.

  1. What assumption is being tested?

    One sentence. Use the format "we believe [customer] will [behaviour] when [condition]." If the sentence cannot be written, the assumption is not ready.

  2. What behaviour would support it?

    The countable, time-bounded action the customer would take that would reduce uncertainty. Opinion is not behaviour; commitment is.

  3. What behaviour would challenge it?

    The result that would make the assumption unlikely to hold. Polite disinterest is not a challenge; three customers in a row saying the same negative thing is.

  4. What result would be inconclusive?

    The outcome that would justify another experiment rather than a decision. Inconclusive is information: the test itself was wrong (channel, customer, or offer), not the assumption.

  5. What decision could change because of the test?

    Pre-write the next move for each outcome. The full set is six: continue, change the assumption, change the customer, change the solution, change the channel, or stop.

Decision thresholds are context-dependent. What counts as useful evidence for a $200 landing-page test is not what counts for a six-month engineering build. The shape of the rule is constant; the thresholds are yours.

Three hypothetical examples

Filled-in rows for three different validation problems

The examples below show the assumption table filled in for a B2B SaaS idea, a consumer product, and a marketplace. The numbers and customer segments are constructed to show what the framework looks like in practice; they are not descriptions of any specific real company. Adapt the assumption, the named customer, the experiment, and the decision rule to your own context.

Hypothetical illustrations, not case studies. The narrative version of the same framework — including the Build → Measure → Learn loop — is in the Lean Startup Validation guide.

B2B SaaS (hypothetical)

Property managers paying for automated monthly reporting

Assumption
Property managers with 10–50 units will pay $99/month for software that automates their monthly reporting.
Why it matters
The price point and payment behaviour are the load-bearing pieces — every other plan item follows from this being true.
Risk if wrong
No prior evidence of payment intent. The customer is reachable; the price is unproven.
Cheapest credible test
Five problem interviews, then a two-week concierge MVP using a shared spreadsheet and an email parser, delivered manually to up to three customers at the planned price.
Evidence to observe
Unprompted problem stories in interviews; first-invoice payment at the end of the concierge; active use past day seven.
Result
(Filled in after the test. Useful evidence: 3 of 5 interviewees describe the problem unprompted AND 2 of 3 concierge customers pay the first invoice.)
Next decision
(Filled in after the test. Continue with a narrower segment, change the price, change the customer, or stop.)

See worked examples in the Lean Startup Validation guide →

Consumer product (hypothetical)

Daily mindfulness app retention at a named frequency

Assumption
Adults who completed a paid meditation course will use a daily mindfulness app at least four days per week for at least eight weeks.
Why it matters
Retention at the natural frequency is what makes the unit economics work; without it, every other assumption falls apart.
Risk if wrong
The customer is identified; the retention frequency is unproven.
Cheapest credible test
Two-week prototype test with fifteen recruited users from the named segment, with a retention dashboard tracking daily opens, completed sessions, and day-7 return.
Evidence to observe
Day-1 retention, day-7 retention, day-14 retention. Frequency of completed sessions per active user.
Result
(Filled in after the test. Useful evidence: 8 of 15 users complete onboarding AND 4 of those return on day 7 AND 3 of those return on day 14.)
Next decision
(Filled in after the test. Continue with a narrower segment, refine onboarding, pivot to a different use case, or stop.)

See worked examples in the Lean Startup Validation guide →

Marketplace (hypothetical)

Two-sided acquisition through one paid channel

Assumption
Independent writers and small-business clients can both be acquired through the same initial paid social channel.
Why it matters
The single-channel assumption is the load-bearing piece — if wrong, both sides must be acquired separately and the unit economics change.
Risk if wrong
Single-channel acquisition has no prior evidence on either side.
Cheapest credible test
Six-week manual matching pilot. One ad campaign aimed at both sides, intake from both, matches by hand, three transactions per week, funnel recorded at each step.
Evidence to observe
Cost per qualified intake per side; quality of writer applications; completed vs failed transactions per week.
Result
(Filled in after the test. Useful evidence: cost per qualified intake on both sides within 2× of each other AND 6+ completed transactions in six weeks AND fewer than 2 failed transactions.)
Next decision
(Filled in after the test. Continue, change the channel for the underperforming side, change the customer definition, or stop.)

See worked examples in the Lean Startup Validation guide →

Validation decision log

One row per decision, kept current

The decision log is the cumulative artifact. The assumption table shows where you are now; the log shows how you got there. Each pass of the loop appends one row. The log is what makes the template reusable across multiple ideas and multiple passes.

DateAssumption testedExperimentObserved evidenceWhat changedNext decision
(date)(one-sentence assumption)(cheapest credible test that ran)(what the customer did, with count)(what this forced you to update)(next assumption or stop)
(date)(one-sentence assumption)(cheapest credible test that ran)(what the customer did, with count)(what this forced you to update)(next assumption or stop)
(date)(one-sentence assumption)(cheapest credible test that ran)(what the customer did, with count)(what this forced you to update)(next assumption or stop)
(date)(one-sentence assumption)(cheapest credible test that ran)(what the customer did, with count)(what this forced you to update)(next assumption or stop)

The log distinguishes what was assumed, what was observed, and what was decided. The distinction is the only thing the log provides — it does not guarantee better outcomes. A well-kept log is the most useful artifact a validation process produces.

After the template

What to do next

The template is the working document. The next steps depend on what the decision section in K says. If you have enough evidence to continue, narrow the scope and run the experiment in section I. If you do not, run a free Startup MRI analysis to see whether the riskiest section matches what you wrote.

  • Run the free analysis →

    60 seconds, no signup. The same 9-dimension framework, applied to your specific idea, with named risks and an MVP plan.

  • Read the validation hub →

    Nine pillars on problem, customer, solution, market, distribution, willingness to pay, product-market fit, MVP, and problem-solution fit.

  • Open the checklist →

    If you want a yes/no pass through the same nine areas, the checklist is the short version of this template.

  • Read a worked report →

    See what a finished Startup MRI report looks like before you submit your own.

  • Get a 7-Day Validation Action Plan →

    Submit your idea and the report ships with a 7-day plan derived from the riskiest assumption — each day an action, a purpose, and the evidence to collect.

FAQ

Frequently asked questions about the startup validation template

Short answers, in the same vocabulary the validation hub uses. Longer answers live in the linked articles.

What is a startup validation template?
A startup validation template is a fill-in document that walks through the idea, problem, customer, solution hypothesis, market, distribution, willingness to pay, product-market fit, MVP experiment, evidence log, and decision. Each section is a short set of prompts. The output is a working document you keep, not a score or a verdict.
What should a startup validation template include?
At minimum: the idea stated in one sentence, the problem stated specifically enough to disagree with, the customer named specifically enough to find, the solution described as a hypothesis, the market described by reachability not size, a named distribution channel, a named price and who pays, a measurable retention signal, a defined MVP experiment, an evidence log that cites every claim, and a written go-or-stop decision.
What is the difference between a startup checklist and a template?
A checklist is a list of yes/no questions you tick through quickly. A template is a working document you fill in over days, with paragraphs and evidence, not boxes. Use the checklist when you want a fast sanity check; use the template when you want a written record of what you believe and why.
How do I document startup validation evidence?
Keep an evidence log: a small table where every row is a claim, a source, a strength (weak / moderate / strong), and what the evidence forces you to change. Anything not in the log is an assumption, not evidence. The strongest evidence is what someone paid or committed to do, not what they said in a survey.
What should I test before building an MVP?
Before an MVP, you should have evidence for problem (people tell you they have it unprompted), customer (you can name a reachable segment), solution (your version beats the workaround on a named dimension), and market (you can describe the first 100 customers and the channel that reaches them). A free Startup MRI analysis scores the same four areas in 60 seconds.
How do I record customer validation?
Record the date, the person, the channel, the verbatim words they used, the behaviour you observed, and the commitment (if any) they made. Anecdotes without dates and quotes are not validation; they are stories you tell yourself. The evidence log in section J is the place to keep them.
What should I do when validation evidence is weak?
Treat it as information. Update the section that produced the weakest evidence, narrow the customer segment if the segment was too broad, change the price if the price was anchored, or replace the solution if the workaround is stronger. Do not collect more weak evidence and ignore it; update the document.
What is the difference between an assumption table and a decision log?
The assumption table is the current state: one row per assumption being tracked, with the cheapest credible test, the evidence to observe, and the next decision. The decision log is the cumulative history: one row per completed decision, with the date, the experiment that ran, the evidence it produced, what changed, and what was decided next. The table shows where you are; the log shows how you got there.
How do you prioritize which assumption to test first?
Rank every assumption by impact (how much damage if it is wrong) and uncertainty (how little evidence you currently have). The riskiest assumption is the one with high impact and high uncertainty — its failure would invalidate the rest of the plan. Test that first; verify the high-impact, low-uncertainty ones efficiently; monitor the low-impact ones.
Can AI help validate a startup idea?
AI can score the structured inputs you give it and surface the assumptions worth testing first. It cannot talk to your customers, run experiments, or commit real money. Use AI to identify the riskiest unknown; use customer conversations to test it. The template is the artefact AI cannot replace.
How often should a startup validation plan change?
Every time the evidence log or the decision log changes. The plan is not a document written once; it is the running record of what you currently believe, what you have evidence for, and what you will test next. If the next decision has not changed since the last pass, you are not actually running the loop.

Fill it in, then decide

The reusable assumption table is the current state. The decision log is the cumulative history. The next step is the cheapest experiment in section I — or a free Startup MRI analysis to confirm the riskiest assumption.

Run the free analysis →Read the validation hub →