1 What is an MVP?

1.1 Introduction

Minimum Viable Product (MVP) is a concept popularized by Eric Ries in his book Lean Startup. The idea has achieved remarkable success and is now used by numerous entrepreneurs, whether they create digital or physical products. It is also part of the vocabulary of software developers, as we studied in Chapter 3.

However, at least in the context of software, the term MVP is sometimes used in ways that deviate from its original definition. Therefore, in this article, we will attempt to clarify the precise meaning of this concept.

1.2 An MVP is an Experiment

To understand the objectives of an MVP, we must recall that the concept was proposed within the context of startups, which are organizations that operate in high-risk environments and face enormous chances of failure.

In such contexts, it is important to quickly test the riskiest hypotheses of the venture. In particular, the Lean Methodology for creating startups argues that two fundamental questions should be addressed as soon as possible:

1. What is the riskiest hypothesis of my venture? That is, what hypothesis, if not true, will certainly lead to the failure of my idea?

2. What is the simplest experiment (i.e., MVP) that I can create to validate this hypothesis?

Normally, the first hypothesis to test is the company’s ability to attract customers willing to pay for its product or service. In other words, this hypothesis can be stated as follows: are there customers willing to pay for my solution X for a problem Y?

Therefore, the first MVP is usually not a software app, since the cost of implementing and deploying any piece of software—even a small one—is typically high. Instead, the first MVP is often a landing page, demo video, or a set of sketches or mockups. In other words, something that you can build in a few days. Once this is done, this initial MVP should be presented to potential customers to get an idea of the potential success of the venture.

For example, suppose your first MVP is a landing page describing the app you intend to build, its main features, and benefits. On this page, you can ask potential customers to leave their email to receive updates about the system as it gets ready. Here applies this famous quote about MVPs:

In an MVP, you decide what is minimal, but it is the customer who decides if the product is viable.

Thus, viable, in the context of MVPs, refers to a product that can attract customers rather than a product that you can implement.

In the previous example, if no one signs up for your mailing list, even after some promotional effort, you need to evaluate if it’s worthwhile to continue with the idea.

On the other hand, if this initial experiment becomes successful and attracts several potential customers, you can start building your first software-based MVP. Some recommendations at this point are as follows:

• Focus on early adopters, as it’s much harder to create a product for a broad and generic audience.

• Require some payment, as it’s important to validate whether the customers are willing to pay for the system. If they do not want to pay, of course, this is a serious threat to the survival of the business.

• Don’t automate everything yet. Since you will have few customers, several tasks—including payments, refunds, and cancellations— can be done manually. This type of MVP is called a Wizard of Oz.

• Always use libraries and third-party services. The classic recommendations are user authentication services and credit card billing services.

• Pay attention to non-functional requirements, such as performance, usability, security, and privacy. These requirements—if not handled appropriately—can lead to the failure of your business. Also, assess if your project has legal or juridical risks.

On the other hand, premature optimizations should be avoided when building MVPs. Since the MVP may fail, you should not worry about using the latest technology. Instead, try to use well-known and robust languages and frameworks. Similarly, concerns with fancy software architectures (e.g., microservices) and a large number of automated tests are not fundamental at this initial stage. The following quote sums up these recommendations:

You should love the problem and not the solution or technology you are using.

Scalability is another aspect that is not so important. If the MVP reaches hundreds or thousands of customers, you will be able to attract capital to solve scaling problems.

1.3 What is not an MVP?

Now, suppose you are hired to implement a well-known system for a certain company. By well-known, we refer to a system whose requirements are clear and delimited. It could be that you have also implemented a similar system for other companies. In other words, the important points here are:

• There is a small risk that the system will become more complex and challenging after the project begins.

• There is no financial risk, as you have a customer paying for the development.

Thus, you decide to use a method like Scrum or XP to implement this system. Imagine, for example, that you own a software agency and have some employees to work on this project.

More precisely, the project will be divided into two-week sprints. Thus, after the first sprint, you’ll have a system with some minimal functionality to show to the customer.

The question then is: is this first system an MVP?

We do not want to be dogmatic about terms, but the answer is no.

As we’ve defined, an MVP is an experiment that tests a major threat to the success of a project. In our example, there are no relevant threats or risks. As we affirmed, the requirements and scope are clear, you have the competence and expertise to implement the system, and there is a customer who will pay for its development.

Therefore, the product increments generated in the initial sprints of this project do not have the characteristics of an experiment, that is, of an MVP.

1.4 Pivots vs Restarts

Sometimes, we also use the term pivot imprecisely. To explain, after creating an MVP, you receive feedback from potential customers. Then, three situations can occur:

1. The experiment was successful, and you reached what is called Product-Market Fit. You will then begin to work on a real and scalable system.

2. The experiment was a complete failure! Therefore, it is better to give up while the investment is small.

3. With what you’ve learned from the experiment, you can now implement a new MVP with major changes and, hopefully, higher chances of success. In other words, you can perform a pivot!

Examples of pivots in the context of MVPs include:

• Attracting a different type of customer. An interesting example is Twitch, which initially targeted a broad audience but then pivoted to focus on video game streamers.

• Making significant changes in the MVP’s features. For example, Instagram started as a check-in app called Burbn, which allowed users to notify their friends of their location and share photos with them. However, this photo-sharing feature was so successful that the founders decided to focus only on it and renamed the app to Instagram.

• Switching to a new technology. For example, Android was initially designed for use on digital cameras and later changed its focus to mobile phones.

However, we should not confuse a pivot with a restart. A restart occurs when the founders abandon the company’s vision and start a new venture from scratch. In other words, a restart is a failure followed by a fresh start in a new field.

Example: Before creating Twitter, the company founders worked on a podcast distribution platform called Odeo. When the initiative proved unsuccessful, they abandoned it and began working on a social network for sharing text messages with 140 characters, which they named Twitter.

Thus, this radical shift in focus—from a podcast distribution system to a social network based on text messages—was not a pivot but a restart.

1.5 Conclusion

When talking about MVPs, the most important thing isn’t the product itself but the risk hypothesis you’re looking to validate. Thus, if someone comments on an MVP to you, don’t forget to ask about the hypothesis under test.

Exercises

1. What is the difference between an MVP and a market research?

2. The following article from the YCombinator startup incubator’s blog has an interesting title: A Minimum Viable Product Is Not a Product, It’s a Process. Why does the article argue for this point? That is, why is an MVP not a product but a process?

3. In its first ten years (1997-2007), Netflix delivered DVDs physically through the mail, having hundreds of thousands of subscribers at that time. Then, in 2007, the company moved to the streaming service as we know today. Do you classify this change as a pivot?

4. Suppose you plan to start a food delivery company in your city, intending to compete with established companies in this industry. Is an MVP recommended in this case?

5. Describe a domain in which creating an MVP is more challenging.

6. What is the difference between an MVP and a prototype?