TL;DR
An MVP is the smallest real test that proves whether customers care enough to act.
A buggy v1 is just the final product shipped early with missing features and more errors.
Fast tools make it easy to ship code quickly. An MVP prevents you from shipping code nobody needs.
Validate demand through real behavior — like paid pilots and signed commitments — not polite feedback.
What is an MVP?
The core minimum viable product definition is simple: it is the smallest thing you can build to test a risky assumption about your business. It is not a cheaper, broken version of your final software. An MVP exists to prove demand through real customer behavior before you spend months writing code.
Founders often say they are building an MVP. What they usually mean is they are building the final product, just thinner, buggier, and missing features. They reduce scope to make shipping cheaper.
Building feels like progress, but this is a trap. A true MVP does not try to look like finished software. It tries to answer one risky question. A good MVP reduces scope to make the learning clearer, not just to launch faster.
The Three Words
We hear the acronym so often we forget what the words mean in practice.
What does minimum mean in MVP?
Minimum means the least effort needed to learn. It does not mean the lowest quality. If your test requires a landing page, that page must work well enough to test the core offer.
What does viable mean in MVP?
Viable means the customer can feel the promised value clearly enough to react honestly. If the experience is completely broken, you learn nothing about demand. Users will reject the poor execution instead of judging the idea.
What does product mean in MVP?
A product is an offer or an experience. It is not always software. You can test a product manually.
MVP vs. Buggy v1
The easiest way to check your plan is to look at your goal. Are you trying to learn, or are you trying to sell early?
Criteria | True MVP | Buggy v1 |
|---|---|---|
Goal | Answer one risky assumption | Get a product to market fast |
Scope | One focused test of value | A stripped-down version of the vision |
Quality bar | High enough to test demand | Low enough to ship this month |
Customer signal | Real behavior and commitments | Polite feedback or frustration |
Example | Selling a service and delivering it manually | Coding a basic app that crashes |
For a deeper look at the core concept of validated learning, Steve Blank's customer development framework provides a strong foundation on testing hypotheses directly with customers.
How to Prove Demand Before Automation
Founders sometimes build because they are afraid to ask for money before the software exists. The most reliable way to test an idea is to secure proof of demand. This looks like paid pilots, revenue, signed letters of intent, design-partner commitments, or booked demos.
Feedback is weak. If you ask people what they think, they will give you polite lies. Actual behavior beats stated intent. As Rob Fitzpatrick explains in The Mom Test, you must learn to ask questions that reveal truth even when everyone is lying to you.
Consider a hypothetical concierge MVP. Imagine a founder wanting to test an AI-personalized workout product. Instead of writing code first, they sell a 14-day pilot to 15 real buyers. The personalized workouts are delivered manually through WhatsApp.
The goal is to measure willingness to pay. If after the pilot, 40% of the testers want to buy the £60 subscription, the founder has proved demand before they built the automation. The check is what demand proof the MVP created, not how many features shipped in the first version.
A good MVP has enough substance to attract early adopters and let them complete a core task. ProductPlan explains this balance in their guide to delivering early value. If you are struggling with what to include, reviewing a minimum viable product guide can help you decide what tests are worth running.
Riskiest Assumption Checklist
Keep the sequence simple when planning your test. Use this four-step checklist to validate your idea:
Identify the riskiest assumption: Find the hardest part of the business model to prove.
Design the smallest test: Build an experiment exclusively for that specific assumption.
Measure real behavior: Watch what customers actually do, not what they say.
Make a decision: Use the behavior data to decide whether to build the software.
You can read more about how MVP testing moves through the build-measure-learn cycle at Productboard.
FAQ
What does MVP mean in startups?
MVP stands for minimum viable product. In startups, it means the smallest experiment you can run to prove people want your solution. It is a tool for learning, not just the first version of your code.
If AI coding makes building instant, why plan an MVP at all?
Cheap building makes it easier to ship things nobody needs. An MVP targets the most painful customer problem to prove demand through behavior. If you skip the MVP phase, you risk spending your time optimizing features like dark mode for a product with zero paying customers. Fast coding raises the cost of skipping validation.
Does an MVP have to be a paid test?
Payment is the strongest signal when feasible. If you cannot charge money upfront, you need another form of hard commitment. This could be a signed design-partner agreement or a scheduled rollout. A free sign-up is rarely enough.
What happens if people reject the MVP?
If users reject the MVP, you have saved months of engineering work. This is the goal. To see why most tests fail and how to fix them, read about the common problems with the minimum viable product. A rejected MVP means your hypothesis was wrong, or your target audience was wrong. You adjust and test again.
