Let's start with the name: MVP means a Minimum Viable Product, sometimes it is mistakenly defined as a Minimum Valuable Product or a Minimal Valuable Product. But the main problem is certainly not in the title, but in the fact of understanding of this approach and in the way it is used in practice.
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, an American entrepreneur and author of «The Lean Startup»
The main purpose of MVP is to get meaningful feedback from users, understand what they need, and do not create what they are not interested in and for what they are not willing to pay. Within this concept, you can validate the business idea about the relevance of your product. To better understand, compare the two approaches: when you make a complete product the outcome is a happy customer, when you make MVP the outcome is the validation of your idea.
Once again, MVP is not a full-featured product due to which users solve their problems. Moreover, to validate the idea, we do not need to create a product as something tangible and something that can be used. This can be a prototype, a set of mockups or even the results of a survey of a likely target audience. You need to understand that the outcome you are getting when building MVP is needed to confirm that people will pay for it, and it often doesn’t include everything that the final product would.
MVP is a tool that we use in order to experiment, to find out if the market really behaves like we assume it does. Daniel Collado-Ruiz, Senior Coach and Partner at Nestholma
In any way, MVP doesn't mean a raw product or its unfinished version. Just when we develop it, the emphasis is only on the necessary functions, the relevance of which is validated for the real users. MVP concept allows you to reduce the time-to-market by implementing only the necessary features and to begin receiving real feedback on your product as early as possible. In other words, it needs to deliver just enough of the desired outcome for users who want to use it, or even buy it, and most importantly provide you with enough data to base product and business decisions on.
To illustrate this approach, the well-known Knigberg's picture with vehicles is usually used. Pay attention to how the icon with the customer's emotions changes in the bottom row: first he is not very pleased with the result, but then gradually he becomes happier, especially in the last iteration, when he receives the completed product.
Very often other pictures are used, where the customer's face in the «right» approach is happy all the time. Because of this, it is erroneously concluded that he is satisfied with the bicycle, although he ordered a car. Аnd another option is proposed with the transformation of a car appealing to what exactly the car is expected by the customer. All these disputes and clarifications come from the misunderstanding of the metaphor originally laid down by Henrik Kniberg (in fact, the customer wanted a vehicle), as well as from a mistaken perception, what exactly is MVP.
So how do you eventually build the product in the right way using the MVP concept? To this end, Lean's gurus recommend the following.
Learn a business context to define the product idea and determine the metrics by which its viability will be validated.
Build the minimum required set of product features that will allow you to validate the idea.
Measure the metrics, review the feedback, and, if necessary, repeat all steps with a new idea about this product.
To better understand this algorithm, I propose to consider the more successful metaphor «The cake model» by Brandon Schauer. Want to make a wedding cake? Invite the customers to try a cupcake so that they appreciate the taste. Then you can try adding new ingredients and increase the scale of the product.
This metaphor successfully reveals the question of how to correctly choose the characteristics for each release of our product. Any version of the cake in the cut should contain the following four layers that determine the «taste» of the product:
it should be technically feasible;
the product must satisfy the needs of customers, so it should be valuable;
every up-to-date product must have a good UX, so it should be usable;
and finally, users should not just be satisfied with it but it should be delightful.
In software development, there are certain approaches that are used to be mostly taken, and the advent of a new concept caused the confusion between POC, Prototype, and MVP.
Proof of Concept (POC) is a micro project, which is usually tested inside the company and not taken to the public. Its purpose is to validate a certain concept that can be achieved in the development process. Usability is not taken into account at all, the set of features is only the most necessary, the quality can be ignored, the time costs should be minimal in proving that the concept is fundamentally viable. Comparing with MVP we can metaphorically say that POC has only one «cake layer» of feasibility.
A product prototype is a working and interactive model of the final product communicating its design. The prototype allows you to create a visualization of how your product will work, demonstrate user flows, and give an idea of the navigation and layout. While the POC shows that a product or concept can be done, the prototype shows how this will be done. This allows you to better explore the product capabilities and fix problems early during the development process. In comparison with MVP, we can say that the prototype has almost all «cake layers», but you can not actually «eat» it, but you can estimate how it will taste.
And finally, MVP is a minimum representation of your complete product, which allows you to test it on the market. This gives you an opportunity to know how your users will react to your product before spending resources on creating something that they do not need. While the prototype eliminates problems in the initial stages of development, the MVP iterative process is designed to better understand the needs of users when the product is actually already presented to the public. Thus, the MVP must have all the «cake layers» to be tested in the actual market conditions.
Summarizing the above, we analyzed the most common mistakes in the name of a Minimum Viable Product concept, figured out why a new concept is needed, discussed what it should include and how to illustrate it better, and how to use MVP approach correctly in practice in the development of software products.