Minimum Viable Product revisited

The last ThreeRiversInstitute.org post

First published November 2010. I was about to find my gig at Facebook which would pull me back out of a long funk. Eric Ries was talking some great stuff & I wanted to fully understand it, so I was part of the Lean Startup community for a minute.

This is the last of the posts to be resurrected from my first blog home—Three Rivers Institute. It was an interesting time of my life. Looking back I’ve enjoyed how hands-on I was then, digging into the minutiae of programming even while I was trying to understand higher level concepts like what became 3X: Explore/Expand/Extract.

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.

If you want to read more about programming & how it fits into the larger picture of the economy, society, and personal growth, please consider becoming a paying subscriber. You’ll receive a weekly Thinkie, a habit of creative thought. You’ll also receive a deluge of draft chapters of my next book on software design.