Minimum Viable Product (MVP): Learn Faster with Less Code

The mental model

An MVP is an experiment, not just a product's first version. Its primary goal is to learn what customers actually want by giving them something real to use, maximizing learning while minimizing development effort. Think of it as a scientific tool to test a hypothesis like "Will users pay for feature X?" It prioritizes validated learning over building a feature-complete product based on assumptions.

How it works

The process starts by identifying the riskiest assumption in your business model—the one thing that, if wrong, would cause the entire project to fail. You then define the smallest possible experiment to test that assumption. This experiment results in a product with just enough features to be usable by early adopters and gather feedback. The core loop is Build-Measure-Learn: build the MVP, measure how users interact with it (e.g., sign-ups, usage metrics), and learn from that data to decide whether to pivot, persevere, or scrap the idea.

When to use it

An MVP is essential when operating under conditions of high uncertainty. Use it when entering a new market, testing a disruptive business model, or validating a core feature before committing a large budget. It helps answer fundamental questions early. Three places this shows up: first, testing if a market for a product exists at all (demand validation); second, validating a specific pricing model to see what customers will actually pay; third, determining which of several potential core features is most critical to users.

When not to use it

An MVP is not always the right tool. Avoid it when the "minimum" bar for viability is extremely high, such as in life-critical systems like medical devices or aerospace software, where failure is catastrophic and extensive upfront design is required. It's also less useful in mature markets where customer expectations are well-established and a feature-poor product would be immediately dismissed as inferior. Most importantly, never use "MVP" as an excuse to ship a buggy, unreliable, or unusable product. The 'V' for Viable is crucial.

One canonical example

Dropbox is a classic case. Building a complex, cross-platform file synchronization engine was a huge technical risk and investment. Instead, founder Drew Houston created a simple video demonstrating how the final product would work and posted it to a tech community. The video acted as the MVP. The overwhelming number of sign-ups from this video alone validated the market demand and proved people desperately wanted this solution. This "video MVP" tested the core hypothesis—"Do people want this?"—without writing a single line of production sync code, justifying the future investment.