image description
« Back to blog

Creating a Minimum Viable Product (MVP): Common Errors, Tips and Case Studies

 

The term Minimum Viable Product (MVP) was popularized in 2008 by the American entrepreneur Eric Ries. It is an essential part of lean methodology, a philosophy that has been imposed in investment policies in both mature companies and startups. Ries defined an MVP as the version of a new product that collects feed back from a prospective client with minimal effort.

The definition of MVP is simple enough to spread quickly. It has the overwhelming logic of something obvious like listening to the customer before continuing to invest, but it is subjective. Consequently, getting the minimum version of the product is a problematic task.

Although the MVP concept has penetrated project management teams, mistakes and confusion are common when implementing.

  • When the person who defines the MVP is the same person who devises the new product, it usually ends up oversized. In the creative process, the creator simultaneously assumes the role of the buyer and the supplier. It is often difficult to forego some designed functionality to create a smaller version of the product. In this sense, it is always advisable for somebody outside of the creative process to be the buyer in order to isolate the necessary functionalities in the MVP.

 

  • The MVP is not the cheap version of the product. The definition of MVP means that it requires minimal effort, but minimum is not necessarily small. Innovative products are often supported by technologies that require custom development. Tailor-made development requires a high starting budget.
  • The MVP is designed in the planning phase of the project and never during the development of the project. When project managers plan the MVP in development phases, they can expect delays in completion. Then, to avoid delaying the market, they change the MVP’s design. Defining the MVP in full development involves distorting the concept of minimum version, since it includes the functionalities that are already completed. These features might not be included in the MVP if it was designed before launching the development.
  • The selected functionalities for the MVP come from the type of feed back that the client wishes to collect. The most sensitive part of MVP’s definition is what feedback, exactly, I want to collect from the first clients. The MVP should gather information to evaluate a specific business model. If  success means mass adoption of the product, the MVP must include the functionality to test the speed of adoption. If the business revolves around paying for a new product, the MVP must get the user to understand the purpose of that product, the problem it solves, and the price. Thus, the user will face the decision of whether it is worth paying in exchange for solving the problem. Finally, if the product competes with others already established in the market, the MVP must include the functionality that differentiates it from the competition, in order to know if that attribute will attract the customer.
The MVP should gather information to evaluate a specific business model.

Cases in practice

Take Facebook. When it launched, social network markets already existed. Therefore, the Facebook MVP should not test the acceptance of a new product, but rather how it differentiated. In this case, its difference was a select audience with an emphasis on sharing photos. These differential elements should be included in the MVP. Including functionalities like chats, advanced messaging, or image tagging would be superfluous.

Uber was the first service designed for renting private vehicles. Since customers already pay for a taxi service, it is not critical to test if the user would pay for the service itself. Uber’s MVP should test if drivers are willing to use their personal vehicles for rental, and if users are willing to use this instead of a taxi. A simple functionality that reaches both users would become their MVP.