Minimum Viable Test
Minimum Viable Test: Before building a product, spending money, or hiring a team, run the cheapest experiment that could prove your key hypothesis wrong. A landing page is cheaper than a product. A manual concierge service is cheaper than software. A cold email campaign is cheaper than a sales team. The goal: maximum learning per dollar and hour spent, with minimum commitment before validation.
What Is a Minimum Viable Test?β
The Minimum Viable Test (MVT) is a refinement of the Minimum Viable Product (MVP) concept from Eric Ries's Lean Startup framework. While the MVP is the smallest version of a product that can be shipped to real customers, the MVT is an experiment β often not a product at all β that tests the most important underlying assumption before building anything.
The distinction matters because most startup failures don't die from building the wrong product; they die from never validating whether the product would be wanted before spending 12β18 months building it. MVT asks: what is the specific hypothesis we're betting on, and what is the cheapest way to find out if it's true?
A food delivery startup might hypothesise: "Urban professionals will pay $9 for a curated meal kit delivered in 2 hours." The MVP is a fully functional ordering platform and fulfilment operation. The MVT is a landing page, a PayPal button, and the founder personally shopping and delivering orders to the first 20 customers β testing willingness to pay and demand density before building any technology.
MVT logic applies far beyond startups: corporate innovation teams testing new business models, product managers validating feature assumptions, and consultants piloting new services all benefit from the discipline of asking "what is the cheapest test of our most critical assumption?" before committing resources.
How It Worksβ
Step 1: State the hypothesis precisely
β "We believe [specific customer type] will [specific behaviour] because [specific reason]"
β Quantify: "pay $50/month," "refer at least 2 friends," "use feature 3x/week"
Step 2: Identify the riskiest assumption
β What single assumption, if wrong, would invalidate the entire plan?
β Common examples: willingness to pay, frequency of use, channel reach, unit economics
Step 3: Design the minimum test of that assumption
β What is the cheapest experiment that could disprove it?
β Can you simulate the experience without building it?
Step 4: Define success and failure criteria in advance
β "We will continue if X% of users do Y within Z days"
β Set criteria before seeing results (prevent goalpost-moving)
Step 5: Run the test with real people
β Friends and family don't count β they're too polite
β Real potential customers with real money at stake
Step 6: Interpret results honestly
β Did you prove or disprove the hypothesis?
β What did you learn that changes your plan?
Three Real-World Examplesβ
Dropbox Pre-Launch Videoβ
Before building Dropbox's cloud sync technology (a significant engineering challenge), founder Drew Houston created a 3-minute video demonstrating how the product would work. He posted it to Hacker News. Overnight, the beta waitlist grew from 5,000 to 75,000 users. The MVT: a video (not a product) testing whether the problem resonated and whether people wanted the solution. Cost: one day of video production. Value: proof of demand before 18 months of engineering.
This is the canonical MVT example because it so clearly separates hypothesis testing (do people want this?) from product building (can we build it?) β which are often wrongly conflated.
Airbnb First Customer Acquisitionβ
Brian Chesky and Joe Gebbia needed to validate that people would pay to stay in a stranger's home before building a marketplace. MVT: they put air mattresses in their San Francisco apartment during a design conference when hotels were full, listed it on a simple website, and rented it to 3 guests. Cost: $80 for air mattresses. Learning: people would pay, guests would stay with strangers, and hosts could earn meaningful income. This single test validated the core Airbnb hypothesis before any platform was built.
B2B SaaS Feature Validationβ
A product team at a B2B analytics company wanted to build AI-powered anomaly detection. The feature would take 3 months to engineer. MVT: the team manually ran anomaly analysis on data exports for 10 willing customers, emailing them a weekly report of flagged anomalies. Cost: 20 hours/week for 4 weeks. Learning: 7 of 10 customers found value; 3 made changes based on the anomaly reports; 2 asked if they could pay for the service. This validated both demand and willingness to pay before a single line of anomaly-detection code was written.
When to Use Itβ
β MVT is essential for:
- New product or feature concepts before significant investment
- Business model assumptions (pricing, channel, customer segment)
- Any project where the key risk is market/demand uncertainty rather than technical uncertainty
- Corporate innovation initiatives where stakeholder buy-in depends on evidence
β Less necessary when:
- Technical feasibility is the primary uncertainty (build a prototype instead)
- The hypothesis has already been validated by existing data
- The cost of the test exceeds the cost of the thing being tested
- Regulatory requirements make minimum viable tests impractical
| Pairs well with | Why |
|---|---|
| Scientific Method | MVT is the practical application of scientific hypothesis-testing in business |
| Falsification | MVT designs tests specifically to falsify critical assumptions |
| Working Backwards | Working Backwards defines what success looks like; MVT tests whether it's achievable |
| Cynefin Framework | MVT is the recommended approach for Complex domain problems (Probe β Sense β Respond) |
Common Misuses and Limitationsβ
Testing the wrong hypothesis. The most common MVT failure: testing a secondary assumption while the primary assumption (the one that would invalidate the whole plan if wrong) goes untested. Map out all key assumptions and rank them by risk β test the riskiest one first.
Using friends and family as test subjects. They give positive feedback to avoid hurting feelings. MVTs require genuine potential customers with genuine willingness to pay and genuine alternative options. "Would you use this?" from a friend is worthless; "Here's a payment link β does this solve your problem?" from a stranger is invaluable.
Declaring success from weak signals. "Two people signed up for our waitlist" is not validation of a business model. Define meaningful success criteria in advance: conversion rate, willingness to pay (with a payment required, not just interest), or usage frequency β depending on the hypothesis being tested.
Building too much before testing. "We need to build a polished prototype before we can test it." This is rarely true. Most demand-side hypotheses can be tested with smoke-and-mirrors prototypes, concierge services, or landing pages. The goal is to test with the minimum possible build.
Related Modelsβ
| Model | Relationship |
|---|---|
| Scientific Method | MVT applies scientific method to business decisions |
| Falsification | MVT is structured to falsify the most critical assumptions |
| Working Backwards | Working Backwards defines the destination; MVT tests whether you can reach it |
| Two-Way Door | MVTs convert big irreversible decisions into small reversible experiments |
Frequently Asked Questionsβ
What's the difference between an MVT and an MVP?
An MVP (Minimum Viable Product) is a product β the smallest version that can be shipped to real users and generate real feedback. It requires building something. An MVT (Minimum Viable Test) may not be a product at all β it could be a video, a landing page, a manual process, or a concierge service. The MVP tests "can we build something people will use?"; the MVT tests "is there a problem worth solving here at all?" In an ideal process, you run MVTs to validate the core hypothesis before committing to building even an MVP.
How do you determine which assumption is "riskiest" to test first?
Ask two questions: (1) If this assumption is wrong, does the entire plan fail? (2) How confident are we that this assumption is actually true? The riskiest assumption is the one that, if wrong, is most devastating AND that we're least certain about. Common candidates: willingness to pay (often assumed, rarely tested), frequency of use (often overestimated), customer segment size (often over-estimated via TAM analyses), and channel economics (cost-per-acquisition is often far higher than projected).
How long should an MVT take?
Long enough to get statistically meaningful signal, short enough to move quickly. For most B2C demand tests, 2β4 weeks with 100β500 potential customers provides actionable signal. For B2B enterprise tests, 6β8 weeks with 10β20 potential customers may be more appropriate given longer sales cycles. The target is: "How quickly can I find out if I'm wrong?" β usually faster than teams assume, if they're willing to test manually and imperfectly.
Further Readingβ
- Ries, E. (2011). The Lean Startup β the foundational text for MVT methodology
- Blank, S. (2013). The Startup Owner's Manual β customer discovery and validation frameworks
- Gothelf, J. & Seiden, J. (2013). Lean UX β applying MVT to product design
Apply with AIβ
π Design a minimum viable test for your hypothesis with MindMax β
This page is part of the MindMax Mental Models Knowledge Base.