Minimum Viable Product

Today's columnist is Emma Jane Hogbin (who, BTW, will be speaking at the Women in Open Source conference in a few hours). She writes:

A few weeks ago Eric Ries, author of Startup Lessons Learned, taught me my new favourite term: Minimum Viable Product (MVP). I learned the term during a session at an unconference. I was pretty sure I wanted to learn about micro-businesses, not startups, but Eric's session was as close as the schedule came to combining "small" and "business." The session was fantastic. If you're like me, you have a bit of a morbid streak that loves to commiserate with other businesses about your failures.

The session was full of delicious new ways to fail. My favourite example was tied to the explanation of a MVP. After weeks of working on features, a project was made available for download. No one downloaded it. The MVP in this case was actually a download link. It would have told the developers no one was actually interested in downloading the product they were creating. The link could have been empty and it would have taught them the same lesson.

Let's take a look at the definition of an MVP: "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".

There are a few key words and concepts in here that deserve special attention. "Minimum" and "maximum" are of course completely subjective. Your team will need to decide what balance needs to exist between these two terms. The second part of this idea is that you are looking for validated information about your customers. You don't need a lot of people to tell you things about your product, but you need to have enough to tell you whether your assumptions about your customers were right or wrong.

MVP, is similar to the well-known open source expression, "release early, release often." It goes a little farther though--it's not just about getting your code out; it's about getting your code out with the intention of learning something about your customers. In other words: it's not about your code; it's about your users. Just this week someone told me they pushed code they knew was broken to motivate another developer to complete a task they'd promised to work on. Ouch! Of course I knew they weren't actually pushing broken code out to the customer, just out to another developer. Their MVP was broken code. They knew broken code would be more successful at getting a feature implemented over having no code at all. Don't make this mistake with code you push to your end users. It will teach you only that broken code makes users angry, discouraged and it may even make them switch to another product.

Your product has to work for you to gain information about your customers. You must fully complete a task before starting the next. In my experience, 100% of a useful feature is better than 80% of 5 potentially useful features. Mobile text messaging and microblogging, when done right, is the simple exchange of 140 or so characters. There are all sorts of extra things that you can add to this but, at a minimum, the message needs to get from one person to another. If you think up a new feature to add to the first, make sure it too works before you ask the public what they think of it.

MVP doesn't need to be limited to code. Examples that may be relevant to your project include:

A/B split testing on marketing pages: what is the minimum feature list that will get people to sign up for notifications about your project?

AdWords: what feature description makes people click through an ad to get to your project's website?

Documentation: Do people really want to read an entire User Manual? What's the minimum documentation you can produce which does not result in support requests?

Take a look at the project you are working on right now and find your minimum viable product. Finish up that one little thing you're working on. Push your product out and learn the lessons your customers have to teach now. Stop fussing and start getting real feedback on what is going to make your project succeed.

You can read more about the concept of the Minimum Viable Product on Eric's Web site.