Minimum Viable Product

An MVP is a version or arrangement designed to obtain useful learning about a new offer with limited effort. What must be built depends on the assumption being tested. It need not be a broad public launch, and minimal effort does not excuse misleading expectations or omission of essential requirements.

Minimum is relative to an important learning question, while viable depends on what participants reasonably need to experience and evaluate the offer. A manual service can test whether an outcome is useful without testing automated scale. A clickable demonstration can test comprehension without showing willingness to pay. Name these differences before interpreting a positive result.

Set the minimum acceptable standard alongside the learning goal. Honest expectations, essential functionality, and a workable end to the trial may be necessary even if they add effort. The goal is to avoid unnecessary commitment while obtaining interpretable evidence, not to classify every untested feature or safeguard as waste.

When to use it

When starting anything new—product, feature, business, initiative—and assumptions are untested; when the cost of being wrong is high and the cost of testing is low; when debates about what to build can be resolved by building and measuring; when perfectionism is delaying learning.

How it can help

Identify your riskiest assumption (usually: 'do customers have this problem and will they pay for this solution?') and build the minimum thing that tests it. Sometimes that's a landing page, a concierge service, a Wizard-of-Oz prototype, or a single feature. The discipline: define what you'll learn and what metrics will tell you whether to proceed, pivot, or stop BEFORE building. The most common MVP mistake: building too much. The second most common: not defining learning goals, so you can't interpret the results.