BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

The Minimum Viable Product - a tool for exposing value

by Shane Hastie on Aug 31, 2009 |

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.
 
 

 
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?

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

MVP, meet MFF by Stuart Stern

The idea of sequencing development around MMFs (Minimum Marketable Features) was originally explored fully and endorsed by my good friend Mark Denne in his 2003 book, Software By Numbers (www.amazon.com/Software-Numbers-Low-Risk-High-R...).

But, will a customer pay to know a product is not viable? by Francisco Jose Peredo Noguez

This MVP idea sounds good in theory, but does it work?,
For example, for custom outsourced development, it is also very hard, because (so far in my experience) no client is interested in a company that tells them: Sorry, the new payroll/purschase orders/ecommerce site you want to build is "not viable". They are looking for companies that answer "yes, we can do it".

For inhouse development it is even worse, because this kind of things are generally aready budgeted and approved since the begining, and the only expected outcome is success (so if after some interations your answer is "this is not viable" they will fire you, and hire something that says it is viable, even if the project ands up being a black hole that sucks the company in to project hell)

Companies do not recognize the value of eairly failure by Francisco Jose Peredo Noguez

The problem I think is that enterprises do not recognize the the value of eairly failure, they do not see as a good thing that someone tells them: "you are on the road to hell, but you are early, if you stop now, you may still save you soul" What they want is someone that tells them "go ahead, if you come with me, it does not matter that you are going straight to hell, I will magically make it heaven, as long as you keep doing what I say"

Re: But, will a customer pay to know a product is not viable? by Keith Moore

If the company you work for fires you for suggesting that something is not viable then perhap looking for a new job is a better answer. I agree there are companies out there that have this kind of attitude, the solution, I believe, is try and change this culture. It takes a lot of effort and patience but I have worked at places where the team has changed this around. I've also worked at other places where it didn't and I ended up leaving.

YAGNI for Product Design by Andy Dent

Isn't this just applying YAGNI (Ya Ain't Gonna Need It) at the level of product features, rather than internal design?

If you regard design as a continuum, as I do, the same principles should be applied everywhere.

My variant on MVP is Imagine the Advertising Campaign - if a feature isn't going to support the core message in your imagined advert of the product then it is a candidate for culling.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT