Minimum Viable Product revisited

I wrote the following in response to a question about the Lean Startup practice of Minimum Viable Product.

The straightforward interpretation of MVP is a product that is built to gain feedback rather than built to maximize sales. I find it helpful to extend the idea. Here’s my interpretation:

  • “Minimum” is a reminder to invest as little as possible to get the next burning question answered or assumption validated.
  • “Viable” is a reminder to build enough to answer that question.
  • “Product” is a reminder to work from particulars.

MVP to me means “what I need to make in order to learn something valuable”. At first this can be as simple as a phrase: “we’ll cross StackOverflow with Twitter” (Quora). If you say your phrase to five people who ought to be interested if your assumptions are accurate and they all respond enthusiastically, then you’ve learned something valuable. Sharpie sketches on index cards could be a next step. Again, show them to people who you think “ought” to be interested and their reactions will give you valuable feedback. A wireframe might be your next step. Then a working but emaciated product. Then adding and/or deleting features.

The goal at each step is gathering feedback fast and cheap. You’re not trying to invest in these increments, you’re trying to avoid investing until you are more certain that a payoff is likely. You stick with a level of investment as long as it is providing valuable feedback, then move on (either forward or back, depending on the feedback). For example, I’ve seen people stick with wireframing long after it has ceased to provide feedback, which is just as wasteful as skipping wireframing if it can validate a hypothesis more cheaply than real code.

I call these steps “Informative Increments”, of which the MVP=barely-but-informatively-functioning-prototype is a special case. Unfortunately, neither the phrase itself nor the acronym can compete with MVP. The principle remains, though: while decisions are risky, make them & validate them as cheaply as possible to preserve capital for the (nearly) inevitable iterations.

The temptation in StartupLand is to try to make something good enough to survive. The paradox of the MVP is that by making a series of products which aren’t good enough to survive but are good enough to inform, you increase your chance of eventual success.


Bob MacNealOctober 29th, 2010 at 7:34 am

I like the term “Informative Increments” and your reminder that MVP is “making a series of products which aren’t good enough to survive but are good enough to inform”. Helpful post. Thanks.

Brian BrownOctober 29th, 2010 at 8:10 am

I think your term “informative increments” accurately describes what you see as MVP – my take on MVP is much different, however. In the case of a commercial software company, we use MVP to mean: “What is the minimum set of features that we can deliver to customers in a viable format”. Viable meaning people will pay money for it and be pleased with the value proposition it represents. To my mind, that is what “viability” means. A viable product is much different than a viable prototype, which is what I understand from your post, essentially the core of Spiral Development. Old yes, but accurate I think :)

adminOctober 29th, 2010 at 8:24 am

I agree that an MVP is a real product, but designed around maximizing learning instead of revenue. My point is that the same strategy applies at various scales of uncertainty, from a crazy idea to a real, functioning system. MVP is an example of this strategy but startups can be more valuable applying it throughout.

Kevin TaylorOctober 29th, 2010 at 12:39 pm

IMHO, Minimum Viable Product is a very unfriendly term when used synonymously to represent what you are calling informative increments.

In Obtiva’s Studio we only use the term MVP to refer only to the minimum marketable product. Otherwise, trying to explain to a client that a google adword campaign or a whiteboard sketch of wireframes is the next MVP becomes confusing and counterproductive.

For those discussions, we just ask, “OK, what assumptions do we need to prove next and how do we prove it quickly and cheaply?” K.I.S.S.

adminOctober 29th, 2010 at 1:23 pm

There are definitely two concepts at work: the general idea of using cheap, quick, concrete increments as learning vehicles and the specific idea of building something you can charge customers for as a learning vehicle. I’ve heard “MVP” used to refer to both. I’m thinking two words would be better.

Bob MacNealNovember 1st, 2010 at 7:04 am

It seems Kent’s is a stripped-to-the bones flavor of MVP; asking “What do we need to make that will answer the first hypothesis about our business idea? second? third? and so on.

One might put a buy button on a web page & count the clicks (an exaggeration!).

This is an important distinction from what most people think of as MVP. Most people are thinking “polished product” with each release, but perhaps with scant functionality, rather than “What hypothesis about my business idea am I testing?”

Isn’t Kent’s approach essentially what Eric Ries & Steve Blank are urging entrepreneurs to do? Iterative hypothesis testing? A product evolves from a series of tests.

Juan BernabóJanuary 13th, 2011 at 7:42 am

It seems that MVP is used in two ways, the first is the MVP as a goal to have a minimim really viable product delivered to the market, and the other concept is about how do you break the progress into steps designed to learn something producing something concrete showable and understable to a stakeholder, user or customer to validate the hypotesis that we are holding to be true or if it needs some more learning, inorder to get to the MVP by learning with feedback on the way.