A minimum viable product is meant to be the smallest thing you can build that proves people will use and pay for what you are making. Most MVPs miss on both sides at once. They are stuffed with nice-to-haves nobody asked for, and thin on the one or two things that would actually prove the idea. That is what the title means: half the features it needs, twice the features it should have.
The evidence that we build the wrong things is not subtle. Around 80 percent of features in the average software product are rarely or never used, and just 12 percent of features drive 80 percent of usage (Pendo, 2019). An older and often-quoted study put it even more starkly, finding 64 percent of delivered features were rarely or never used (Standish Group, 2002), though that came from a small sample and is best treated as the well-known industry figure rather than hard science. Either way the direction is clear. Most of what gets built does not earn its place.
What is an MVP actually for?
An MVP exists to answer one question: will people want this enough to use it and pay for it? Everything in the build should point at that question. Features that do not help you learn whether the core idea works are not part of the minimum, they are decoration you are paying to maintain. The reason poor product-market fit sits at the very top of the startup failure charts, cited in 43 percent of recent shutdowns (CB Insights, 2026), is that teams spend their money proving they can build something before checking that anyone wants it.
Why do MVPs end up bloated?
Because feature creep is the natural state of any project with more than one opinion in the room. We have watched it happen on builds that started perfectly sensible. A tool for onboarding contractors and labourers onto sites, for instance, has a clean core job: get a worker verified and cleared to start. Then the stakeholders arrive and "can it just" syndrome sets in. Can it just also track certifications. Can it just do reporting. Can it just handle payroll. Each request is reasonable on its own. Together they quietly swap the real problem for a much bigger, vaguer one, and the thing you ship no longer maps to the job you set out to solve.
This is worth being honest about, because the mistake usually happens at the very start, not the end. The problem gets misread before a line of code exists, and then a competent team faithfully builds the wrong, bloated thing. Scope creep now hits 52 percent of projects, up from 43 percent five years earlier (PMI, 2018). The discipline is not in building fast, it is in refusing the features that do not serve the question the MVP is meant to answer.
Which features should an MVP have?
The ones that prove or disprove the core idea, and nothing else yet. Start from the single most important thing a user needs to do, make that one path excellent, and cut everything that is not on it. Look at your feature list and ask, for each item, whether it is there because a user needs it or because a stakeholder feared leaving it out. The second group is where your budget quietly disappears. Publicly traded software firms collectively spent an estimated 29.5 billion dollars building features customers rarely or never touch (Pendo, 2019).
A simple test for each feature: keep it only if the answer to all of these is yes.
- It is needed to prove whether the core idea works.
- A user, not just a stakeholder, actually needs it now.
- Removing it would stop you learning something you have to learn.
- You are willing to maintain it for years, not just ship it once.
Does shipping fewer features actually pay off?
Yes, and speed to market is the reason. A classic McKinsey study found that a product six months late to market earns around 33 percent less profit over five years, while a product that ships on time but runs 50 percent over budget loses only about 4 percent (McKinsey, via TCGen). Being late is roughly eight times more expensive than being over budget. A lean MVP that ships now and starts teaching you things beats a complete one that arrives late and teaches you the same things far more expensively.
What happens if you get the MVP right?
You earn the right to keep building, with evidence instead of guesses. The clients whose products last are almost always the ones who started narrow. Strip everything out until the core case is proven, ship it, learn from real usage, then add deliberately. Those are the products people keep investing in for years, because every addition after the MVP is backed by something you actually know about your users rather than something you hoped at the outset.