An MVP, or minimum viable product, is the smallest version of a product that you can give to real users to learn whether it works. It is not a cheap version of the full product. It is a tool for learning the fastest, which means it should do as little as possible while still testing the core idea.

Why should an MVP do less?

Because every feature you add before launch delays the day you learn whether the product works, and adds risk that something breaks or distracts from the core. A smaller MVP reaches real users sooner, which means you learn sooner. Doing less is not careless work, it is getting the answer faster.

What is the one thing an MVP must do well?

It must do the single core thing that makes the product worth using, and do that one thing well. Everything else can be rough or missing. If the core is weak, no amount of surrounding features will save it, and if the core is strong, users will forgive a lot of unfinished parts.

How do I decide what to cut from an MVP?

For each feature, ask whether the product can teach you what you need to learn without it. If yes, cut it for now. Keep only the features required to test whether the core idea works. Most of what feels essential before launch turns out to be something you can add later, once you know it matters.

Does a smaller MVP mean lower quality?

No. Doing less does not mean doing it badly. The one core thing your MVP does should be done well, because that is what you are testing. A small MVP concentrates your quality on the part that matters instead of spreading it across features nobody asked for yet.

Why does adding features delay learning?

Because each feature takes time to build and test before you can launch, so every feature delays the day real users touch the product. Until real users touch it, you are guessing. More features means more time guessing and less time learning, which is the wrong order for a first version.

What is the risk of launching with too many features?

You spend months building things you assumed users wanted, launch, and discover the core idea was wrong or that users only care about one part. Now you have wasted the effort on the extra features and delayed the feedback that would have told you sooner. Big first versions hide that risk instead of removing it.

How is an MVP different from a discovery prototype?

A discovery prototype tests a risky assumption cheaply, often before writing real code, and you usually throw it away. An MVP is a real, released product, just a very small one, that real users actually use so you can learn from their behavior over time. The prototype comes first, the MVP is the first real version.

What should I do after launching a small MVP?

Watch how real users behave, learn what they actually value, and add only what the evidence says matters. The MVP is the start of a cycle: release, learn, adjust. Adding features after launch is fine and expected, the discipline is not adding them before you have any evidence.

How do I resist the pressure to add just one more feature?

Remind yourself and your team that every added feature delays the day you learn the truth. Tie each proposed feature to a question it helps answer, and if it does not help you learn whether the core works, it waits. Writing the cut features on a "later" list helps, because nothing is lost, it is just deferred.

Can a small MVP really compete with a full-featured product?

At the start you are not trying to beat a full product on features. You are trying to learn whether your core idea is worth building further. A small MVP that does one thing well and teaches you fast is worth more early on than a full product built on assumptions you never tested.

Why your MVP should do less: Reveneau

Almost every team we work with wants to build more into their first version than they should. It is not carelessness. It is the opposite: they care about the product, so every feature feels important, and cutting any of them feels like releasing something unfinished. So the "minimum" product grows and grows, and what was supposed to be a quick first version turns into a six-month build. Then it launches, and only then does the team find out whether the core idea worked at all. By that point the money and time are already spent. The instinct to add is natural, and it is the exact thing that makes a first version go wrong. Your MVP should do less than you think, and here is why that is a strength, not a compromise.

An MVP is a tool for learning, not a small version of the product

Start with what an MVP is actually for, because the name confuses people. Minimum viable product sounds like "the cheap version of the real thing." It is not. It is a tool for learning the fastest whether your idea works.

That difference changes everything about how you build it. If an MVP were a small version of the full product, you would want it to be as complete as you could afford, and every feature you added would make it better. But it is a learning tool, and a learning tool has a different job: get you real evidence about the core idea as quickly as possible. Judged that way, extra features do not make the MVP better. They make it slower to build and slower to teach you anything, which makes it worse at its actual job. Once you see the MVP as a way to reach the truth quickly, cutting features stops feeling like a loss and starts feeling like exactly the point.

Every feature you add before launch delays learning

Here is the core idea, and it is the one to remember. Every feature you add before launch delays the day you learn whether the product works.

The logic is simple. Each feature takes time to build and test before you can launch. Until you launch and real users touch the product, everything you believe about it is a guess. So each feature you add is more time spent guessing and less time spent learning. A team that adds ten features to its first version has not made the product ten times better. It has delayed the moment it learns the answer by however long those ten features took, while risking all of that time on assumptions it has not tested. If the core idea turns out to be wrong, and for new products it often is in some way, all of that extra effort was spent making a wrong thing more elaborate.

This is why big first versions do not reduce risk, they hide it. It feels safer to launch something complete. It is actually riskier, because you have committed more before learning anything, and you find out later, when changing direction is most expensive. A smaller MVP feels risky and is safer, because it gets you to real feedback while you can still act on it cheaply. We made a version of this argument about custom builds in general in build vs buy: the research on large software projects is direct, and the pattern holds here too. Bigger means more risk. Smaller means more safety.

The discipline is cutting

Knowing you should do less is easy. Actually cutting is hard, and it is a discipline you have to practice deliberately, because the pressure always pushes the other way.

The tool that helps most is a single question you ask of every proposed feature: can the product teach me what I need to learn without this? If the answer is yes, the feature waits. Not forever, just not now. You are not deciding the feature is bad. You are deciding it is not required to test whether the core idea works, which means it does not belong in the version whose only job is to run that test. Most of what feels essential before launch fails this question. The extra settings, the second user type, the final details on flows nobody has even reached yet, the integrations you assume people will want. Each one feels necessary, and almost none of them are necessary to learn the one thing you are launching to learn.

A practical trick makes the cutting easier: keep a "later" list. Every feature you cut goes on it. Nothing is thrown away, it is just deferred. This matters because most of the resistance to cutting is fear of losing the idea. Write it down and the fear goes away, and the team stops arguing to keep features in the launch because they can see the features are safe on the list, waiting for evidence that they matter. Tie each item to the question it would help answer, and you will find that many of them are answering questions you do not even have yet.

Do one thing, and do it well

Doing less does not mean doing it badly. This is the part people get wrong in the other direction. When you reduce an MVP, the one thing that remains, the core reason the product is worth using, should be done well. That is the thing you are testing, so it has to be good enough to give an honest test.

Think of it as concentrating your quality instead of spreading it across many features. A full first version spreads a fixed amount of effort across many features, so everything is a little rough. A small MVP puts that same effort behind the one thing that matters, so that one thing is genuinely good, and the rough or missing pieces are all in the parts that do not matter yet. Users forgive a lot of missing features if the core does its job well. They do not forgive a weak core no matter how many features surround it. So the rule is not just "do less." It is "do one thing, and do that one thing well." Find the single core action that makes the product worth using, make that excellent, and let everything else be rough or absent for now.

After launch, let evidence decide

The MVP is not the end of the story, it is the start of a cycle. You release the small version, you watch how real users actually behave, you learn what they value, and you add only what the evidence says matters. Adding features after launch is completely fine and fully expected. The discipline was never "never add features." It was "do not add them before you have any evidence they matter." After launch, you have evidence, so now adding is informed instead of a guess.

This is what makes doing less worth it. The team that launched small is now learning from real behavior, adding the features users actually use, and dropping the ones from the "later" list that nobody ever missed. The team that launched big is still discovering, weeks later, that half of what they built goes unused, and now they own all of it: the maintenance, the complexity, the code that has to keep working even though it earns nothing. Small got the answer faster and has less to maintain. That is the whole case for doing less. It is not modesty and it is not careless work. It is the fastest honest way to know whether the thing you are building is worth building further. If you want a team that will encourage you to cut rather than add more, that instinct is central to how we approach a full product build.

The argument for a small MVP got stronger, which is the opposite of what most teams assume. When building was expensive, "build less" was partly a budget argument, and a team with more funding could reasonably ignore it. That budget argument is gone: you can now afford to build the large version.

You still should not. Every feature in an MVP is something to explain, support, and keep working, and each one adds a place where user feedback about the core idea gets mixed up with feedback about a less important one. The MVP was never small to save money. It was small so that what you learn from it means something. Cheap building removed the budget excuse. The reason for a small MVP remains.

Why your MVP should do less than you think