In the world of Product Management, a Minimum Viable Product (MVP) can serve as a canary in the coal mine allowing Product Managers and developers an opportunity for valuable feedback. When done correctly, MVPs can prevent wasted time and money and enable companies to get new products to market faster. However, misunderstandings of what exactly constitutes an MVP abound. These misunderstandings stem from the fact that Minimum Viable Product means something different to different people. As a result, product teams and entrepreneurs often miss the mark by delivering a minimal product quickly, perhaps even ahead of competitors, but that fails to offer value to customers. As a consumer, there’s nothing worse than being promised a solution to your problem only to be sold a false bill of goods.
To prevent this type of failure and misunderstanding, all stakeholders must be on the same page when it comes to defining an MVP. Going back to Eric Ries’ definition of MVP in The Lean Startup, “A 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.”
An MVP served as a market test. Over time, the concept of an MVP has succumbed to the pressure of sacrificing functionality for a quick turnaround time. The problem arises when Product Managers and teams take the ‘M’ in MVP at face value and fail to ensure it provides value to the target audience. This often occurs as a result of pressure to build something just to meet a deadline.
Once a company has lost the trust of consumers, it’s tough to regain that credibility.
When defining what constitutes a Minimum Viable Product, it’s essential to consider the following:
- Are consumers willing to pay for a solution to this problem? (Is it the right problem?)
- Does the product fully solve at least one problem for the target consumer? (Does it provide value?)
- How does this product stand out from its competition? (Does it provide customer delight?)
The first consideration here is whether the product is even solving the right problem. Just selecting a problem to solve is not enough. The product must solve a problem that is significant enough to warrant consumers paying for a solution.
Articulating the Right Problem
One of the first – and most important – steps in the product development process is ensuring a clear understanding and articulation of the problem. This includes accurately identifying the size or magnitude of the problem. The key to arriving at this understanding and articulation is to listen.
Remember, you’re looking to gain insight into what your users perceive to be a problem. You may just discover that what you had thought was a significant issue isn’t an issue at all. Is there a large enough market for a solution?
As you identify a target market, take the time to understand pain points, are there different categories of users within the market? How would each category define a successful product solution?
Be sure to validate your clearly defined problem statement with all key stakeholders. Ensure the problem is genuinely worth solving. Consider whether users have ideas for how to solve the problem, what workarounds they may currently be employing, and what other products on the market already address the problem and how.
The “Full Product” vs. an MVP
It is necessary to determine what the complete or full product will be. Include all the possible features in the product backlog. The backlog should reflect the needs of all users in the form of User Stories. Only after defining the complete product can you whittle down to the best subset of features and arrive at an MVP. This is done by analyzing and prioritizing all user stories included in the backlog. Now is the time to consider cost and feasibility, as well as the importance of solving the problem. Use these considerations to rank User Stories in order of priority and determine where to draw the line to define the Minimum Viable Product.
One common mistake entrepreneurs and product teams make at this stage is failing to prioritize features for inclusion in the MVP properly. One version of this mistake is overshooting for customer delight – including shiny features with bells and whistles only ends up wasting time and financial resources when they discover that customers aren’t even interested in those features. The other version takes the opposite track and focuses on the easiest or most cost-effective features to include. This version of an MVP skimps in ways that leave users with incomplete solutions to any of the problems the full product is intended to address.
Though it doesn’t need to be elaborate, the MVP, on its own, must hold customer value. By fleshing out the details of the complete product and then prioritizing down the list of possible features, teams can arrive at an MVP that not only holds customer value but does so quickly and at the lowest possible cost. Rather than selecting features at random to constitute an MVP, do your research and choose with intention.
Customer Delight Not Negotiable
The final triad in determining a good MVP is that it must provide customer delight.
Your MVP doesn’t need to be elaborate, but it should include some feature(s) that impress users and allow it to stand out from the competition. Think about it this way, when your product is “on the shelf” next to its competitor, does your MVP have a feature(s) that will differentiate it from the competition and entice customers? Again, these features don’t have to be major; they could even be UI features that affect customer experience.
Defining a Win
The product development process is fraught with competing desires for “must-have” features. Still, when it comes down to it, an MVP’s primary purpose is to gather user feedback for future iterations of the product. It doesn’t need to be flawless. An MVP built correctly should provide further direction for the product development team. If you can get users to buy your MVP and use it as an imperfect and incomplete product, just imagine how well you’ll do as the product continues to iterate and evolve.