An MVP, or minimum viable product, is the smallest version of a product that lets you test your core hypothesis with real users, not a smaller version of the whole finished thing. As of August 2026, after 15 years shipping products across healthcare, EdTech, and regulated systems, I still watch teams confuse the two, and build months of extra scope before anyone outside the company ever touches the thing. The term is older than the startup hype cycle around it. Frank Robinson used it in a product strategy context years before Eric Ries's The Lean Startup made it mainstream. The point was never speed for its own sake. It was learning the cheapest way possible, before you commit real engineering time to the wrong assumption.
What is an MVP in software development?
An MVP in software development is the smallest working version of a product built to test one core assumption with real users, not the smallest version of your finished vision. It ships fast, measures a real reaction, and tells you whether to keep building or change direction before you spend months finding out.
Here's what I keep coming back to: the word doing the work in that sentence is viable, not minimum. Minimum without viable is an unfinished product, nothing more. Viable without minimum is a slow, expensive way to learn the same thing.
I've watched teams build a beautiful, feature-complete first release and call it an MVP because it shipped early in the company's life. That's not what the term means. An MVP is defined by the hypothesis it tests, not by the calendar.
Why does the MVP pattern exist?
The MVP pattern exists because most product failure is a guessing problem before it's a building problem. Teams spend months of engineering time on features nobody asked for, then learn the mismatch after launch. An MVP moves that discovery earlier and cheaper, when a wrong guess costs weeks instead of a year.
The honest answer is that engineering time is the most expensive thing most product teams have. Every sprint spent building the wrong feature is a sprint you cannot get back, and a competitor you cannot out-guess forever.
The oldest version of this idea I know of, before either Robinson or Ries put a name on it, was a founder recording a short demo video of a product that did not exist yet, then measuring who signed up.
No code. Real signal.
That instinct, test the assumption before you build the machine, is the whole pattern.
How is MVP different from a prototype?
A prototype tests whether something can be built or how it should look, and it rarely touches real users or real data. An MVP is a real, working product released to real users to test whether they want it. A prototype answers a feasibility question; an MVP answers a demand question.
I use both, for different jobs. A clickable prototype tells you if a flow makes sense before you write a line of production code. It never leaves the building.
An MVP leaves the building on purpose. It has to, or it can't answer the question it exists to answer.
This is the same distinction I wrote about in emotionally intelligent design: a prototype can look right in a design review and still feel wrong in a real person's hands. You don't find that out until real users touch the real thing.
What's the difference between MVP and MLP (Minimum Lovable Product)?
An MVP proves people will use the thing enough to test your hypothesis. An MLP goes further and asks whether they love it enough to stay, tell a friend, or pay for it. MVP clears a validation bar; MLP clears a retention bar, and it almost always costs more to reach.
I think the MLP idea is a useful correction, not a replacement. Plenty of teams shipped a technically validated MVP that nobody enjoyed using, called the experiment a success, and then wondered why retention was terrible. Viable and lovable are different questions with different price tags.
Deciding which bar you're clearing, and being honest about which one you actually cleared, is a judgment call. It's the same kind of call I wrote about when I asked what AI has and hasn't replaced in software engineering: the tools can help you build either one faster. They can't tell you which one your team needs right now.
When shouldn't you build an MVP?
Skip the MVP pattern in regulated spaces, like medical devices or clinical workflows, where a half-built version can hurt someone before it can teach you anything. Also skip it when the demand question is already answered and the real risk is execution, not desirability. In both cases, minimum is the wrong axis to optimize.
I spent years in regulated health systems, where "ship the smallest thing and see what happens" is not a strategy, it's a liability. In that world, you validate the hypothesis a different way: paper workflows, closed pilots, stakeholders who can veto before code ships.
The MVP instinct is still there. The word "viable" means something stricter.
The same logic holds anywhere the cost of being wrong in public outweighs the cost of researching the answer in private.
So the honest definition is not "the smallest thing you can ship." It's the smallest thing that answers the question you're actually asking. Get the question wrong, and no amount of minimum saves you.
I write more about how I make these calls, and about the fifteen years of specific mistakes behind them, on the About page.