ProcessBusiness Building
How to run a venture validation sprint that ends in a real decision
A validation sprint buys evidence before a new venture gets a team and a budget. It turns an idea into a few testable assumptions, runs the cheapest test that could credibly disprove each one, and ends with a written decision to proceed, pivot or stop. Below is the method step by step, with the extra feasibility checks AI and distributed-ledger ventures need.
On this page
- What a validation sprint buys, and what it leaves for later
- The sprint as a chain of decisions
- Running the sprint, step by step
- Matching each assumption to the cheapest credible test
- Asking about past behavior instead of future intent
- Extra feasibility checks for AI and distributed-ledger ventures
- Proceed, pivot or stop: what the decision memo recommends
- Questions and answers
- Sources
What a validation sprint buys, and what it leaves for later
A validation sprint is a short, time-boxed piece of work whose only product is evidence. It finds out, as cheaply as possible, whether the beliefs a new venture depends on are true before anyone hires a team or writes production code. The asymmetry is the point: a week of interviews costs little, while a year spent building the wrong product can cost the venture itself.
In ColdAI's studio method the sprint follows thesis development and comes before any significant commitment of people or money: the team interviews potential customers, builds minimal products and tests core assumptions first1. The sprint answers whether the problem is real, whether the proposed solution addresses it and whether the venture is feasible. It does not prove fit, which needs paying customers over time (see how to measure product-market fit), and it only roughly tests price, which has its own research methods.
The sprint as a chain of decisions
- Write the hypothesis
Customer, problem, current alternative and why now.
- Map assumptions
What must be true for customers to want it, pay for it and for the team to build it.
- Rank by risk
Order assumptions by how damaging and how unproven each one is.
- Match cheap tests
The least expensive test that could credibly disprove each top assumption.
- Fix pass marks
Write down what counts as a pass or a fail before testing.
- Run and log evidence
Raw evidence kept apart from the team's interpretation.
- Decision memo
Proceed, pivot or stop, and what each option needs next.
Running the sprint, step by step
Write the venture hypothesis
Describe the customer, their problem, what they use today and why the venture is possible now, in a paragraph anyone on the team could repeat. If the team cannot agree on it, the sprint is not ready to start.
Map assumptions across desirability, viability and feasibility
Desirability: do customers have the problem and want this answer to it? Viability: will someone pay enough, through a channel the venture can afford? Feasibility: can the team build and operate it, legally and with the data it needs? Write each assumption so it can be proven wrong: “claims handlers spend most of their day re-keying data”, not “insurers want efficiency”.
Rank the assumptions
Score each on two questions: how badly would the venture suffer if this were wrong, and how little evidence exists today? Assumptions that score high on both are the sprint's scope; everything else waits.
Match each assumption to a test
Choose the cheapest test that could produce a convincing answer, using the table below. A test that asks for a commitment beats one that asks for an opinion.
Set pass and fail thresholds
For each test, write down which result means pass, which means fail and what sits in between, before it runs. For example: most interviewed buyers describe the problem without prompting, or a stated share of pilot candidates sign a priced letter of intent.
Run the tests and keep an evidence log
Record raw evidence such as interview notes, sign-up data and spike results in one shared log, apart from interpretation, and review it together each week so the most memorable interview does not set the agenda.
Write the decision memo
Compare results with the thresholds, say which assumptions passed, failed or remain open, and recommend proceed, pivot or stop. Someone outside the sprint team decides.
Matching each assumption to the cheapest credible test
| Test | Best for testing | Strong signal | Watch out for |
|---|---|---|---|
| Problem interviews | Whether the problem exists, how often it occurs and what it costs today | Buyers describe the problem unprompted and show you their workaround | Leading questions and polite enthusiasm about a future product |
| Smoke test (landing page or fake door) | Whether a defined audience responds to the value proposition | Qualified visitors request access or leave details, not just click | Traffic from the wrong audience; low B2B volumes make rates noisy |
| Concierge MVP | Whether delivering the outcome by hand solves the problem | Customers come back for a second round and ask for more | Confusing gratitude for personal attention with demand for a product |
| Wizard-of-Oz MVP | Whether people use an interface whose automation is done by hand behind the scenes | Repeat use without reminders | Honesty about manual processing, and protecting the data staff handle |
| Letter of intent or paid pilot | Whether buyers will commit budget | A signed, priced commitment with named success criteria | Letters with no price attached; free pilots that never convert |
| Technical spike | Whether the hardest technical step works with real inputs | It works on the customer's own data at acceptable quality and cost | Demonstrating on clean sample data that production will never see |
Run the cheapest test that could change your mind; if it cannot give a convincing answer, move up to a commitment-based test.
Asking about past behavior instead of future intent
Extra feasibility checks for AI and distributed-ledger ventures
AI and shared-ledger ventures carry feasibility risks that interviews cannot reveal. Test them inside the sprint, not after the build starts.
Proceed, pivot or stop: what the decision memo recommends
- If
The riskiest assumptions met their pass marks and some buyers made priced commitments
ThenProceed: fund the build stage, and carry any assumptions still open into the next gate's criteria.
The evidence now justifies people and money; the rest can be tested while building.
- If
The problem held up, but the proposed solution or target segment failed
ThenPivot: rewrite the hypothesis around the segment or solution that showed pull, and rerun a shorter sprint on what changed.
Most of the evidence still stands.
- If
The problem did not hold up, or a blocker such as data rights or regulation has no realistic path
ThenStop: record what was learned and release the team and budget.
Building cannot fix a problem customers do not have or a product that cannot legally operate.
- If
Results are ambiguous because the tests were too weak to fail
ThenDo not call it a pass; rerun with a commitment-based test rather than more interviews.
Weak tests produce weak evidence in both directions.
Questions and answers
How long should a venture validation sprint last?
Long enough to run a credible test on each top-ranked assumption, and short enough that the team cannot drift into building the product. The right length depends on how quickly you can reach buyers and data. Fix the end date at the start; any extension is the sponsor's decision, with a stated reason.
How many customer interviews are enough during venture validation?
Stop when new interviews within the target segment stop changing what you believe. If every conversation surfaces a different problem, the segment is too broad; narrow it before interviewing more. Interviews show whether a problem exists and how people handle it today, but not willingness to pay, which needs commitments such as priced letters of intent or paid pilots.
Is a validation sprint the same as a design sprint?
No. A design sprint, the workshop format popularized by Google Ventures, compresses the design and user testing of one solution concept into a few days. A validation sprint tests a venture's riskiest assumptions across desirability, viability and feasibility and ends with a funding decision. A design sprint can be one of its tests when the open question concerns the solution.
Can a corporate innovation team run a validation sprint inside a large company?
Yes, with some protection. Run smoke tests under a separate brand so results reflect the offer rather than the parent's reputation, approve one letter-of-intent template rather than one per customer, and have a venture board, not the annual budget process, make the decision. Data is often easier to reach in a large company, but confirm it may be used for the new purpose.
Sources
- Business Building: venture studio approach, including the Validation Sprint step — ColdAI
- Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) — EUR-Lex · checked 10 October 2026
- Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA) — EUR-Lex · checked 10 October 2026