MVP: How to Build One That Actually Tests Your Riskiest Assumption
Most product teams get MVPs wrong. They either ship a half-finished product that embarrasses the brand, or they spend six months polishing features nobody asked for. The real purpose of a minimum viable product is neither of those things. It is a focused experiment designed to test the one belief that, if wrong, kills your entire product idea. According to CB Insights, 42% of startups fail because they build something nobody needs. An MVP, done correctly, is how you avoid joining that statistic.
This guide covers what a minimum viable product actually is, the five types of MVPs available to you, a step-by-step process for building one, and the mistakes that turn most MVPs into expensive wastes of time.
Table of Contents
- What is a minimum viable product?
- Why the MVP matters more than ever
- The five types of MVPs (and when to use each)
- How to build an MVP in six steps
- Real MVP examples worth studying
- The riskiest assumption test: a sharper alternative
- Common MVP mistakes that waste months
- MVP vs. prototype vs. proof of concept
- Frequently asked questions
What Is a Minimum Viable Product?
A minimum viable product is the simplest version of a product that lets you test your most critical business assumption with real customers. Eric Ries, who popularized the term through The Lean Startup, defined it as “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
The key phrase there is validated learning. An MVP is not a beta release. It is not a prototype you show to investors. It is a deliberate experiment with a specific hypothesis attached to it.
Here is what separates a real MVP from a rushed launch:
- A rushed launch ships incomplete features and hopes users figure out the value.
- A real MVP ships only what is needed to answer one question: “Will customers actually use this to solve the problem I think they have?”
The “minimum” in MVP refers to scope, not quality. Whatever you ship should work well enough that a negative result tells you something about demand, not about your execution.
Why the MVP Matters More Than Ever
The data on product failure has not improved over the past decade. CB Insights’ analysis of 431 VC-backed startup failures since 2023 found that the top reason is still the same: no market need. These companies raised a combined $17.5 billion before shutting down, with a median raise of $11 million.
The MVP exists to surface that “no market need” signal before you burn through your runway. Three reasons it matters more in 2025 and 2026:
Customer expectations are higher. Users compare every new tool to the best software they already use. A minimum viable product that looks and feels broken will not generate useful signal because customers will bounce before engaging with the core value proposition.
Build speed has accelerated. No-code platforms, AI coding assistants, and modular infrastructure mean teams can ship an MVP in weeks, not months. The bottleneck has shifted from “can we build this fast enough” to “are we testing the right thing.”
Funding requires traction data. Startups with a functional MVP and early user data are roughly three times more likely to secure pre-seed funding than those pitching a slide deck alone. Investors want evidence of demand, not just a vision.
The Five Types of MVPs (and When to Use Each)
Not every MVP requires writing code. The right format depends on what you are testing and how much you can invest before you need a signal.
1. Landing Page MVP
What it is: A single webpage describing your product, its value proposition, and a call to action (sign up, join waitlist, pre-order).
When to use it: When you need to test whether anyone cares about the problem before building anything. Ideal for validating demand at near-zero cost.
Example: Buffer launched with a landing page that described their social media scheduling concept. Visitors who clicked “Plans and Pricing” saw a second page asking for their email. The signup rate told the founders whether demand existed.
2. Concierge MVP
What it is: You deliver the product’s value manually, working directly with each customer instead of building automated systems.
When to use it: When you need to deeply understand the customer’s workflow before deciding what to automate. Works well for service-based products or complex B2B solutions.
Example: Food on the Table started by manually creating grocery lists and meal plans for individual families. The founder showed up at grocery stores, talked to shoppers, and did the work by hand before building any software.
3. Wizard of Oz MVP
What it is: The customer interacts with what appears to be a working product, but a human performs the work behind the scenes.
When to use it: When you need to test whether customers will pay for the outcome before investing in the technology to deliver it at scale.
Example: Zappos tested whether people would buy shoes online by photographing inventory at local shoe stores and listing it on a simple website. When orders came in, founder Nick Swinmurn went to the store, bought the shoes at retail, and shipped them. No warehouse, no inventory system, no logistics. Just a test.
4. Single-Feature MVP
What it is: A functional product built around one core feature, ignoring everything else.
When to use it: When you have identified one specific behavior that predicts whether the product will succeed. If that single feature does not generate engagement, additional features will not save you.
Example: Instagram launched as Burbn, a complex check-in app. The team noticed that photo sharing was the only feature people consistently used. They stripped everything else and relaunched with just photo sharing, filters, and a feed. The single-feature focus drove one million users in two months.
5. Piecemeal MVP
What it is: You simulate your product using existing tools (Notion, Typeform, Slack, Airtable, Zapier) stitched together without custom code.
When to use it: When existing tools can approximate your product’s workflow. This lets you run paid pilots and collect real usage data before committing engineering resources.
Example: A B2B onboarding tool could be tested using a Typeform intake survey, a Notion knowledge base, and Slack channels for support. If customers pay for and engage with that cobbled-together experience, you have validated the need.
How to Build an MVP in Six Steps
Step 1: Identify Your Riskiest Assumption
Every product idea rests on a stack of assumptions. Your job is to find the one that, if wrong, makes everything else irrelevant.
Common riskiest assumptions include:
- “Customers will pay to solve this problem” (demand risk)
- “Our solution is meaningfully better than their current workaround” (value risk)
- “We can deliver this at a cost that supports a viable business” (feasibility risk)
Write your riskiest assumption as a falsifiable statement: “We believe [target customer] will [specific action] because [reason].” If you cannot articulate the assumption, you are not ready to build.
Step 2: Define Your Success Criteria Before You Build
Decide what result would confirm or reject your assumption. Be specific: “50 signups from the landing page in two weeks” or “3 out of 10 pilot customers convert to paid.” Setting the bar before you launch prevents you from moving the goalposts when results come in soft.
Step 3: Choose the Right MVP Type
Match your MVP format to your assumption. If you are testing demand, a landing page is enough. If you are testing whether people will pay, you need a concierge or Wizard of Oz approach. If you are testing engagement with a specific interaction, build a single-feature MVP.
The rule: use the format that gives you a clear answer with the least work.
Step 4: Build Only What the Experiment Requires
This is where most teams go wrong. They start with the experiment and then add “just one more feature” until the MVP becomes a full product. Use your product roadmap to separate “what we are testing now” from “what we will build if the test succeeds.”
Scope your MVP to the experiment. If a feature does not directly contribute to validating your riskiest assumption, cut it.
Step 5: Ship to Real Customers and Measure
Put the MVP in front of actual users from your target segment. Not friends. Not colleagues. Not your advisory board. People who match your ideal customer profile and have the problem you are trying to solve.
Measure behavior, not opinions. What people do (sign up, complete onboarding, return the next day, pay) tells you more than what they say in a feedback survey.
Step 6: Decide, Do Not Drift
When results come in, make a clear decision:
- Proceed: The assumption held. Move to the next riskiest assumption and build the next increment.
- Pivot: The assumption failed, but you learned something that points to a different opportunity. Redefine and test again.
- Stop: The assumption failed, and there is no adjacent opportunity worth pursuing. Kill the idea before spending more.
The worst outcome is ambiguity, where results are neither clearly positive nor clearly negative, and the team drifts into building more without a clear signal. If your results are ambiguous, redesign the experiment to get a sharper answer.
Real MVP Examples Worth Studying
| Company | MVP Type | What They Tested | Result |
|---|---|---|---|
| Dropbox | Explainer video | Would people want file sync that “just works”? | 75,000 waitlist signups overnight |
| Airbnb | Landing page + manual fulfillment | Would travelers stay in a stranger’s home? | Three bookings at first conference validated demand |
| Zappos | Wizard of Oz | Would people buy shoes online without trying them on? | Orders confirmed willingness to buy sight unseen |
| Single-feature pivot | Was photo sharing the core value, not check-ins? | 1 million users in two months after stripping features | |
| Buffer | Landing page | Would people pay for scheduled social media posts? | Email signups confirmed pricing tier interest |
Each of these teams tested one specific assumption before building the full product. None of them launched with a complete feature set.
The Riskiest Assumption Test: A Sharper Alternative
Some product leaders, including Ries himself in later writing, have moved toward the Riskiest Assumption Test (RAT) as a more precise framing than MVP.
The difference is emphasis. An MVP asks “What is the minimum product I can build?” A RAT asks “What is the fastest way to test the assumption most likely to be wrong?”
The RAT approach works well when your biggest risk is not demand but something more specific:
- Technical feasibility: Can we actually build this at the required performance level?
- Channel viability: Can we reach enough customers through the channels we have?
- Willingness to switch: Will users abandon their current solution for ours?
The test does not have to look like a product at all. It might be a customer discovery interview with ten potential buyers, a pricing page experiment, or a prototype tested in person. What matters is that it directly addresses the assumption most likely to kill the idea.
A practical approach: use the RAT to identify what to test, then choose the MVP type best suited to run that test.
Common MVP Mistakes That Waste Months
Mistake 1: Building a “Minimum” Product Instead of a Minimum Experiment
When “minimum” becomes an excuse to ship something sloppy, you learn nothing. If the experience is so broken that users bounce immediately, a negative result does not tell you whether the problem exists. It tells you that your test was poorly designed.
Mistake 2: Testing Multiple Assumptions at Once
If your MVP tests demand, usability, and pricing simultaneously, you will not know which variable drove the result. Test one assumption per MVP cycle. Stack them sequentially.
Mistake 3: Ignoring the “Viable” in MVP
Viable means the product must actually work for the use case you are testing. A meal planning MVP that only covers dinner recipes is viable. A meal planning MVP that crashes when you try to save a recipe is not.
Mistake 4: Skipping the Success Criteria
Without predefined success metrics, every result becomes “encouraging.” Teams interpret 12 signups as “early traction” and keep building without evidence. Define what success looks like before you launch, and hold yourself to it.
Mistake 5: Treating the MVP as the Product
An MVP is a learning tool, not the foundation of your production codebase. Plan to throw it away. The code, the design, the infrastructure, all of it. What you keep is the knowledge about what customers want. Then you build the real product with that knowledge.
MVP vs. Prototype vs. Proof of Concept
These terms get used interchangeably, but they serve different purposes:
| MVP | Prototype | Proof of Concept | |
|---|---|---|---|
| Audience | Real customers | Internal team or stakeholders | Technical team |
| Purpose | Validate market demand | Test usability and interaction design | Confirm technical feasibility |
| Fidelity | Functional (must deliver real value) | Can be non-functional (clickable mockup) | Can be rough (code spike, benchmark) |
| Feedback type | Behavioral data from real usage | Qualitative usability feedback | Technical performance data |
| Outcome | Go/no-go on the business case | Refined UX for development | Confidence that the solution is buildable |
A typical product development flow might look like this: proof of concept (can we build it?) then prototype (will users understand it?) then MVP (will customers pay for it?). Some teams skip steps depending on where their biggest risk sits. If the technology is proven and the UX is straightforward, go straight to an MVP to test demand.
For a deeper look at how to structure this progression within your product discovery process, the key is matching each stage to its corresponding risk.
Frequently Asked Questions
What is a minimum viable product (MVP)?
An MVP is the simplest version of a product that lets you test your most critical assumption with real customers. It is not a half-built product. It is a deliberate experiment designed to generate validated learning about whether customers actually need what you are building, with the least effort possible.
What is a good example of a minimum viable product?
Dropbox validated demand for cloud file sync by releasing a three-minute explainer video before writing production code. The video showed how the product would work, and 75,000 people signed up for the waitlist overnight. That signal confirmed demand without building the actual sync engine.
How is an MVP different from a prototype?
A prototype tests usability with internal stakeholders or test users. An MVP goes to real customers in a real market to test whether they will actually use and pay for the product. Prototypes generate design feedback. MVPs generate market evidence.
How do you decide what features go into an MVP?
Start with your riskiest assumption, the belief about your customer or market that would kill the product if wrong. Include only the features required to test that assumption. Everything else is scope creep. If a feature does not contribute to validating or invalidating your hypothesis, cut it from the MVP scope.
How long should it take to build an MVP?
Most effective MVPs ship within four to twelve weeks. If your MVP is taking longer, you are probably including features that are not essential to the experiment. The goal is speed to learning, not speed to a polished product. Landing page and concierge MVPs can launch in days.