How MVP Became an Excuse for Shipping Broken Products

Eric Ries defined the minimum viable product as the version of a new product that allows a team to collect the maximum amount of validated learning with the least effort. Somewhere between that definition and common practice, the concept mutated. "Minimum" started meaning "barely functional." "Viable" got dropped entirely.

The result is a generation of products launched with missing core functionality, obvious usability problems, and performance issues that would embarrass a first-year developer. These products do not generate validated learning. They generate validated contempt. Users try them, have a terrible experience, and never return. Worse, they tell others.

The word "viable" was always the important half of MVP. A product that is not viable — that does not deliver enough value to make someone use it despite its limitations — teaches you nothing about whether your idea has merit.

The Viability Threshold Has Risen Dramatically

When Ries wrote The Lean Startup, user expectations were lower. Today, people interact with beautifully designed, instantly responsive applications every day. The baseline for "good enough" has risen across every category. What was viable in 2011 is not viable now.

This does not mean you need to ship a perfect product. It means you need to ship a product that does one thing exceptionally well — well enough that users tolerate everything it does not do. Dropbox's MVP was not a bad file sync tool with missing features. It was an excellent file sync tool that did nothing else. The quality of the core experience was high. The scope was narrow.

The distinction matters: reduce scope ruthlessly, but do not reduce quality. Ship a product that is narrow but polished, not broad but broken.

Alternatives to the Traditional MVP

The Concierge MVP: Deliver the outcome manually before automating it. If you are building a recommendation engine, recommend things by hand to early users. This validates demand for the outcome without requiring the technology investment.

The Wizard of Oz MVP: Present a functional-looking product to users while handling the back end manually. Users get a realistic experience while you learn whether the value proposition resonates before building the infrastructure.

The Single-Feature MVP: Instead of shipping a watered-down version of your full vision, ship a complete and polished implementation of your single most important feature. Test whether that feature alone is valuable enough to attract and retain users.

All three alternatives share a common principle: validate the value proposition before investing in the product. The goal is not to ship a product. The goal is to learn whether the problem you are solving matters enough that people will change their behavior to use your solution.

When to Invest Beyond MVP

An MVP that works — that generates retention and enthusiasm from early users — creates a dangerous temptation: to keep running in MVP mode forever. Some companies become addicted to shipping minimum and never invest in building a complete, robust product.

The transition from MVP to growth product should happen when three conditions are met: retention metrics show product-market fit, the core value proposition is validated, and the primary barrier to growth is product completeness rather than market demand. At that point, continued under-investment in the product becomes the risk, not over-investment.

Think of MVP as a phase, not a philosophy. It is the right approach when you are testing hypotheses. It is the wrong approach when the hypothesis is proven and you need to capture the market.