What is an MVP: a minimum viable product explained with real examples and honest limits

A minimum viable product is an experiment, not a small product

People who ask what is an MVP usually expect a product type: a small app, a rough first release. It is closer to an experiment with a product attached. Wikipedia defines a minimum viable product as a version of a product with just enough features to be usable by early customers, who can then provide feedback for future development. A cafe that tests ordering ahead with a plain form for its regulars, before it pays for an app, has built one.

According to the same article, the term was coined and defined in 2001 by Frank Robinson and popularised by Steve Blank and Eric Ries. Ries gave it the wording founders quote: on his blog Startup Lessons Learned, in August 2009, he called it that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Learning is the output, effort is the cost.

What an MVP is not: a rough draft, a prototype, an investor demo

The name misleads, and Ries says so himself: MVP, despite the name, is not about creating minimal products. In the excerpt from his book The Lean Startup that TechCrunch published in 2011 he adds that it is not necessarily the smallest product imaginable and that, unlike a prototype or concept test, its goal is to test fundamental business hypotheses, not just design or technical questions. A prototype shows that something can work. An MVP shows whether real customers want it.

Nor is it a licence to ship something broken. Wikipedia’s article records the criticism: products below the expected minimum standard of quality lose to competitors that enter the market with a higher one, and negative feedback on an early release can affect a company’s reputation. A demo for investors is a third thing again: it shows what could exist to people who will never use it. The one thing an MVP does has to work properly.

The question it answers, and the hypothesis written before any code

The Lean Startup site puts the purpose in one line. The question is not whether this product can be built; the questions are whether it should be built and whether a sustainable business can be built around it. A competent team with enough time can build almost anything. Whether strangers will change a habit and pay for the result stays unknown until somebody tries.

Wikipedia gives an example. In 2015 specialists at the University of Sydney devised the Rippa robot to automate farm and weed management. The technical hypothesis, that the robot could tell weeds from crops, was already proven; the business hypothesis, that it would be a viable tool on a working farm, was not. A small company writes the same split in one sentence before any code: who the customer is, what they do today, what they will do with the product, and which number by which date counts as a yes.

Three kinds of MVP, each with a documented example

The lightest kind has no product in it at all. Ries tells the Dropbox story in the TechCrunch excerpt: the working software could not be demonstrated in prototype form, so its CEO, Drew Houston, made a simple three-minute video aimed at technology early adopters. By Houston’s account the beta waiting list went from 5,000 people to 75,000 literally overnight. In this case, Ries concludes, the video was the minimum viable product. A page that collects sign-ups works the same way.

The second kind is a landing page that asks for a little more than an email. Joel Gascoigne, the founder of Buffer, described his on the company blog in February 2011. The first version was two pages, made to check whether people would even consider using the app. Then he put a pricing page in between to see which plan visitors clicked, and a small number clicked on paid plans. Only then did he build the product, and the first paying customer arrived within four days of launch.

The third kind is a service done by hand behind a simple shop window. Wikipedia’s article on the lean startup, citing Ries, describes how Zappos founder Nick Swinmurn tested whether customers would buy shoes online. He photographed the stock of local shoe stores, posted the pictures online, bought the shoes at full price once he had made a sale and shipped them to the customer. The plainest kind is one feature built properly: Gascoigne wanted to take the scheduling feature of Twitter apps and make that single feature awesome.

Cutting the scope: one user, one scenario, one result

Scope is where most first versions go wrong, and no formula settles it. Ries admits as much in his guide: it requires judgment to figure out, for any given context, what MVP makes sense. A working rule helps. Choose one kind of user, the one who meets the problem most often. Choose one scenario, the single path from opening the product to getting what they came for. Choose one result that the user can see and you can count.

Gascoigne’s account shows it from the inside. He told people the first version would take a week; it took seven, and he still had to leave out the guided step-by-step signup he had planned. The cuts look alike from project to project: a second user role, settings, an admin panel that a spreadsheet can replace for a month, integrations, a mobile app next to the web one. None is a bad idea. Each answers a question nobody has asked yet.

What to measure after launch, and what counts as an answer

Launch day produces numbers, and most of them flatter. Wikipedia’s lean startup article separates two sorts. Vanity metrics give the rosiest picture possible without reflecting what drives the business; the typical example is the number of new users gained per day. If acquiring each user through expensive advertising costs significantly more than the revenue that user brings, gaining more of them could quickly lead to bankruptcy. Actionable metrics are those that can lead to an informed business decision.

For a first version the actionable numbers are few. How many of those who saw the offer tried the product, how many came back without a reminder, how many paid. Gascoigne reported his: about two and a half months after launch, over 500 users and around 4% of people upgrading to paid plans. An answer also needs a threshold set in advance, otherwise any result reads as encouragement. The Lean Startup site names the decision that follows: when the drivers of the business model are not moving, it is time to pivot or make a structural course correction.

Three errors: a year of building, no numbers, polite interest

The first error is the long build. The Lean Startup site describes it: too many startups begin with an idea for a product they think people want, then spend months, sometimes years, perfecting it without ever showing it, even in a very rudimentary form, to a prospective customer. When customers at last communicate, through their indifference, that they do not care, the startup fails. Ries is as strict with himself: in his guide he recalls two weeks spent on a feature that absolutely nobody wanted and calls that way too long.

The second error is launching with nothing to measure: no threshold and no counter on the one action that matters, so every outcome looks like progress. The third is taking politeness for demand. Friends call the idea great, visitors leave an email, and none of it costs them anything; Gascoigne’s pricing page made interest cost one more click. The method has a limit as well: Wikipedia’s article cites research suggesting that an early release may hurt more than help when a competitor can imitate the product and no other barrier exists.

What to prepare before ordering an MVP from a studio

Some of these tests need no developer. A page with an offer and a sign-up form, a short video, a service delivered by hand to the first ten customers: an owner can run these alone before paying for software. Ordering makes sense when only a working product can answer the question: accounts, payments, data that must not be lost, a scenario too long to fake by hand. Even then the brief is the hypothesis, not a list of screens.

So bring one sheet: the one user, the one scenario, the result that user should get, the number and the date that will count as a yes, and what cheaper tests have already taught you. VITON13 Studio builds web application MVPs from briefs of this kind; the scope and the cost are set out in the linked guide and on the service page. With that sheet, the question of what is an MVP becomes a practical one: which is the smallest version that could prove you wrong.