PM 101: Minimum Viable Product (MVP)
1 March 2020 ‧ 7 min read
In the “PM 101” series I am sharing some PM basics that I wish I had known when I first started as a product manager. In this article, I talk about what the overused term Minimum Viable Product (MVP) means.
The term Minimum Viable Product (MVP) is used in product teams everywhere, from startups to established organizations, and frequently debated as well. Medium is full of articles arguing against the concept or proposing adjustments such as Minimum Lovable Product or Minimum Viable Vision. So if this term is so controversial, why do we keep using it?
The big challenge and the root cause for the controversy is that there are several competing definitions for what an MVP is. Worse, people will often not be explicit about what definition they are using (or be aware of the different definitions), which can lead to miscommunication.
The original definition of “Minimum Viable Product”
The term “Minimum Viable Product” was first introduced by Frank Robinson in 2001, and the formal definition is as follows (emphasis mine):
The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk.
In other words, a minimum viable product needs to be able to generate a return, but be scoped in a way that any increase in scope would increase cost and/or risk more than it would add value. It is important to understand this origin of the definition, but it isn't actually used much today. For one thing, investment, return, and risk can only be coarsely estimated before building the product, so maximizing this ratio isn't something that can be done with precision. It is worth noting, however, that this definition conforms to the intuitive definition of a “product” as something that can be bought and sold.
Enter “Lean Startup”
The reason the term MVP is so ubiquitous today, though, isn't its original definition, but the fact that Eric Ries used the term in his seminal book “The Lean Startup”, which is the foundation for a lot of the ways of working of Silicon Valley startups. At the heart of his concept is what he calls the Build-Measure-Learn loop: create something small, put it in front of customers and “measure” their reaction, then learn from it for the next iteration. His definition of MVP is as follows:
The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.
He also provides a practical recipe for identifying and what to aim to “learn” in the first turn of the loop:
To apply the scientific method to a startup, we need to identify which hypotheses to test. I call the riskiest elements of a startup’s plan, the parts on which everything depends, leap-of-faith assumptions. The two most important assumptions are the value hypothesis and the growth hypothesis. (…) Once clear on these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP).
This recipe makes it a little clearer how an MVP should be defined: identify the riskiest assumptions, then create something (a “version of the product”) to test the assumption by putting it in front of customers. That “version of the product” is an MVP and should be as small as possible (low effort / cost) to allow for the assumption to be tested quickly.
What isn't clear from this definition but becomes clear later in the book is that the “version of the product” doesn't have to be a (buyable / sellable) product at all. Ries recounts the story of Dropbox and how its MVP was a video showing how the seamless, magic-like syncing functionality might look like in future. The assumption that Dropbox was trying to test was: “in the crowded market for file synchronization, there is interest in a new solution that is more seamless.”
The Dropbox example also dispels the myth that an MVP is only about functionality and the user experience (UX) can be neglected. In the Dropbox case, there were plenty of other solutions on the market already that had the functionality of synchronizing files across computers. Dropbox's key improvement was precisely on the UX front, making the synchronization experience seamless and magical: there's a folder on your computer, you drop a file in, and it automatically appears in the Dropbox folder on all your other computers. Oh, and you can access it from the web, too. (Recall, those were the days where the easiest way of being able to access a file on a trip, for example, was “emailing it to yourself”).
So... Is an MVP a product or not?
At the heart of the confusion about the term MVP, then, is the question whether or not it is an actual product. Some argue, like product management guru Marty Cagan does in his book “Inspired”, that an MVP should never be a product:
An MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support). The MVP should be a prototype, not a product.
Others follow more the intuitive understanding of the term, which is also in line with the original definition, and expect an MVP to be something that can be released, bought, and sold, like Jeff Patton's definition in “User Story Mapping”:
The minimum viable product is the smallest product release that successfully achieves its desired outcomes.
Neither of these definitions is per se right or wrong, of course. The important thing is to agree on a common definition. When someone talks about an MVP, be explicit in clarifying whether they are talking about an actual product or a prototype.
What does “minimum” mean?
Even after you have clarified whether you are talking about a prototype or a product, the question of what “minimum” means remains unanswered. Here, there are two important points to understand that lead to a lot of the controversy.
Firstly, there is the question of user experience. As mentioned above in the Dropbox example, a good user experience can absolutely be part of the scope of an MVP. It is all about what assumption is currently being validated. If a product manager feels that the value risk (i.e., the risk whether the product is valuable to the user) is currently too high to warrant investing in good user experience, then the solution should often be to test with a prototype instead of shipping a product with usability challenges. Now, this is of course still a difficult debate, especially when it comes to aspects like user delight that aren't necessarily about usability per se, but the point stands: if something is shipped, even as an MVP, then it should meet the quality bar.
Secondly, there is the issue of the “abandoned MVP”. This is based on the flawed understanding that an MVP is the “good enough” experience, which often leads to the following scenario: a PM wants to move fast and learn quickly, and pushes engineers and designers to cut corners: “we're building an MVP here, let's be scrappy and learn fast”. They ship a version that designers and engineers are unhappy with in terms of quality, and then it just stays in the product forever and the team moves on to a different feature.
Let's be clear: this is absolutely against the spirit of an MVP. An MVP only makes sense if it is seen as part of a series of tests, validating assumption after assumption. If you ship an MVP, and you learn that it works (the underlying assumption was validated), but you don't take that learning into the next iteration of the Build-Measure-Learn loop, you aren't following the idea of Lean Startup at all. This also means that the notion of the MVP is misguided to begin with: an MVP tests the current riskiest assumption. Once that assumption has been validated, another assumption becomes the riskiest one, requiring another MVP. The right approach is to build a series of MVPs, each learning from the previous and testing the next risky assumption. Once all critical assumptions have been validated, double down on the product and build it out.
Prototypes as MVPs
Just a few words, then, about prototypes as MVPs. As mentioned above, according to the Lean Startup definition, the key purpose of an MVP is validating the riskiest (“leap-of-faith”) assumption. According to Marty Cagan, there are four types of risks in product development: (customer) value, usability, (technical) feasibility, and (business) viability. In The Lean Startup, Eric Ries specifically calls out value and growth (which is a subset of business viability) as being particularly risky, but occasionally, the biggest risk might be of technical or usability nature.
The prototype needs to be fit for purpose for the assumption that is being tested. If the assumption is about usability (“will people be willing and able to order medication on the phone?”), it needs to be close to the actual experience. If it is about technical feasibility, the prototype will likely be a technical proof of concept. Value and viability prototypes are more likely to look and feel like an actual product, but there are some specific cases that I would like to describe.
A very simple prototype to measure demand is a landing page or “painted door” test. In this case, a landing page or in-app entry point to a non-existent product or feature is created, and demand for the value proposition is measured through clicks / visits or through a form to sign up for a wait list (regardless of how far along the promised product actually is). This provides a signal for customer interest, but it's generally of low fidelity: clicking a button or even signing up to a wait list is very low friction and doesn't “cost” the potential customer anything. A higher fidelity signal would be getting an actual commitment, like a binding pre-order with the user's credit card number.
A prototype to understand customer value is the concierge experience. In the concierge experience, the product's value proposition is fulfilled through a person. For example, instead of an app that creates a personalized meal plan, that meal plan might be created by a person and sent via email.
A wizard of Oz prototype is a more advanced variant. In this case, the frontend of the product is built, but the backend is replaced by humans. This is often done in AI-related startups. In the above meal planning example, you would then create the app itself, but the creation of the meal plan (the backend) would be done by hand.
Concierge and wizard of Oz prototypes do not scale, obviously, and that is not the point. If scalability is the riskiest assumption, then they are not the right way to test that assumption. If value or viability are, they might be. You can already charge customers for these prototypes—after all, they are getting the promised value out of them. Unit economics will likely be terrible (it's unlikely you'd charge enough to pay for the manual labor), but you can validate the assumption that customers would be willing to pay (and once the manual labor is automated away, start making money).
Putting it all together
The term Minimum Viable Product can be confusing, because it's used in multiple different ways—and not all of them necessarily mean an actual product. For new product managers, it is advisable to clarify what is meant when the term MVP is being used. In addition, it is always a good idea to list the critical assumptions behind a product or feature, identify which ones are very risky, and then think about the fastest way to validate them. If a product release is not the fastest way, then use a prototype instead.
Also, make sure to not stop at a single MVP release. Learn from it and iterate. Add in the stuff considered “optional”. Fix quality issues. In the medium and long term, your product will be better off for it.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.