In The Lean Startup, Eric Ries defines a “minimum viable product”:
A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way way to get through the Build-Feature-Learn feedback loop with the minimum amount of effort.
The minimum viable product has gotten a bad reputation lately. I think it all started with this image from a presentation by Spook Studio:
The definition of “viable”
Is the cake on the left really a “viable product?” It is able to be consumed, making it a viable form of food. But is a baker’s goal really to create a viable form of food? Of course not. The goal is something more. Back to Ries’ definition, is the cake on the left enough to “start the process of learning” about people who eat cake? No. All you’re going to learn is they don’t like shitty cakes.
When building software, what does “viable” mean? The cake image implies that “viable” simply means the software will run. If you look at Ries’ definition, a minimum viable product is something much different.
Young startups have very limited resources. Spending too many development cycles going down the wrong path can destroy them. This is what’s great about a minimum viable product. Every startup begins with an idea—one worth forming a company around. That is the idea that you validate with an MVP.
This is how Zappos started:
In reality, Zappos was originally called shoesite.com. A guy named Nick Swinmurn had this “crazy” idea that shoes could be sold online, so he patched together a very basic website. But he needed shoes to sell, and he had no money.
Nick happened to live near a small shoe store. One day he went to the store and took photos of a bunch of shoes to post on his website. Whenever someone bought a pair of shoes, Nick would run over to the store, buy the shoes, and ship them to the person.
Through this minimalist MVP, Swinmurn was able to find out that there was indeed a market for buying shoes online. With his idea validated, he could now go ahead and build his real (as in, greater than minimum) “viable” product. He didn’t build the boring cake on the left. He bootstrapped the cupcake, with a focus on the frosting (the sweet idea that would set Zappos apart).
Minimum viable functionality
HubSpot may feel like a startup on the inside, but it’s a company with more than 700 employees and over 11,500 customers in 70 countries. We have the resources to validate our ideas that bootstrapped startups do not. This is an advantage, for sure. On the flipside, it’s not acceptable for us to ship a minimum viable product—even if it’s something brand new. People are expecting robust, delightful software from us.
I’ve been trying to think of “minimum viable” in two ways. One is minimum viable product but the other is minimum viable functionality. What I’ve been calling minimum viable functionality is essentially what Ries called minimum viable product—it’s the early prototype that’s just good enough to generate insight.
I break it down like this:
|Minimum viable functionality||Minimum viable product|
|Tasks can be completed||Task flows are optimized|
|Focus is on features||Focus is on experience|
|What’s there works||What’s there is awesome|
|Ready to ship and test||Ready to ungate to all|
The key for us is that last row. At HubSpot, we use feature gating to test our work during the development process. It’s been life-changing for me as a designer and developer. We are able to build features on the site, but only activate them for certain users. At first, we’ll “ungate” members of our small product team team. But once we’ve reached minimum viable functionality, we begin ungating beta users.
Because these are beta users, they are more tolerant of software at this stage in development. In fact, they enjoy helping us work through difficult product decisions. Through multiple rounds of iteration with our beta users, we finally reach our minimum viable product—a product that not only functions well, but fulfills our goals of delighting our users. That’s the product we ungate to the world.
Utilizing the minimum viable product approach does not mean shipping poorly designed or incomplete software. “Minimum” and “viable” mean wildly different things to companies at different stages. As with just about everything else, it comes down to simply using the best tool for the job.