Minimum Viable Product (MVP)

A minimum viable product is the smallest version of a product that allows a team to learn something essential about whether customers want it, popularized by Eric Ries in The Lean Startup. The defining property is not that it is small or cheap but that it is built to answer a specific question, and that the question concerns validated learning about customer behavior rather than internal opinion about feasibility.

The most persistent misuse is treating it as a synonym for a first release with fewer features. Under deadline pressure, teams cut scope, ship something incomplete, call it an MVP, and then measure nothing in particular, which produces neither a good product nor a useful lesson. The distinguishing question is what specific hypothesis the release will test and what result would cause the team to change direction. If no answer exists, the release is a small product, not a minimum viable one.

The viable half of the term also gets neglected. A version that is minimal but does not work, or that fails at the one thing it is meant to do, produces evidence about the implementation rather than about demand. Customers rejecting a product because it was slow, broken, or confusing tells the team nothing about whether the underlying proposition has value. Whatever is included must be good enough to give the idea a fair test, even if the surrounding scope is drastically reduced.

Several established patterns answer demand questions without building a full product. Concierge approaches deliver the service manually to early customers to learn what they actually need before automating anything. Wizard-of-Oz implementations present a working interface with humans performing the work behind it. Landing page tests measure whether anyone responds to the proposition before development begins. Each of these produces behavioral evidence, which is far stronger than the stated intentions collected in surveys and interviews about hypothetical products.

The approach fits some contexts far better than others. In regulated industries, in safety-critical systems, and in enterprise sales where a single poor first impression closes a market for years, shipping deliberately incomplete software carries costs that outweigh the learning. In these settings the same logic is better applied through prototypes, pilots with informed participants, and staged rollouts to limited audiences, rather than through public release of a minimal product.

Deciding in advance what result would cause the team to stop is what makes the exercise meaningful, and it is the step most consistently omitted. Without a pre-agreed threshold, any result can be interpreted as encouraging: low usage becomes a marketing problem, poor retention becomes an onboarding problem, and the project continues on the strength of whichever explanation preserves it. Writing down, before launch, what level of adoption or retention would justify continuing, what level would justify a change of approach, and what would justify stopping altogether converts the release into a genuine test. It also protects the team, since a documented threshold agreed by stakeholders is far easier to invoke than a judgment made after the fact.

Used properly, the concept keeps a team honest about the difference between building and learning, and it is most valuable where uncertainty about demand is genuinely high. In practice the hypothesis and the evidence standard are established through product research, the build sits with product development, and the discipline of defining in advance what result would trigger a change of direction is what separates the approach from simply launching early. For startups in particular, that discipline determines whether limited runway is spent learning or merely spent.