Published by
The idea of minimum viable product (MVP) is very popular with startups, especially those in the software and digital solutions space. However, more often than not, MVPs turn into MFPs (minimum features product).
The issue is that in planning MVPs, the business operations (such as sales), product and engineering teams focus on a feature set instead of focusing on the core problem and trying to solve for that.
In this piece, I have tried to highlight key differences between MVPs and MFPs.
1. MVPs solve for small but critical parts of a very big problem. For example, if the problem is that a person’s legs hurt from standing and the floor is dirty, the minimum viable product to solve the problem would be a simple, quickly made, low quality (therefore low cost) stool. However, in solving this problem, one might easily consider that a person’s back might also hurt since it doesn’t have anything to rest on (thus suggesting the need to build a chair), and then go even further to think that a person’s hips might also start hurting from sitting on a hardwood surface (thus necessitating the need to add a cushion or foam on the chair). And so, we are no longer talking about MVP, but more about a minimum features product to solve a few different problems. It’s best to create the MVP and then seek user feedback to determine next steps.
2. MVPs are not intended to offer a great experience. They are built to purely address the most important problem. In doing so, product managers are deliberate in parking any new problems they discover in the backlog and use that for future development. But if the product manager starts to focus too much on user experience, design and ease of use, then they are deliberately introducing new features and the focus is no longer on viability. The focus is shifted to features. Going back to our stool example, if the focus was on experience, comfort, design and ease of use, then the product developers are going to end up with a recliner and not a stool. It’s easy to lose track of the end goal and try to solve for multiple problems with the first iteration, but this takes longer to deliver and delays the gathering of important feedback.
3. Finally, MVPs are cheaper to build (relatively speaking). This is because MVPs are built on the idea that product managers and the delivery team will get something out to the market that does the job it is supposed to do. Goals of MVPs include being able to test the market, collect feedback, improve and launch a better version through future iteration. MFPs on the other hand have a set of features that need to be delivered. While the intent is not to take longer for delivery, it is easy to include features and sub-features that are not required to solve the biggest problem. It is common to witness scope creep and end up in a situation where the product and development teams are solving multiple problems all at the same time.
Let me clarify this — in the example used above, the biggest problem to solve was the person’s legs hurting from standing for too long. Therefore, the stool was the fastest option, thus the minimum viable product. One can say a chair would still solve the same problem which is entirely correct. But if the goal instead was to solve for backache and sore legs from standing too long, then most definitely, the chair is would be the minimum viable product.
Therefore, in order to identify what your minimum viable product looks like, it is very important to understand the problems you are trying to solve for and rank them in the order of biggest first.
As a product management consultant at Bottle Rocket, I am a big advocate of MVPs, as well as iterating and improving. This allows our partners to continuously improve and deliver features and enhancements with every release to their products, but also get something out in the market as quick as possible. If you are a product manager working on new products, challenge yourself to identify and rank problems and solve for the biggest problem first — thus allowing you to get to market quickly with an MVP.
