MVP has become one of those terms that gets applied to almost anything — often as a euphemism for "we didn't finish it" or "we ran out of budget." A half-built product shipped to customers isn't an MVP. A prototype that doesn't work isn't an MVP. An MVP is a specific, deliberate strategy for testing a business hypothesis with the minimum investment required to generate a valid result.
Getting it right is one of the most important skills in product development. Done well, an MVP saves you from building the wrong thing at full cost. Done poorly, it either tests nothing useful or damages the trust you're trying to build with early users.
What an MVP Actually Is
The concept was popularized by Eric Ries in "The Lean Startup," borrowing from Steve Blank's customer development methodology. An MVP is the smallest version of a product that can deliver the core value proposition to a specific user segment and generate learning about whether that value proposition is real.
The key word is "viable" — not just minimum. A viable product works. It delivers actual value to actual users. They can use it, and using it either confirms or challenges your hypothesis about what they need.
The minimum is in scope, not in quality. An MVP with important features missing but excellent quality in the features it does have is far more useful than a feature-complete product that's buggy and slow.
What an MVP Is NOT
- Not a prototype or mockup (unless your hypothesis is about interest, not usage)
- Not a beta version (a beta implies the core value is established; you're just refining it)
- Not a poorly built version of what you eventually want to build
- Not the cheapest thing you can ship to meet a deadline
- Not necessarily software — an MVP can be a manual process, a landing page, a concierge service
The Three Questions an MVP Must Answer
Before building anything, define what hypotheses you're testing. Every MVP should be designed to answer specific questions. Common fundamental hypotheses include:
- Problem hypothesis: Do potential users actually experience this problem frequently and painfully enough to seek a solution?
- Solution hypothesis: Does our proposed solution actually solve their problem in a way they find valuable?
- Business model hypothesis: Are users willing to pay for this? At what price? Through what payment model?
If your MVP can't test these specific hypotheses with the data it generates, either the MVP is poorly designed or your hypotheses need refinement.
The MVP Development Process
Step 1: Define Your User and Their Core Problem
Precision matters here. Not "small business owners" but "retail entrepreneurs with a single physical store who are manually tracking inventory in Excel." The more specifically you define the user, the more clearly you can identify the core value to deliver. Broad user definitions lead to broad MVPs that try to do too much.
Step 2: Identify the Riskiest Assumption
What single assumption, if wrong, would make your entire business model invalid? That's what your MVP should test. If you assume users will pay a subscription for this capability — test that. If you assume they'll change their existing workflow to use your product — test that. Don't test low-risk assumptions while leaving high-risk ones unvalidated.
Step 3: Determine the Minimum to Test That Assumption
Work backward from the assumption to the minimum capability needed to test it. Dropbox's MVP was a video demonstrating the product before it was built — because the assumption being tested was whether people wanted this capability, not whether it worked. Zappos' MVP was manually fulfilling shoe orders that "customers" placed through a website before building fulfillment infrastructure — testing whether people would buy shoes online.
"A Minimum Viable Product is not about building the smallest thing you can get away with. It's about designing the most efficient test of your most important hypothesis."
Step 4: Build with Quality Where It Matters for the Test
If you're testing whether users will purchase, the purchase flow must work flawlessly. If you're testing whether users return for ongoing use, the core value delivery must be solid. Identify which parts of the experience are critical for the hypothesis being tested and invest quality there. Everything else can wait.
Step 5: Define Your Success Metrics Before You Launch
Decide in advance what result would validate your hypothesis and what result would invalidate it. Don't make this judgment after seeing the data. Some commonly used validation metrics: activation rate, retention (D7, D30), Net Promoter Score from early users, conversion from trial to paid, and qualitative interview insights from power users.
Step 6: Launch to the Right Users
Early access users skew toward tech enthusiasts willing to tolerate rough edges. They're useful for feedback on the solution, but their behavior may not predict your eventual market's behavior. Supplement early access data with structured user research from your actual target segment.
Common MVP Mistakes to Avoid
- Building too much: Every feature beyond what's needed to test your hypothesis delays learning and adds complexity you may have to discard
- Building too little: If the MVP doesn't actually deliver the value you're claiming, failure doesn't tell you your idea is wrong — just that your MVP wasn't viable
- Wrong early users: Validating with friends and family who will politely use anything produces misleading signals
- Ignoring negative signals: Confirmation bias leads teams to explain away poor data. Negative results have value — they redirect you toward what will actually work
- No plan for what comes next: An MVP is not a strategy; it's a step. Know in advance what you'll do with validation, what you'll do with invalidation, and what you could learn that would change your direction
AdaptNXT helps product teams design and build MVPs that generate real learning quickly. Talk to us if you're planning your first product launch and want to validate your concept before full investment.
