Minimum Viable Product (MVP) is a frequently used word today in development. For a Product Owner it is one of the foundations of Agile and a successful product. However, are you sure you know what MVP is and how it differs from the minimum marketable product (MMP)? Many people mistake or misuse these terms. Even when you google the definition of MVP, it is very easy to come across confusing information. If you (don’t) understand that you do not understand MVP, keep on reading and we hope, you will understand :).
Minimum Viable Product (MVP) in practice
Minimum Viable Product is not a finished product or version 1.0. It is the smallest part of the product that clearly demonstrates its main functionality and is available to the public. MVP does not have to work, it can be a prototype of a web application explaining the main idea of a product, for example. MVP’s role is to get feedback from the user and learn what he likes about the product and what the things that he does not need are.
MVP is a minimal version of a product that should teach us how the user perceives the product.
And what it looks like in real life? Let’s look at an example of a farmer who grows two varieties of apples.
The farmer wants to sell them in a shop, but he doesn’t know how to build a basket so people would like to buy the apples and at the same time it would bring him the greatest benefit. So he creates several baskets with a different combination of apples, different prices and takes a few of the baskets to the store.
He will watch how many pieces of what kind of baskets are sold and how people react. Nothing complicated, he does not focus on the packaging and does not try to promote it in any way.
Each basket in this situation represents one minimum viable product. By doing this, the farmer will find out which product is the most purchased and can decide what type of basket to sell as his official product.
Sometimes even simpler testing is enough, e.g. sell a few baskets of organic apples at a farmers market, make a Facebook poll, or you can also create a website where people can click on photos of different baskets.
Each basket with a different combination represents one MVP. MVP emphasizes only the main idea of the product, apples, and does not pay attention to the packaging or other things. By testing, MVP1 has been shown to be the most popular and has become an MMP through refinement. Once launched on the market, MVPs are tested again for additional parameters.
After MVP we will improve the product to MMP
Minimum Marketable Product is an advanced viable product. Here we can talk about the commercial version 1.0. It is a product with a minimum amount of features that are supposed to satisfy the user experience and at the same time, has a value.
Unlike MVP, this is already a functional product that we launch on the market. However, one rule is applied: less is more, it truly is a minimal product without various ‘enhancement’ features. The reason is simple. Create a minimal product quickly, test it quickly, and deploy it faster. It is simpler and thus contains fewer errors. By getting feedback, we improve it further, if necessary. The entire process of the minimum marketable product is, therefore, more cost-effective.
MMP is a product with minimal amount of features that satisfy the user’s experience.
By designing multiple MVPs, our farmer has identified which type of basket people like best. The result is transformed into a professionally prepared basket. He suggests a more beautiful packaging, puts an advertisement in the store flyer and creates a minimal but tradable product. It still is a minimum, so he will have to stick to his tested concept. If he wants to expand the product, he can do so in the next steps. He can start another MVP to see, if people prioritize the price or appearance of the basket, whether they are interested in a mix of fruits, and so on. By using MVP and MMP, the farmer has gotten the right product on the market efficiently, quickly and at a minimal cost.
Examples from famous MVP companies
We can test MVPs very simply. Proofs of that are several well-known successful companies that skillfully tested the market without launching a functional product.
Zappos, an online shoe sales company, was bought by Amazon after 10 years. Their MVP consisted in the fact that the founder took pictures of shoes in various stores and uploaded the photos to a simple page. When the user wanted to buy shoes, the website referred them to the store address (more about their beginnings). The product did not work but tested whether people would be interested and dare to buy shoes over the Internet and whether it is worth to start with the development. At that time, however, it was assumed that ladies prefer to ‘feel the shoes’ in their hands and try them in person. The founder of Zappos has saved millions whilst building eCommerce solution that could have been thrown out of the window if women didn’t want to buy shoes online.
Dropbox tested the interest of people and investors only with a video demonstrating the main functionality. A funny video made by the founder increased the number of people waiting for the beta from 5000 to 75 000 people.
Slovak Sygic created commercially sold add-ons for their successful navigation (DashCam, Head-Up display) during internal hackathons, where they checked if their ideas make sense. Only after the feedback they incorporated them into the portfolio as extensions to the navigation app.
SpaceX approaches its missile development equally, using agile. Their first Falcon 1 was built with the goal of commercial use. When they found that there was not sufficient market for small rockets (like Falcon 1), they shifted their attention to the new Falcon 9.
The heavier rocket was even more cost-effective and its engines could return to Earth, making the Falcon 9 their first commercially successful rocket. They were not afraid to ‘throw away’ their work when they found out it wouldn’t work and move to something with better potential. With this approach, they have worked their way to missiles like Starship (or BFR), which are expected to travel to the Moon or Mars and test the possibility of transporting people across the globe through space.
Common mistakes
- MVP is used instead of the correct term, MMP.
- Epic is not an MVP/Not always as a rule. One MVP/MMP can be created from multiple epics. An apple represents epic in the picture, MVP/MMP is the whole basket that we are testing, i.e. selling.
- MMP is not a time milestone.
- MVP does not have to be a functional product, however, MMP has to be.
- MMP as a whole must have value for the user. It’s not just a set of supplied features, epics.
- The result of MVP is feedback with impact on further development, product direction.
Summary
When designing MVPs, it is essential to be clear about the problem that MVP solves and focus on that. It’s more than enough to have the idea of the product which can be presented to the public. It does not necessarily have to be a functional product.
The goal of MVP is to get feedback from users before starting a costly and time-consuming development. Implementing multiple MVPs will show exactly what users like about the product and help to build MMP.
MMP is a minimal but valuable product with an emphasis on properties favorited by people. Thanks to these tools, we get a product that we launch on the market in a relatively short time, at minimal cost and with amazing quality.
In this day and age, less is simply always more.
