What Is a Minimum Viable Product (MVP)?

In product work and startups, MVP stands for minimum viable product. The same initials stand for most valuable player in sport, which has nothing to do with this entry.

The reference definition comes from Eric Ries, on his blog on 3 August 2009: the version of a new product that lets a team collect the most validated learning about customers with the least effort. Ries took the idea into his book "The Lean Startup", published on 13 September 2011. According to the book's own summary, the MVP is there to test the assumptions the business depends on.

The misreading is to take an MVP as a stripped-down first version or a beta. Ries warns against this himself: despite the name, it is not about creating minimal products. A stripped-down version answers the question of what can ship soon. An MVP answers a different one: which assumption has to be tested, and what is the least you have to build to test it? Seen this way, it is the smallest experiment that tests an assumption. The method's website uses both words: the experiment is also a first product.

So the outside appearance does not settle it. A beta and an MVP can look alike. An MVP also has a written question, a measurement and a decision that depends on the result. Ries warns that this adds work, because you have to talk to customers or set up metrics.

The size is not fixed. According to Ries, IMVU's original MVP took six months to reach the market, against almost five years at an earlier company. In another case the team spent two weeks on a feature nobody wanted, and a simple AdWords test would have shown this sooner. The definition calls for judgment, not a formula.

The phrase is not Ries's. On its archived website (copy of 28.09.2015), SyncDev, Frank Robinson's company, writes that it first used the term in 2001, and on the same page Steve Blank credits the phrase to Robinson. That is the company's own account: no document from 2001 could be found, and the current page at that address mentions neither Robinson nor that year.

Robinson meant something else. SyncDev defines the MVP as the product that maximises return on risk for both vendor and customer, that is, the product that goes on sale. Blank spoke of a minimum feature set, and in March 2010 he was already warning about the confusion when "minimum" becomes the goal. Ries himself, in March 2009, described it as the product with just the features that resonate with early adopters. Five months later he was defining it by learning. So the confusion has a history, and it is worth asking which MVP someone means. This entry follows Ries's definition of August 2009.

A prototype is something else, even when the material is the same. The PDMA's review of Ries's book sums it up like this: prototypes are commonly used to test functionality, MVPs to test business hypotheses. The method's website draws the same line: the question stops being whether the product can be built and becomes whether it should be. A prototype becomes an MVP when you put it in front of customers to measure an assumption. Ries describes a paper prototype being shown to people.

The first step is to write the assumption down in a way that could turn out to be false. According to the PDMA review, Ries recommends starting with the riskiest elements of the plan. These are the ones everything else depends on, for example that someone will pay to have the problem solved.

The second step is to decide in advance what you will measure and which result would change the decision. The method's website asks for metrics that can show cause and effect. If the metric is picked afterwards, any result looks good.

The third step is to build the least that produces that measurement. That can be very little. Ries says that, instead of building, his team should have started with a landing page promising the product, with traffic from ads, and he reckons nobody would have clicked. In other cases it takes a real product.

An invented example: a company believes small offices would pay for a weekly coffee bean subscription. Before setting up the logistics, it publishes a page with the price and a reservation button, and advertises it to that audience. People who click are told the service is not available yet, and nothing is charged. What it measures is how many offices try to reserve at that price.

The fourth step is to decide. Ries calls the cycle build, measure, learn, and the decision is to persevere or pivot, meaning to change course and test a new hypothesis. One poor first result is not enough. Ries talks about the fear of the false negative: if nobody wants the first paper prototype, you iterate. Only after many rounds without interest (his example is ten) does it make sense to conclude the direction is wrong.

Product-market fit is a state, and an MVP is a tool. Marc Andreessen described it on 25 June 2007 as being in a good market with a product that can satisfy that market, a formulation he credits to Andy Rachleff. The signs he gives come from the business: customers buy as fast as you can make the product, or usage grows as fast as you can add servers. Without it, customers get little value from the product, word of mouth does not spread and sales cycles drag on.

An MVP with a good result does not prove that fit. It tests one assumption, and in Ries's account it does so with early customers. Ries explains that they are the most forgiving and fill in the missing features in their minds. Blank adds that only a subset of customers gets excited about a minimum feature set. What works with them says little yet about the wider market.

The relationship is one of order: MVPs are the steps by which a team looks for fit. Andreessen asks founders to focus on reaching it ahead of almost everything else. That is a contention, and he calls it one himself. His text gives neither a threshold nor a measurement.

An MVP lowers the risk of building something nobody wants. The method's website describes the opposite case: teams that spend months or years perfecting a product without showing it, and then run into customers' indifference. The sources cited here offer experience and argument, not a study measuring how much is saved. This glossary does not have that figure.

It has limits too. Ries says that someone who only wants to meet an obvious need or build something for a quick resale does not need an MVP. SyncDev points out that too small a product is also a problem, because it leaves room for a competitor. And what a group of early customers will put up with, not every customer will.

The MVP connects with other entries. The Business Model Canvas treats each block as an assumption, and an MVP is one way to test the riskiest. A/B testing compares two variants of something that already exists and needs enough traffic. The MVP comes earlier, while it is still open whether to build it at all. Growth hacking optimises the stages of a product that already has users. The value proposition can be the first assumption to test.

• Write the assumption down before building anything.
• Start with the assumption the others depend on.
• Set the metric and the deciding result in advance.
• Build only what that measurement needs.
• Measure what people do, not only what they say.
• Tell participants clearly what is being tested and what does not exist yet.

• Calling any first version or beta an MVP.
• Launching without having written down what you want to test.
• Choosing the metric after seeing the data.
• Dropping the idea after a single negative result.
• Taking early customers' enthusiasm for product-market fit.
• Showing a prototype and believing that tests willingness to pay.