But after all, what is an MVP — Minimum Viable Product

Introduction

This article will be a short read but contains information about what an MVP is, illustrated with some paradigmatic examples that support the article’s conclusion.

Definition of MVP — Minimum Viable Product

The term MVP — Minimum Viable Product was popularized by author Eric Ries, author of the bestseller “The Lean Startup.” His definition states that an MVP — Minimum Viable Product is a version of a new product that allows us to collect the maximum amount of validated learning about consumers with the least possible effort. In his own words: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about the customers with the least effort.”

Are companies and teams effectively defining and delivering an MVP?

Reading and understanding the definition of MVP — Minimum Viable Product, a question arises nowadays:

1 — Do we need to develop a product with a minimal number of features to have an MVP? The answer is NO.

However, most companies and teams working on these matters believe and do this repeatedly, sprint after sprint. The goal is to deliver something new in each sprint/iteration and within the proposed timeframe, and then evaluate what customers think. This worsens when there is no iteration.

The author of the book, Eric Ries, himself gives an example of how frustrating it was to develop what he thought was an MVP. That is, a product with a minimal number of features, put it online, and ask people to download it. He gives this example because the number of downloads for this supposed “MVP” was zero. This happened despite all the effort and investment made in Adwords campaigns.

If this simple example is not enough, let’s analyze real-life examples in the next point.

The Costs of Poor MVP Definition

Products that do not work, that is, do not provide an exceptional customer experience, have associated costs, reflecting in:

• Technical debt and UX debt.
• Brand reputation costs. The first impression always matters, and if it is negative, it will translate into costs.
• Support and training costs. If the MVP product is poor, it will be necessary to explain to customers how to use it.

Examples of MVPs that do not necessarily involve software development

The presented examples are from companies that offer a good customer experience, and it all started with a well-thought-out MVP. Launching an MVP is not an easy activity. You need to know very well what you want to achieve with the product you are developing; understand the needs of potential customers and from there think about what can really be your MVP and not version 1.0 or beta version. Let’s see the examples below.

Example 1 — Dropbox

The example of Dropbox is striking and paradigmatic in showing that developing features for a product is not necessary to create an MVP. In the case of Dropbox, their MVP was a video presenting what the product would be, and an email address was provided for people to sign up. The beta waiting list for the service jumped from 5,000 to 75,000 potential users almost overnight.

Example 2 — Amazon

Another interesting example is Amazon. Amazon’s MVP was based on a simple approach of developing an application with a manual back-end that users are not aware of.

Furthermore, Jeff Bezos himself would buy books from bookstores and ship them to customers by mail.

It was an initial low-cost approach, as expected in an MVP, but it worked. Within two months, Amazon was earning nearly $20,000 per week.

Example 3 — Instacart

The example of Instacart is very similar to the example of Amazon. Its founder had the brilliant idea of developing a mobile grocery delivery service. However, at the time, he didn’t have the resources to build the extensive and complex backend of the application.

The solution (MVP) was to create, just like Amazon, a manual backend. In other words, whenever someone ordered something from Instacart MVP, the founders had to buy those products and deliver them to the customers. Everything was done manually.

MVP vs Version 1.0 or Beta Version

The differences between an MVP and a version 1.0 or beta version of a product lie in their definition, specifically in the points of “validated learning about the customers” and “minimum effort possible.”

In other words, a version 1.0 or beta version of a product implies a launch. And with a launch, there logically has to be a considerable amount of effort involved. On the other hand, when we release a version 1.0 or beta version, we are already aware of what we are going to launch, and our purpose is not to gather findings and insights, or validated learning from consumers. It’s not that they can’t provide feedback, but that feedback won’t be part of the iterative cycle that an MVP undergoes. In essence, a version 1.0 of a product has likely gone through being an MVP. However, an MVP does not necessarily become a version 1.0 or beta version of the product unless the correct definition of the MVP is in question.

But How Do We Focus on Delivering an MVP in Reality?

The focus of companies and teams on delivering an MVP depends primarily on understanding what an MVP truly is, as mentioned above. And all of this is related to culture. If a company has a strong research culture and is mature enough in terms of user experience (UX), the focus on what an MVP actually is becomes easy.

On the other hand, if the culture revolves around the “agile” approach with sprints every two weeks, delivering quickly and within these inflexible deadlines without resorting to multiple iterations in each delivery cycle, then the focus is on delivering features at the expense of delivering outcomes based on the pre-defined MVP.

Conclusion

Before reaching a conclusion about what an MVP truly is in practice, it is important to understand why companies develop products or services. I would say there are two types of reasons. The first type focuses on the outcome provided, while the second type focuses on the output. Let’s examine each of these reasons:

Reasons for developing products/services with a focus on Outcome:

1. To bring about a change in the world and/or in customer behavior that makes their lives better and easier, and vice versa.

2. To surprise and/or delight customers (related to the first reason).

Reasons for developing products/services with a focus on Output:

1. To attract more customers.

2. To generate more revenue (related to the first reason).

Developing a particular product with a series of features (minimal or perceived as minimal) may not be our MVP, and consequently, we may not be delivering value to customers or our business. Above all, we cannot iterate with customers in an ideal way to truly present a product that is “valuable” to them and brings value to our business. This is because we lack sufficient iterations in terms of research.