Minimum Viable Product

A Minimum Viable Product (MVP) is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The key word is “viable” — it must actually work well enough to deliver value to early adopters and elicit real feedback.

The MVP is not the smallest thing you can build. It is the smallest thing that tests your riskiest assumption.

What MVP Is

  • A learning instrument — an experiment designed to test a specific hypothesis
  • The entry point into the Build-Measure-Learn-Loop
  • Calibrated to what early adopters will tolerate, not what mainstream customers demand
  • A vehicle for Validated-Learning, not a shortcut to shipping

What MVP Is NOT

  • A broken or half-finished version of the eventual product
  • An excuse to skip quality (“it’s just an MVP”)
  • The first version you plan to build without testing assumptions
  • Minimum effort rather than minimum necessary effort to learn

Calibrating MVP Quality

The calibration problem: too minimal and the product fails to deliver real value, producing noise instead of signal; too complete and you’ve over-invested before validating assumptions.

Ries introduces the concept of a quality threshold: what level of functionality and reliability must the MVP have to generate a genuine learning signal from early adopters? The answer varies by context. A landing page MVP has near-zero functionality tolerance; a healthcare MVP has high reliability tolerance.

This calibration requires knowing who your early adopters are — the specific customer segment willing to use imperfect solutions in exchange for being first.

Origins and Critiques

Frank Robinson (SyncDev) is credited with coining “Minimum Viable Product” in 2001 in the context of customer-synchronized product development. His original framing emphasized “viable” strongly — an MVP must demonstrably solve a customer problem.

Marty Cagan argues that what most teams call an MVP is actually a Minimum Viable Test (MVT) — an experiment to validate demand, not a product. The distinction matters: an MVT tests whether customers want the product; an MVP tests whether the team can build something customers will pay for or use consistently.

Future Connections

Will connect to Early-Adopters, Types-of-MVPs, Leap-of-Faith-Assumptions when created.

Sources

  • Ries, Eric (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing. ISBN: 978-0-307-88791-7.

    • Chapter 4 (Experiment) — MVP first introduced; Chapter 6 (Test) — full treatment with case studies including Dropbox demo video and Zappos shoe experiment
  • Robinson, Frank (2001). “Minimum Viable Product.” SyncDev Inc.

    • Original coining of the MVP concept in the context of customer-synchronized product development; emphasizes that “viable” is the critical qualifier — the product must solve a real customer problem, not merely exist
  • Blank, Steve (2013). “Why the Lean Start-Up Changes Everything.” Harvard Business Review, May 2013.

  • Cagan, Marty (2017). Inspired: How to Create Tech Products Customers Love (2nd ed.). Wiley. ISBN: 978-1-119-38754-7.

    • Critiques common MVP misuse; distinguishes MVP from Minimum Viable Test (MVT); argues most teams conflate product launch with hypothesis testing, producing misleading results
  • Maurya, Ash (2012). Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media. ISBN: 978-1-449-30517-8.

    • Reframes MVP as “minimum viable experiment” in early stages; the Lean Canvas provides a systematic tool for identifying the riskiest assumptions to test before building anything

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.