The True Purpose of MVPs

Minimum viable product (MVP) is a popular concept in the product circle. Product managers, designers, and developers are well familiar with it – but there is considerable misunderstanding and misguided assumption about what it is.  For example – MVP is not the first phase or deliverable of a pre-planned project.  This entirely missed the point!   

About the MVP

Minimum viable product is not just the initial product that is released to the market with minimal features. It also provides the customer with just enough features to at least be thought usable. The MVP reflects a strategy seeking and factoring market feedback early and often, rather than delivering a large project that consumes all of your resources before validating if there is product-market fit. 

Ash Maurya’s 2010 book Running Lean and Eric Ries’s The Lean Startup published in 2011 contributed significantly to the popularity of this concept. They drew attention to how companies end up with failed products by not adequately validating ideas. While MVPs are much more popular now, a good understanding of the concept seems to be lacking in many cases.

Where Things Go Wrong

The original idea behind minimum viable products is iterative development. They are supposed to enable fast learning for us to know whether we are on the right track and then work based on what we learn. The sad truth is that this is not the viewpoint that some product professionals have toward MVPs.

No iteration takes place in certain instances. The belief seems to be that there is only a way and if that fails we drop the idea and walk away. Let’s try this thing and if it doesn’t go to plan we jettison it altogether.

It is a fact that product development teams are constantly under pressure to ship something. There are often commitments to do this by certain dates or periods and developers must work to ensure deadlines are not missed. This sort of situation can impact adversely on getting real value out of MVPs.

By their nature, minimum viable products may be deemed risky in that they are not yet proven. It is uncertain what the response of customers would be towards them. Also, MVPs can take significant investment, which is part of why many people are tentative about them.

Initial product versions with minimal features aren’t necessarily bad investments if approached with the right mindset. They are not things we release and then walk away. MVPs should promote learning but that never happens in a lot of cases. There is a real abuse of the MVP term by some product professionals, one may say. They claim to be committed to learning and iterating on initial versions but they never really do that. John Cutler calls this phenomenon the MVP Bait and Switch.

A Better Approach to MVPs

It is hard to understand the talk about minimum viable products if we are not ready to show a commitment to learning. The initial basic versions should serve as learning tools. Of what use is building and releasing them if we are simply going to walk away after doing so? We should just stop talking about the concept already if that’s all we intend to do.

MVPs need to be viewed as a critical part of a learning process. They are product versions that we release to allow us to gather quick feedback and uncover necessary changes to requirements moving forward. They help us to find the right path to follow toward what may be deemed an ideal solution.

When building a minimum viable product, the aim should not be to get a winner right out of the door. We shouldn’t feel like we have failed if what we ended up with turned out to be useless. Our primary aim should be that of learning.

So we need not feel like failures if we have to discard the greater parts of the MVP. It is supposed to guide our discussions and work in the right direction. We should learn and make use of what we have learned. However, it is critical that we already have a good understanding of what the MVP should look like before even building one. We need to be sure to a significant degree that it will solve a key problem for the customer. We don’t just proceed to build one based on sentiments.

There is a need for us to do adequate research before going ahead to build an MVP. We have to relate with customers to really know their pain points and desires. There are diverse tools to help us do this, including interviews and surveys. Research reduces risks by helping to recognize poor ideas before going too far.