What Is a Minimum Viable Product?

A team ships an app with one working feature and no settings page, and calls it an MVP. Six weeks later, nobody has used it twice. The product was small, but it wasn't a test.

A minimum viable product is the smallest working version of a product that can tell you whether people want it. The word that does the work is learning, not smallness. Many teams get this backwards.

The cost shows up in two ways. Some teams cut so much that the product can't answer any question. Others build so much that answering one takes a year. Either way, the money goes on a release that teaches them little.

This article is for the founder or product lead about to scope a first release. It explains what the term means, what belongs in an MVP, and how it differs from a prototype.

Key Takeaways

• A minimum viable product is the smallest working version of a product that real users can use, built to learn whether they want it.
• "Minimum" describes scope, not quality. What you include should work properly, because a broken experience can't teach you anything.
• An MVP differs from a prototype (a simulation), a proof of concept (a technical test) and a minimum marketable product (the version built to sell).
• MVPs take many forms, from a landing page to a manual service to a single feature, and the cheapest form that answers your question is usually right.
• To decide what goes in, start with one problem and one user, then cut anything the core workflow can run without.

What Is a Minimum Viable Product?

MVP stands for minimum viable product, a term from Lean Startup. It's the smallest working version of a product that real users can use. Its job is to find out whether they want it.

Eric Ries popularised the idea in 2009. Ries's original 2009 definition is still the clearest one. The MVP is the version of a new product that lets a team collect the most validated learning about customers for the least effort.

Learning is the point.

Ries added a caveat straight away. Despite the name, an MVP isn't about producing a minimal product. His MVP definition uses the words maximum and minimum, which means it takes judgement rather than a formula.

That's why two MVPs for the same idea can look nothing alike. One is a landing page and the other is a working app. And both can be right. But the judgement is where teams often go wrong.

What Makes an MVP Viable

Viable means a real user can complete a real task and get real value from it. A workflow that only works in a demo doesn't count. That's a prototype.

But the Agile Alliance glossary lists the common pitfalls. Teams treat the smallest possible feature set as the goal. They don't ask whether it's enough to learn from. They stress the word minimum and forget the word viable. The release ends up too rough to show whether people would use it. And some teams ship once and never change anything, whatever feedback arrives.

Minimum describes scope, not standard. What you include should be built to a production standard, because users can't teach you anything from a broken experience.

Every MVP also needs a question. Write it as a hypothesis: we believe this user will do this, for this reason. Then write down the result that would count as a no. Without that line, teams find reasons to carry on whatever the data says.

Why Teams Build an MVP

Because building the wrong thing is the expensive mistake.

An MVP puts a working product in front of real users before the full build. And the team finds out early whether the idea has pull. The Agile Alliance glossary names the main benefit as understanding customer interest without fully developing the product.

But the direct saving isn't the only one. The benefits of MVP development include faster feedback and a smaller bet on an unproven idea.

Types of MVP

An MVP isn't always software. The form should match the question you need answered. But six types are worth knowing.

And single-feature is the default shape for most software MVPs. But each of the others is a cheaper way to test one specific doubt. Choosing between them is one decision inside the wider MVP development process.

What Goes Into an MVP

Start with the problem, not the feature.

Someone says the product needs a dashboard, and the conversation jumps to what it shows. The better starting point is the problem the dashboard would solve. Who has it, how often it happens and what it costs them decide whether it belongs.

For every proposed feature, ask what user problem it solves. If the honest answer is that you assume users have it, that's a hypothesis. Hypotheses belong in a product validation plan, not in the build.

Then pick one user and one core workflow. The MVP features are whatever a real person needs to finish that workflow and get real value from it. Everything the workflow can run without gets cut.

Analytics dashboards, settings pages, user profiles, admin tools and reporting exports are the usual first cuts. And most go on a roadmap for later. The test is blunt: if the core workflow still works without it, it isn't in the first release.

But the exception is anything that makes the workflow trustworthy, such as security, data handling and basic error states. In our experience, teams that agree the list in writing before building end up with a shorter backlog. They also have fewer arguments about it.

Once you know what's in, the next job is how to build an MVP. That means holding the line on scope.

MVP vs Prototype vs Minimum Marketable Product

An MVP sits between the things that come before it and the things that come after.

A prototype is a simulation. People click through screens, but nothing real sits behind them. It tests whether they understand the product. But it doesn't test whether they'd use it. The MVP vs prototype difference comes down to opinion versus behaviour.

A proof of concept is a technical test for the internal team. It answers whether something can be built. And its code is usually thrown away.

A minimum marketable product comes after the MVP. The Agile Alliance glossary separates them by focus. An MVP is about learning. A minimum marketable feature or product is about earning. A minimum marketable product is the version built to sell repeatedly to the segment the MVP proved.

Whether the MVP earned that next step shows up in product market fit. You can start measuring it with a few dozen survey responses.

An MVP Example

MVPs come in many shapes. A landing page with a pre-order button is one. A service delivered by hand to ten customers is another. And a single working feature is a third.

Classic Informatics built RoamingDuck as a travel planning MVP that connects travellers with experts and friends. Its capabilities were itinerary building, budgeting and document management. That's a short list for a travel product. But it's the shape a scoped MVP takes.

What makes each of these an MVP isn't the size. It's the purpose: a real test of demand, at the lowest cost that still gives a fair answer.

Let's Sum Up!

A minimum viable product is a test, not a smaller version of the finished product. The scope is small because the question is narrow. And the quality is high because a broken test teaches you nothing.

Get those two things right and the rest of the decisions get easier. Write the question, cut to the core workflow, and build that part properly.

Classic Informatics has spent 23+ years helping founders and product teams scope a first release around one clear question. If you're about to define yours, our MVP development services start with that conversation. And we're happy to talk it through.