Monday, August 3, 2009

Minimum Viable Product: a guide

One of the most important lean startup techniques is called the minimum viable product. Its power is matched only by the amount of confusion that it causes, because it's actually quite hard to do. It certainly took me many years to make sense of it.

I was delighted to be asked to give a brief talk about the MVP at the inaugural meetup of the lean startup circle here in San Francisco. Below you'll find the video of my remarks as well as the full slides embedded below. But I wanted to say a few words first.

First, a definition: the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don't need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense. As I talked about in a previous interview, IMVU's original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situations we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was.

Without further ado, the video:

Slides are below:

Reblog this post [with Zemanta]


  1. I do this as a core part of the Product Management process I use at all startups. When we originally came up with the idea during the dotcom boom we called it a "Compelling Product Offering" -- the minimum feature set that caused people to be compelled to pay us money.

    It's a great exercise and useful to help the biz folk combat scope creep. It's much easier to cut features that aren't part of your CPO.

  2. Alan mentions above what I believe is the critical learning element your team needs to gain insight into via the Minimum Viable Product, Compelling Product Offering or other named approach . . . that being how many potential customers will have a willingess to pay for a core offering that you can consistently deliver on profitably.

    There is a distinction between product and offering. Those that focus solely on their product miss the potential found in communicating an offering that includes the product and other elements that customers place value on and increase willingess to pay.

  3. I've started a Wikipedia page for the Minimum Viable Product to burn it into my brain.

  4. Your often mention, but never name, your pre-IMVU company, which was presumably Will Harvey's There Inc.

    You refer to an anonymous Valley-based MMORPG that consumed years and tens of millions in development, but got little commercial traction. There was only one such company.

    No reason not to name it -- you're unfailingly respectful, and everyone in the industry knows most companies fail, so postmortems are not an insult.

  5. Great post. We are big believers of this principle at Pollenizer. We call it 'your core utility' - the smallest set of features to create value in your very very focused first segment.

    Quick video here with my views on focus;

  6. Without a doubt, this is the most forward thinking process/solution/methodology/post I've seen in quite awhile. Thank you. I know it's going to help me immensely!

  7. Thanks Eric. Refreshing to finally see lean and agile thinking emerge in product/business-floors and not only in technology. Critical also, as the lean company/start-up can not be lean by just using lean principles in IT and not in Product Development/Management - a common misinterpretation of the Toyota Production System.


  8. Great Post - could not agree more.
    My experience is in Enterprise Software - where we are forced to chunk features into formal releases.

    While it is still possible - and recommended to experiment with customers in order to determine the minimum that they need, the exercise is bit more complicated due to the formality of the release process.

    Most enterprise customers do NOT want frequent releases for two main reasons (1)They have heavy internal release processes: long QA cycle, security reviews, etc; and (2) It is costly to communicate and educate their own customers about a new set of features.

    While the release cycle is not as fast as it could be, the challenge of defining an MVP still remains!

    As I present in my blog, defining the MVP requires answering the following question: "Will our customers be willing to buy the product with these features - available at this date - at this price?"

  9. Thanks Eric, great blog! Definitely highlights the beauty of the web. Iterate quickly to uncover true market demands...

  10. Very nice post and video - I wonder how much this changes for people who are using the "eat your own dog food" model and building a product that they will use as well as sell.

  11. Thanks for the insightful ideas.

    I just came across a great example MVP -- the IMDb precursor lists. "The IMDb originated from two lists started as independent projects in early 1989 by participants in the Usenet newsgroup rec.arts.movies. In each case, a single maintainer recorded items emailed by newsgroup readers, and posted updated versions of his list from time to time." (

    Of course the pre-IMDb list maintainers weren't thinking about creating a lean startup, but they did put a lot of the concepts into practice. Perhaps IMDb is best described as an emergent lean startup rather than an intentional one. Nonetheless, the story is a good case study.


  12. Your presentation was something that I needed right now. Thank you so much for being so open about your ideas.

  13. What's the difference between a Minimum viable Product and a Proof Of Concept?