What Is an MVP — And Why Does Everyone Keep Talking About It?
MVP stands for Minimum Viable Product. You've probably heard the term, but it gets used so loosely that it's worth being precise about what it actually means — and more importantly, what it doesn't mean.
An MVP is the simplest version of your product that delivers enough value for real users to actually use it, gives you enough signal to learn whether your core assumptions are right, and costs as little as possible to build. That's it. It's a tool for learning, not a finished product. It's a way to find out whether the thing you think people want is the thing people actually want — before you spend six months and twenty lakhs building the full version.
Where the Term Comes From
The concept was popularised by Eric Ries in The Lean Startup, drawing on earlier work by Steve Blank on customer development. The core idea is that most product failures aren't engineering failures — they're assumption failures. The team built the wrong thing, or built the right thing for the wrong audience, or built something technically excellent that didn't actually solve a problem people cared enough about to pay for.
The MVP is a structured way to test assumptions before you build the full product. Build the smallest thing that lets you test whether your assumption is true. Show it to real users. Learn from what happens. Adjust. Repeat.
What an MVP Is Not
This is where most people get confused, so it's worth being direct:
An MVP is not a bad version of the product
The "minimum" in MVP refers to the feature set, not the quality. A minimum viable product should work properly and be pleasant to use. It just does fewer things than the eventual full product. If your MVP is buggy, slow, or confusing, you're going to get feedback about the quality, not about whether your core assumption is right.
An MVP is not a prototype
A prototype is typically a non-functional mockup used to test a concept. An MVP is real software that real users can actually use. It works. It might connect to a real database or it might use manual processes behind the scenes — but the user experience is functional.
An MVP is not always the cheapest option
Sometimes the minimum thing you can build to test your assumption is still substantial. A marketplace MVP still needs a working search, a working transaction mechanism, and enough listings to make it useful. "Minimum" is defined by what's required to validate the assumption — not by what's cheapest to build.
An MVP is not just for startups
Established companies use the same principle when launching new products or features. Building in small increments and validating with real users before full investment is sound practice at any scale.
What Goes Into an MVP
The right scope for an MVP depends entirely on what assumption you're trying to validate. The process of defining it starts with a question: what is the one thing I need to be true for this product to succeed?
For a B2B SaaS tool, the core assumption might be: "Operations managers at mid-sized logistics companies will pay for a dashboard that reduces their manual reporting time." To test that, you need enough of the dashboard to be functional that a real operations manager can use it in their actual workflow. You don't need every feature on your product roadmap.
For a marketplace, the core assumption might be: "There are enough buyers who want to purchase handmade jewellery directly from artisans, and enough artisans willing to list on a new platform." Testing that requires real buyers and real listings — not a full suite of CRM tools for sellers and a loyalty program for buyers.
The discipline of MVP development is the discipline of constantly asking: "Does this feature help us test our core assumption, or is it a nice-to-have that we're building because it's interesting?"
Common MVP Approaches
The Concierge MVP
You do manually, for a small number of real customers, what your product will eventually do automatically. An early version of a cleaning booking app might involve manually matching cleaners and customers via WhatsApp before building the matching algorithm. This is surprisingly effective — it lets you validate the core value proposition with almost no engineering cost.
The Wizard of Oz MVP
The user-facing experience looks automated, but it's actually humans operating behind the scenes. Early versions of several successful products used this approach — the user sees a polished interface, but the "AI" recommendation or the "smart" matching is actually a person. It tests whether users value the outcome before you build the automation.
The Single Feature MVP
Build one feature well, rather than many features poorly. This is the most common MVP approach for SaaS products — identify the single feature that delivers the most core value and build that to production quality. Everything else is post-validation.
The Landing Page MVP
Before building anything, create a landing page that describes your product, drives real traffic to it, and measures whether people sign up, click "buy", or take some other action that signals genuine interest. If nobody signs up despite real traffic, that's signal. If you get a strong conversion rate, that's also signal. This costs almost nothing and can validate (or invalidate) basic demand assumptions in weeks.
What Happens After the MVP
A successful MVP — one that generates clear learning, not just activity — leads to one of three outcomes: you continue building because the assumption was validated and you now know more precisely what to build; you pivot because the assumption was wrong but you learned something valuable about a related problem; or you stop because the evidence suggests the assumption was wrong and there's no clear pivot.
All three outcomes are good. The only bad outcome from an MVP is building one and not learning anything from it — which happens when the MVP wasn't actually tested with the right users, or when the team was so committed to the idea that they interpreted ambiguous results as validation.
Should You Build an MVP or Skip Straight to the Full Product?
The answer almost always favors the MVP approach, with one exception: when your assumptions have already been validated by significant market evidence. If you're building a product in a well-understood category, for a known user base, based on extensive customer research, some of the traditional MVP validation steps can be compressed. But if there's meaningful uncertainty about whether your core assumptions are right — and there almost always is — the MVP is the fastest and cheapest path to clarity.