A Minimum Viable Product Is Not a Product, It’s a Process
“You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska.” —-Evan Williams It’s the same story again and again.
“You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska.” —-Evan Williams
It’s the same story again and again. First, a team comes up with an idea.
Next, they build a minimum viable product (MVP) as a proof of concept, spending a lot of time arguing about which features to include or exclude from the MVP. Finally, if the MVP works well, they plan on building the full, mature, stable product.
So what’s wrong with this picture? Why does it all go wrong for so many startups?
The problem is that these teams do not understand the point of an MVP. An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done.
An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.
When you build a product, you make many assumptions. You assume you know what users are looking for, how the design should work, what marketing strategy to use, what architecture will work most efficiently, which monetization strategy will make it sustainable, and which laws and regulations you have to comply with. No matter how good you are, some of your assumptions will be wrong. The problem is, you don’t know which ones.1
In a post-mortem of more than 100 startups, CB Insights found that the number one cause of startup failure (42% of the time) was “no market need.” Nearly half of these startups spent months or even years building a product before they found out that they were wrong in their most central assumption: that someone was interested in that product in the first place.
The only way to find that out—the only way to test your assumptions—is to put your product in front of real users as quickly as possible. And when you do, you will often find that you have to go back to the drawing board. In fact, you’ll have to go back to the drawing board not just once, but over and over again.
This is not unique to product development. When you’re writing a book or an essay, you have to produce many drafts and spend lots of time editing. And when you’re writing code, you frequently have to refactor or even rewrite the code.2 Every creative human endeavor requires an enormous amount of trial-and-error.
In a trial-and-error world, the one who can find errors the fastest wins. Some people call this philosophy “fail fast.” At TripAdvisor, we called it “Speed Wins.” Eric Ries called it Lean. Kent Beck and other programmers called it Agile. Whatever you call it, the point is to find out which of your assumptions are wrong by getting feedback on your product from real users as quickly as possible.
Whether you’re building a product, writing code, or coming up with a marketing plan, you should always be asking yourself two questions:
- What is my riskiest assumption?
- What is the smallest experiment I can do to test this assumption?
MVP-as-a-process, in action
Let’s go through an example.
You decide to build a product that allows restaurant owners to create a mobile app for their restaurants in just a few clicks. It’ll have a simple drag and drop interface, a bunch of pre-built templates, an events calendar, newsletter, check-ins, photo galleries, real-time chat, integration with review sites, social networks, and Google Maps. And most importantly, it’ll offer a way to make reservations, place take-out orders, and use coupons, from which you’ll take a small cut as a way to monetize your product. This is going to be awesome!
You find a few friends to join you as co-founders and, if you’re a typical startup team, you’ll raise some money, lock yourselves in a room for 12 months, and try to build all these features. If you’re slightly more savvy, you’ll cut a few features that aren’t essential for the first launch, so you’ll be able to launch your “MVP” in 8 months instead of 12.
And in both cases, you’re most likely going to fail.
Why? Well, consider how many assumptions you’re making that could turn out to be disastrously wrong:
Recent Comments