One of the trickiest concepts from the Lean Startup Methodology is the Minimum Viable Product. In our experience training and coaching teams, we’ve seen lots of confusion. Part of the challenge is that the moniker “Minimum Viable Product” seems to convey diametrically opposite goals. “Minimum” indicating build as little as possible so you don’t waste time or effort. “Viable” indicating that you need to build enough to make the experiment realistic enough that customers will believe they are responding to an authentic product experience. Furthermore, “Product” indicates a level of completeness or refinement in what is presented to customers.
Eric Ries’ shorthand guidance for MVPs is to start off with what you believe is needed in the MVP. Then eliminate half the features. Then eliminate half the features again. His point is that we all tend to design in much more functionality than what is actually needed.
The guidance we give teams is to think of the MVP as the experiment vehicle. You’re building just enough to run a good experiment from which you will validate (or invalidate) your hypotheses. In most cases, you will not need a complete end-to-end product experience if your experiment only requires a partial experience to collect your customer-validated learning. It’s worth noting that the experiment itself may require several iterations before you feel you have designed the appropriate experience to test your hypotheses. Often it's while we are running the experiment that we become aware with problems in the experiment design or the MVP itself.
The other guidance we give teams is that for well-designed MVPs, customers should not have a clue that they are participating in an experiment. Once your customers are “on to you”, then your experiment results cannot be trusted because customers were no longer giving you “real” responses.
A simple landing page that asks customers to sign up for a “coming soon” product can be a valid MVP for measuring customer interest especially if that landing page is being displayed in the same channel you envision your product will eventually be sold.
On the other hand, surveys do not quality as MVPs because at best they ask customers hypothetical questions like “Would you be interested in a product with feature X?”. Answers to hypothetical questions cannot be trusted as predictive of real behavior. This is especially true for breakthrough products. As Henry Ford has been quoted to have said, “If I’d have asked my customers what they wanted, they would have told me ‘A faster horse.’”
There are tricky situations where a product will be distributed by viral propagation (like a social media app). In these cases, the MVP needs to have enough functionality to deliver enough of the value proposition such that customers will share the MVP with their friends. Even then, your MVP can consist of a very thin slice of your ultimate vision for your product as long as that thin slice supports your hypothesis. We can learn a lot from about the effectiveness of a minimal approach from the first versions of Facebook and eBay.
The first version of “The Facebook” that Mark Zuckerberg released at Harvard in 2004 only contained a single profile page for each user, a way to search for people you know, make friend requests, and send messages. There were no news feeds, no groups, no events, or even like buttons! With such a minimal feature set, Zuckerberg was able to build the service in just a few weeks.
The first version of “Auction Web” (which eventually became eBay) Pierre Omidyar released in 1995 was a simple page on his personal website that let sellers list items for auction. The code for that page only took Omidyar a weekend to write.
These minimal first versions are a far cry from the sophisticated services we use today. But their minimal approach allowed both Omidyar and Zuckerberg to quickly get their products into customers’ hands and provided the validation that they were onto something big.
Another important consideration when designing your MVP is making sure you are able to measure results. You can certainly ask your customers what they thought about the experience but when it comes to measuring behavior, nothing beats having analytics built into the MVP. Teams often will spend a lot of time thinking about features and not enough time thinking about measurement, which is essential for running an effective experiment.
Finally, some people have redefined the MVP acronym to mean “Minimum Valuable Product.” In this case, the MVP is referring to a more complete product that can support a pilot release with hundreds of customers. Minimum Valuable Products can be a valid experiment vehicle in the Lean Startup Methodology but we encourage teams not to wait for the weeks and months to achieve that threshold before they start experimenting. For most product ideas, we’ve found lean experiments can start on day one if your mindset for MVP is experiment vehicle.
In summary, the Minimum Viable Product balancing act requires you to:
- Minimize effort - only build what’s important
- Maximize learning - don’t forget to think through how you will measure results
- Ensure viability - your customers shouldn’t be able to tell it’s an MVP!
Jeff Zias and I are writing the book Grassroots Innovation in the Enterprise to be published early 2017. Do you have stories to share about how you’ve used MVPs in your company? We’d love to hear from you and share some of the best stories we gather in our book.
Follow @hughmolotsi
Follow @hughmolotsi