Maximum Viable Product | Hacker News Reader

Maximum Viable Product

measuringmeasures.com

57 pointsfogus7 comments

He lost me here: "A maximum viable product doesn't fail fast - it succeeds slowly as you iterate toward it with minimum viable products and learn along the way."

So there's nothing new there, that's what minimum viable product "people" have been doing. The hard part is to convince some people to follow the fail fast mantra. Getting passionate with big vision is easy as it is to be provocative and look innovative being so.

Some people won't get on board with fail fast.

Others are on board with fail fast, but they are purely focused on fail fast and don't get the vision part.

Ever hear people complaining that lot's of modern web companies look more features than products? Based on my experiences and interactions, that is primarily due to lack of vision.

Worst of all, some people have no vision and don't get fail fast. They are missing on both counts.

All I am doing in this post is giving my opinion that both the vision and fail fast execution are important, and this is the particular way that I think they fit together.

I don't think it's a lack of vision. More likely it's a lack of patience and guts. And a complete confusion about what constitutes a product and what constitutes features.

It takes patience and guts to focus on the core elements of your product and see if they have any merit out there. So often people compensate by adding all the features they envision could be added.

I normally use the hammer http://000fff.org/wp-content/uploads/2009/11/product_feature... as an analogy for explaining the difference.

That is at least my experience having worked on so many startups I can't count them anymore.

I really liked the article, and I think the Maximum Viable Product is a great concept. From reading some people's descriptions of MVP it seems like they expect their users to tell them exactly what to do. However, comparing user feedback to a bigger vision seems like the most important part of an MVP.

Bradford sorry for dismissing your post so fast but I don't agree with the way you try to conciliate the two approaches.

Those are two different problems at different levels. Minimum Viable Product is a principle to follow at a tactical level to drive the development. The strong vision you refer is required at a strategic level.

Depending on your role you should rely more on one or the other but trying to conciliate the two may just create more ambiguity because they guide decisions at different time-frames. A product manager without an holistic vision will not understand the drawbacks in adding yet another customer requested feature. A team lead focused on the strong vision will try to integrate the new feature with the whole system, slowing development cycles.

The two principles are fundamental for developing a great product but they define the mission of different parts of the system.

By the way, I really liked your blog. I don't know if it's new here on HN but it's new for me.

http://measuringmeasures.com/blog/2010/6/3/software-product-... Wow, love to see how you explained, it really ressonated with me. Yesterday in the end of the scrum sprint retrospective a big discussion arose where this would have been helpfull.

Liked this as well: http://measuringmeasures.com/blog/2009/12/2/the-decline-of-t...

Or looked at a slightly different way. We should only build things that customers want, and they find it very difficult to explain what they want unless we give them an application to try. When we do give them an application we will receive conflicting requests, and we have to decide which fit the product, or whether we can meld them into a more encompassing or strategic form. Once the customers start giving feedback my thinking is that the "vision" you talk about should just be our interpretation of what the customers ask for rather than being independent of them. Or less absolute, perhaps the proportion of development effort expended on non-customer-requested changes should be small compared to things which address their currently stated requirements. I'll stop rambling now ...

His idea might be right but calling it a "Maximum viable product" seems to lead in the wrong direction. MaxVP makes me think of feature bloat not innovation.

Reply on news.ycombinator.com