In a recent interview onVenture Hacks (Advice for Entrepreneurs) commentator Eric Ries discussed the concept of the Minimum Viable Product (MVP) – doing “just enough” to meet customer needs in order to get a product THAT PEOPLE WILL PAY FOR to market as soon as possible. As Reis says:
The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.
He contrasts this with the fairly typical “build every feature we can think of” scattergun approach :
But the problem with that is you won’t get any feedback until you’ve already built all those different products.
All those different features, so you ship this product with a ton of features, and generally, by the time it’s done, it’s too late to make sure that you are on the right track.
Focusing on the minimum viable product is useful because you can basically say, "look, our vision is to build a product that solves this core problem for customers, these kind of general feature areas, and we think that for the people who are early adopters for that kind of solution, they will be the most forgiving".
And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.
In the interview he provides some examples of where his company has achieved good results by focusing on the MVP, and recounts problems that arose when they didn’t.
He gives advice on using the MVP to truly validate the product vision – if you can’t identify the MVP you’re probably trying to build the wrong product – kill it early!
I’ll have entrepreneurs come up to me and say, “But hold on, my customers don’t know what they want. If I ask them ‘Do you want this thing?’ They might say no when the answer is really ‘Yes.’”
Unfortunately, that’s an excuse that is used way too often, but there are situations where it’s true. The judgment call is; what really is the minimum set? In some cases like in entertainment products it might actually require you to build an early prototype, or a mockup, or even version one of the product with the minimum possible set of features that you think could go.
The nice thing about minimum feature set is you can always try intermediate points to ask yourself, “Am I at the minimum feature set yet? Am I at the minimum feature set yet?”
As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that you give up because, “Oh, forget it, we’ll never make it.” You’ve got to say, “OK, well then let’s iterate some more.”
If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself, “You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”
He continues to discuss how the application of Agile practices such as TDD, short iterations, and minimum design allow the evolution of a product that delivers value and competitive advantage. He compares the flow of features to a non-linear network such as the Internet:
I now think about that rather than as a linear sequence, I actually think about it as a big network. The question is; just for any given feature, in what path should you route it through that network? Different features should be routed differently, just like on the Internet we route packets differently as necessary
He cites an example of going so far as deploying a feature without actually building it to gauge customer feedback and identify if the feature will actually add value (if we build it will they actually want it?):
There’s one link on one key page that notifies them that they can go do this other thing or at a key moment they receive an email, even though the feature might be wide and complicated.
Generally, access to the feature is controlled through a simple choke point. We would often add those choke points in a split test just to see first of all, did anybody click on them? So we could look at the click-through rate of people that now believe there is this feature.
We would also see an interesting phenomenon, sometimes the presence of a feature, even if nobody clicks on it, still impacts their behavior in other ways.
The full article can be found at http://venturehacks.com/articles/minimum-viable-product
Even if you’re not building products that need venture funding, how can these principles assist in the prioritization and sequencing of the work on projects?
