Minimum Viable Product (MVP)

The most common MVP mistake is treating it as a definition of quality rather than a scope decision — shipping a buggy, barely-functional version and calling it an MVP. The "Minimum Viable" in MVP refers to minimum feature scope, not minimum quality. An MVP should be production-quality and fully deliver on its narrow promise — it just makes a smaller promise than the full vision would. A better mental model is Steve Blank's definition: an MVP is the minimum feature set a specific customer segment will pay for to solve a specific problem. Eric Ries adds the critical word: "viable" — the product must be viable enough that real customers will use it to learn from, not prototype-tier code that only internal teams would accept.

The learning objective must be defined before building the MVP — otherwise there is no way to determine whether the experiment succeeded. The learning objective answers one core question: "Will the customers we believe have this problem actually use this solution, and will it work well enough to retain them?" Specific hypotheses to test: "Customers in segment X will activate on feature Y within the first session," "Users who activate on Feature Y will return at least weekly," and "We can build the core workflow without the full feature set we imagined." Product Ops documents the MVP hypothesis, sets the quantitative success criteria (e.g., 40% activation within week 1, 60% returning in week 2), and runs the post-MVP analysis to confirm or refute each hypothesis.

Multiple MVP archetypes exist along a spectrum of build investment. Concierge MVP — manually deliver the service for a small group of customers to understand if they value it (no code required). Wizard of Oz MVP — the customer interacts with what appears to be an automated product, but humans are performing the work behind the scenes. Prototype MVP — a mid-fidelity clickable prototype tested for comprehension and task completion rates. Single-Feature Build MVP — build only the core interaction loop with no edge cases, error handling, or integrations. Tech-Spike MVP — build the technically risky component only (the rest is mocked), to validate technical feasibility. The appropriate MVP type depends on the primary risk to be validated — if the risk is whether customers want the feature, a Concierge MVP is fastest; if the risk is technical, a Tech Spike is necessary.