MVP is dead. Long live MVP

Somewhere right now, a steering committee is cutting scope. Someone has said “progress over perfection.” Someone else has said “kill your darlings.” A programme that spent eight months in discussion is finally moving, because somebody invoked the two most effective letters in corporate digital transformation: an MVP. Ship the minimum. Learn. Iterate.

For twenty years this was not just acceptable practice, it was the mark of a serious organisation. Nobody knows at the outset whether a product will fly, so you build the smallest thing that could possibly teach you, and you let the market finish the design. The alternative — betting years of engineering on an unvalidated guess — was how enterprises burned nine figures on platforms nobody used.

I think the MVP, as we have practised it, is dead. But not for the reason the term deserves to die, and not in the way most people saying “just ship it all” believe.

It was never about minimum

Start with a correction, because the history matters to the argument. The MVP does not come from The Lean Startup, where most people place it. The term was coined in 2001 by Frank Robinson, a product consultant working on synchronised customer and product development. Steve Blank carried it into his customer development methodology, and Eric Ries made it famous in 2011. But somewhere between Robinson and the airport bookshop, the concept inverted. Robinson’s MVP was the product that maximised return on risk — big enough to cause adoption and sales, small enough not to be bloated. Ries defined it as the version of a product that maximises validated learning for the least effort.

Neither definition is about smallness. Both are about learning per unit of risk. “Minimum” was always the adjective; “viable” was always the point.

The enterprise heard it differently. In large organisations — the ones that are not digital natives, the ones trying to learn from Silicon Valley without being Silicon Valley — MVP became a management device rather than a learning instrument. It was the socially acceptable way to end a discussion and force something into production. Cut everything not strictly needed. Get it live. And because the cutting was done under budget pressure rather than learning pressure, teams routinely cut past the bone — removing the very features that made the product worth adopting. Enough companies got burned this way that the term itself grew corrective prefixes. Minimum commercially viable product. Minimum lovable product. Each rebrand an admission that “minimum,” taken literally, produces something the market correctly ignores.

So before AI enters the picture at all, the honest description of the MVP in corporate life is this: a compromise between what you believed the product needed to be and what your engineering budget could deliver by the deadline. The learning rationale was the theory. The resource constraint was the practice.

The constraint just disappeared

That compromise rested on one assumption so universal nobody stated it: building software is expensive. Development time was the scarce resource, so scope was the variable you sacrificed.

That assumption is now collapsing. When applications are built with AI — and increasingly they are built almost entirely with AI — the marginal cost of another feature, another integration, another polished flow approaches zero. I have written before about what this does to the rhythm of product teams: implementation stops being the bottleneck, and decisions become it. But the consequence for the MVP is more brutal. Why would you launch something that barely works when the full product costs nearly the same to build? The entire justification for shipping the minimum — we cannot afford more yet — has evaporated.

So yes: the MVP as we knew it is dead. The compromise no longer purchases anything.

You can now be 99% wrong at full scale

Here is what did not die: the reason the MVP existed in the first place.

Building everything does not make you one percent more likely to have built the right thing. Your project still has no validation in the market and none from end users. All that has changed is the blast radius. Where the old constraint forced you to expose a small, cheap guess, you can now expose a large, complete, beautifully engineered guess — and be exactly as wrong, from day one, at full scale.

It is worse than that, actually. A small product is a clean experiment. When an MVP with three features retains users, you know roughly why. When a launch with forty features underperforms, the signal drowns in the noise. Which feature failed? Which one would have carried the product if the others had not buried it? The minimalism of the MVP was never only a budget concession — it was instrument design. Shipping everything is not just no cheaper insurance against being wrong; it makes being wrong harder to diagnose.

The constraint did not disappear. It moved.

The faster horse changes riders

There is a famous quote about this, and it is worth handling carefully because it is fake. Henry Ford never said “if I had asked people what they wanted, they would have said faster horses.” The line appears nowhere in his writing, nowhere in the Henry Ford Museum’s database of authenticated quotations, and was first attributed to him half a century after his death. It survives anyway, because it names something true: users are very good at describing symptoms and very bad at describing painpoints. They ask for the faster horse because the horse is the frame they have.

In the old world, this was survivable. The product team shipped the minimum, then spent the following quarters listening to feature requests and trying to interpret what users actually meant — the faster-horse translation work happened after launch, in the iteration loop, paced by engineering capacity.

In the new world, that translation work moves almost entirely upstream, and it lands on one desk: the person designing the product. When you can build anything, the question “what should we actually build here?” stops being constrained by feasibility and becomes constrained only by judgment. The product designer now has to consider the application 360 degrees before launch — users, market, industry, and the core problem the product exists to solve — because nothing else in the process will force the discipline that budget scarcity used to force for free. Most product people can imagine how an MVP gets designed and built. Nobody knows where it ends. The scope of version one is no longer an engineering negotiation. It is a thesis about the market, and the market grades it immediately.

Long live MVP

So the answer to the question is yes, and no, and the tension between them is the interesting part.

The MVP as a resource compromise is dead. There is no longer any reason for a product to feel minimal, unfinished, or barely viable. Users will meet complete products on day one, and their tolerance for “we’ll add that next quarter” will fall accordingly.

But the MVP as a discipline — the smallest product that can prove or disprove your thesis — is more necessary than it has ever been, precisely because nothing enforces it anymore. Scope used to be set by what the team could afford to build. Now it is set by what the designer actually understands about the people the product is for. That is a harder constraint, not an easier one, because it cannot be bought, staffed, or prompted. It has to be known.

The challenge, in other words, is exactly the same as it always was: build the thing that teaches you the most about whether you are right. What has changed is that there is no longer a budget to blame when you get it wrong.

Written from the perspective of someone who now ships complete products in the time a steering committee used to spend approving the MVP — and has learned that the speed makes the “what should we build” question more dangerous, not less.