Approaching a Minimum Viable Product

The purpose of the MVP is to answer your most pressing question or validate your most pressing business assumption. Work backwards from question, not forwards from a feature list.
For Tattlebird, my most critical assumption was that stuff was happening in browsers that site developers would care about. Working backwards from that I needed to gather the data in the browser, send it to a server, and show it, minimally, to a single user. That was the list of features for my MVP. Nothing happened in the first few minutes so I was ready to move on. After a nap, though, there was a flood of exactly the kind of information I was hoping was out there.
Your networking platform must have a twist, something no other professional networking platform currently does. If users don’t care about the twist you’ve found, your idea (this iteration of the idea, anyway) is invalid and you’re best off moving on to the next idea.
Let’s say the twist is location–you have the professional network that shows where people are in real time (hey, not a bad idea!) If people don’t care about location, it’s time to move onto the next idea. How are you going to find out whether people care about location? Well, you have to have a system that two people can use, the system has to have some way to find out where they are, and the system needs some way to notify both people where the other one is. There’s the MVP–what’s the fastest/cheapest way to get that done and then ask users whether they care?
That’s how I practice MVP, in any case.

Eric Ries [update] is the latest product developer to promote “Minimum Viable Product” to describe a product created to elicit feedback. A recent mailing list question suggested to me that more explanation was necessary. Here are my thoughts on what an MVP is and how to approach it.

The purpose of the MVP is to answer your most pressing question, to validate your most pressing business assumption. To create an MVP work backwards from your question, not forwards from a feature list. Invest as little as possible to answer the question because after this there will be another question and another and you’ll need enough money to answer them all.

For Tattlebird [my new product], my first critical assumption was that stuff was happening in browsers that site developers would care about. Working backwards from that question, all my MVP needed to do was gather data in a browser, send it to a server, and show it, minimally, to a single user. That was the list of features for my MVP. An hour later there was a flood of exactly the kind of information I was hoping was out there.

Your networking platform [the original questioner was asking about the MVP for a professional networking platform] must have a twist, something no other professional networking platform currently does. If users don’t care about the twist you’ve found, your idea (this iteration of the idea, anyway) is invalid and you’re best off moving on.

Let’s say the twist is location–you have the professional network that shows where people are in real time (hey, not a bad idea!) If people don’t care about location, it’s time to move onto the next idea. How are you going to find out whether people care about location? Well, you have to have a system that two people can use, the system has to have some way to find out where they are, and the system needs some way to notify both people where the other one is. There’s the MVP–what’s the fastest/cheapest way to get that done and then ask users whether they care?

What’s Hard About That?

I don’t know about anyone else’s practice of MVP, but what makes it hard for me is completely irrational: I prefer dreams to answers. I’m not saying this is a good thing or useful or sensible, you understand. It’s just something that’s true of me that I’ve come to understand.

For example, after I validated potentially-fatal assumption #1 for Tattlebird (“interesting stuff happens in browsers”) I needed to validate potentially-fatal assumption #2, “Developers will find the information useful, not just interesting”. That is, I need a story where a developer says, “Tattlebird told me surprising fact X, so I did Y, and now I’m making $Z more.” I don’t know if such a story is possible. If I can elicit such a story I may have a business. If I can’t elicit such a story, I need to move on.

Here’s where the dreams/answers dilemma comes up. Since I got the answer the PFA #1 I’ve been walking around with dreams of financial security floating in my head. It feels good to think I could make my living programming again. I don’t want to give that up. If I want to actually achieve that dream, though, I have to let go enough to find out if PFA #2 is true or not.

I could have gotten PFA #2 validated the day after I got a thumbs-up on PFA #1. Instead I fiddled and fussed for a week, a week I could have been using to get answers to PFA #2 through N. Yesterday I finally expanded the MVP just enough to get my answer and contacted someone who might use it and experience “the story”.

Conclusion

When I look back at all my startup experiences (all of them eventually sunk on a PFA), every single one of them could have been shipped much sooner. Sometimes the barrier was intellectual: it’s just plain hard to see how to ship 1/10th of a new piece of hardware. (Hard but not impossible.) By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.

The problem with chasing the dream too long is that you end up without the resources to change direction when a PFA comes true. The MVP is intended to counter this tendency. The process of working backward from the assumption to the least possible investment to validate the assumption saves resources in the case of difficulties and keeps the business on the path of learning.

21 Comments

Jeffrey FredrickAugust 7th, 2009 at 7:03 am

Interesting insight!

Most of the startups I’ve worked for have had technical founders and there generally has been more emphasis on solving the technical problems than exploring the PFAs.

Gene MyersAugust 7th, 2009 at 7:49 am

Ken, an interesting post that yields another perspective for something which I’ve coined the phrase, ‘Quality Continuum’. The Quality Continuum is the effect of adding features to a product, and the subsequent of unconsidered overhead that ensues. Imagine a horizontal line; up from that are your products features, and down from that are the products (potential) defects. The more features you have, the more (potential) defects you have, or at the least, the more unit tests you need to write, potentially higher maintenance overhead, and less time for UX testing. I’ve used the Quality Continuum to illustrate the hidden overhead in adding features (vers 1.0 MUST have ALL of these features to be complete and competitive!). As the features increase, the (potential) quality decreases, in a non linear fashion, similarly to the way the time it takes to execute an algorithm increases non-linearly as its complexity grows, as illustrated with Big-O notation.

Now, having said that, I had an euphony the other evening when I realized my vers 1.0 was becoming too complicated. My answer was to draft a feature roadmap, staging the features over time so I can concentrate on the most important ones first. And while I whole heartedly believe in doing the simplest thing that works, I’m learned to make sure I anticipate and design for scalability and future features.

I very much enjoyed your honesty and humility.

Dylan HassingerAugust 7th, 2009 at 10:48 am

Awesome post, thanks.

Taylor NorrishAugust 7th, 2009 at 11:49 am

Awesome dude. I too am a product guy dreamer, and your post gives me discipline to make feedback a priority.

Loved these lines:
“reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback. The problem with chasing the dream too long is that you end up without the resources to change direction when a PFA comes true”

Peter J. HartAugust 7th, 2009 at 12:09 pm

Great post.

Do you have any ideas how to implement this in large corporations, where the specs are by decree and everything needs to be spelled out before work begins so no one is “liable”?

Tobin HarrisAugust 7th, 2009 at 12:18 pm

Most Viable Product seems nicely congruent with the notion of “fail fast”; if the idea isn’t going to take, you need to find out very quickly!

Great post btw, I love this sentance (highlighted on 37Signals blog)

“By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.”

NiviAugust 7th, 2009 at 12:21 pm

Eric rocks but he didn’t invent the name or idea of MVP. It has been around for some time among product developers, e.g.: http://bit.ly/3Eucl7

KentBeckAugust 7th, 2009 at 12:22 pm

I agree that founders are often technical, but that’s no excuse. We all get ~3e9 seconds on the planet. If we’ve been giving the gift of programming we have a responsibility to make an impact with that gift. Laboring in the basement for five years on a product that turns out not to have any impact is a waste of potential. The techniques required to maximize impact are intellectually challenging, but not out of reach. The emotional side, however, is a constant struggle (at least for me).

KentBeckAugust 7th, 2009 at 12:46 pm

Peter,

I wrote about this in http://www.threeriversinstitute.org/blog/?p=305 “Every Project a Startup”. The biggest challenge is see is changing the culture so that “failure” (that is, learning that further investment is wasteful) is celebrated instead of punished. The person who blows through 20 ideas in a year, proving that none of them represent ROI, could save the company millions of dollars. This is, sadly, a virtually-nonexistent skill in the corporations I’ve worked with.

KentBeckAugust 7th, 2009 at 12:50 pm

Nivi,

My bad. I’ve updated the post. Thanks.

Kent

[...] Three Rivers Institute » Blog Archive » Approaching a Minimum Viable Productthreeriversinstitute.org [...]

Dale CookAugust 7th, 2009 at 1:54 pm

That’s a great post.

I had a similar experience over the last couple of years. Two start-ups ago we had GlueNote, it was a “always on, always available” note taking application but it never even launched – we ran out of money because we were always second guessing what the users might want, always adding features, or redefining the feature set. Eventually it became bloated and fragile – something you don’t want in a start up. Gatherra then followed, similar story, although we did launch that one, but the market never took to it.

This time I tried something different. With no money I relaunched GlueNote, this time as glunote.com (dropped the e)
It’s a note taking application for Twitter. It’s still always on, and always available – but it’s simple, straight forward, with a minimal feature set. If it works great, if not no problem because it’s a few hours of my time and no money at stake. Plus, and it’s a big plus, for the first time in a long time, it was fun to develop something – no investors, no deadlines, no feature creep. The way it should be.

AronAugust 7th, 2009 at 3:54 pm

If only I had read this before or even during our last dev project. Great post.

Knowtu » links for 2009-08-07August 7th, 2009 at 5:04 pm

[...] Three Rivers Institute » Blog Archive » Approaching a Minimum Viable Product (tags: software product) [...]

RaminAugust 7th, 2009 at 7:00 pm

Awesome blog post! I actually do not care about programming (and I can’t do it), I just stumbled accross it accidentally. But this is true for so much more than programming! Thanks.

Parag ShahAugust 7th, 2009 at 11:23 pm

Hi Kent, Thanks for posting this. Just recently I read a blog post about a startup founder who had to shut down their startup after 2 years, because they released very late and probably made fatal assumptions.

I look forward to reading more of your experiences as you move ahead with your new idea.

[...] Three Rivers Institute » Approaching a Minimum Viable Product [...]

[...] pointed me to Kent Beck’s recent ‘Approaching a Minimum Viable Product’ post. “By far the dominant reason for not releasing sooner was a reluctance to trade the [...]

Andrew WatsonAugust 15th, 2009 at 6:02 pm

I wasn’t familiar with the term MVP but I actually was doing exactly that with my latest startup. I didn’t want to invest too much time in the wrong set of features before I knew what people would use/pay for so I created othernum.com with a bare minimum of functionality (admittedly, I may have overdone it and gone TOO minimal but I digress…) and I am now in the process of trying to get those PFAs answered.

I’ve given accounts away to a couple of other startup companies in the hopes of getting feedback from them. I have a long list of “standard” features that every webapp should have and I’m checking them off one at a time.

Thanks for a great post that really sums up a good approach to the situation a lot of startups find themselves in!

[...] [...]

isambard » Quote of the week (7 December)December 29th, 2009 at 3:13 am

[...] Kent Beck, quoted at 37 [...]