The MVP Problem
MVP or Minimum Viable Product is a term that gets used a lot. It is also one of the most misunderstood and problematic concepts in modern product development.
Breaking down the MVP
First, some definitions will help us to understand it better.
the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. - Eric Ries
A minimum viable product (MVP) is the most pared down version of a product that can still be released. - Techopedia
So our MVP is a small version of a product that allows us to gather data about our customers. It is an experiment but also a real product that allows us to gather data and decide what to do next. That seems like a simple approach but let's consider the ramifications of an MVP.
Is it Minimal?
Most products are a collection of features that when combined make a unique product. Which features are required for a minimal product is the source of debate in most projects. As a rule of thumb, we normally say that if a feature is not essential to allow the product to add value then it should be left out of the MVP.
This can sound simple in theory but the reality is far more complicated. In an ideal situation you are building an entirely new product and you can spend some time working out which features you really need. Identifying features can be far more complex for products that replace an existing product or set of products. In these cases it can be tempting to say that minimal means everything the existing product does but then your ‘Minimal’ Viable Product becomes very big.
When the feature set is large it can be a sign that the team does not really understand the core of their product yet.
Is it Viable?
Product viability is a part of an MVP that is often overlooked. For a product to be Viable it must do the things that an end user needs to get a job done. It does not need to do everything but often doing half a job can make it unsuitable for testing with users. It can be too far removed from the real product to make the user testing valid.
In some cases you need to develop an integration or do some experiments with an external system. That work can be useful but what you have there is a Proof of Concept rather than an MVP.
What goes wrong with an MVP?
The most common problem we see are project development teams trying to build an MVP when that is not appropriate, needed or what they are building is simply not an MVP.
The giant MVP.
This happens when a team cannot bear to drop features from their MVP and have missed the focus on what they’re trying to build. An MVP is not simply a product with less features, it should be there to test the core proposition. If a team is not clear about what that proposition is then the MVP grows to the point that it becomes a full release the team doesn't know when it will be ready.
It can also happen with internal products that replace an existing system. Teams often start by saying the new product must do everything the old one did. This seems like a logical starting point since most organisations would want to avoid dual running or making a complex process where both the new and the old system have to be used at the same time. The scope of the MVP will continue to grow as the existing system is examined more closely and all the details of the system come out.
The micro-MVP
The micro-MVP happens when the scope of the MVP is cut to the point where it stops being useful. The most common cause is when the MVP development is limited in time or money so when it becomes clear the project will overrun the scope gets cut.
The danger with the micro-MVP is that the result often cannot be released or tested. It lacks so much functionality that it fails to prove anything. It is common to see organisations label phases of a project as MVP1, MVP2 etc so that they report the success of building the first MVP to management but it is actually an empty shell.
When should you build an MVP?
If the organization is building a brand new product then an MVP makes sense. It is there to prove there is a market for what you are building and that your product will solve a real problem. This can save an organisation from spending a lot of time and money on something that has no market.
If the product is for internal use and it is to replace an existing product or process then do you need an MVP? In most cases the answer is no. The purpose of the MVP is to validate if the product will have a purpose but if you are trying to replace an existing product then you know there is a place for it. If you are building an internal product then you might not need an MVP.
Is there an alternative to an MVP?
The approach that we like to take is to think about Version One, rather than an MVP. The difference is that Version One is the first fully functional version of your product. When we develop products we start with the users and run a number of prototypes to find out if we are solving the problem. These can be clickable designs, technical integration experiments or something in between. We are want to answer the following questions:
Is this product going to be useful?
Can we actually build this product in the way we think?
How much work will it be to get to Version One?
We find this prototype phase answers the questions that an MVP would answer but by making it clear these are only prototypes rather than a minimum viable product we keep the focus on experiments rather than features.
Then, when we are all happy with what we are building and why we should do it we can plan our first release. We normally call this Version One, it should have all the features that are needed to make it useful but only those that are really needed for it to do its job. The reason we call this Version One is because it should be clear that this is only the beginning of the product, subsequent versions will be needed to make the entire vision a reality. Once the first version is released we start on Version Two and gather data from Version One.
Normally Version One will be the largest release of the product, subsequent versions will normally come out every few days or weeks. At this point we can move quickly to iterate the improve the product.
We find this approach is easier because it draws a line between prototypes and product development. It makes it clear that the first release is the start of a journey and not the end plus it removes the confusion that comes from terms like MVP.
Summary
The principle behind the MVP process is good but we see the execution often fails. The problem is that terms like MVP are loaded with details that are easy to get wrong. We like to keep the good stuff and restructure it into a set of prototypes and a Version One. That way it's easy for everyone to understand and you can focus on the product, not the terms.
