Minimum Viable Products: I Do Not Think They Mean What You Think They Mean

In the 1987 movie The Princess Bride, Vizzini (played by Wallace Shawn) is struggling to stay several steps ahead of the pursuing Dread Pirate Roberts (Cary Elwes). Vizzini repeatedly states it is “inconceivable” that the Dread Pirate has not been foiled desipite his attempts. But he tends to overuse the word, inspiring Inigo Montoya (Mandy Patinkin) to deliver this memorable line: “You keep using that word. I do not think it means what you think it means.”

This is the same response I think of in most cases when I hear product managers use the phrase minimum viable product (MVP).  Product managers keep using this acronym, but I do not think it means what they think it means.

MVP has somehow morphed from its original definition and intent to become a catch-all label that can be slapped onto any product to justify pretty much anything. Product has a lot of bugs? Call it an MVP! Product is missing some key features? It’s okay, it’s an MVP!

But it’s NOT okay to just call a product an MVP for no reason (or release a buggy or lacking product to the market). First, we need to clarify what a minimum viable product really is.

Although there are many similar definitions in use, SiriusDecisions defines an MVP as any output that requires the least amount of effort to build but delivers the best ability to learn about customers’ needs.

• Least amount of effort to build. The “minimum” in MVP refers to the desired lean approach to expend the least amount of time and effort. This does not mean the work should be haphazard or shoddy. Instead, given a range of options, use the one that requires the least amount of resources and can be done the fastest to minimize the initial investment and time required.
• Best ability to learn about customers’ needs. An MVP is not itself a goal. It’s an approach to gain a deeper understanding of customer needs before applying additional effort. This learning should be about the needs themselves as well as the proposed way of addressing those needs. By this definition, an MVP should be preceded by a hypothesis or question to be answered, which should drive its creation.

Getting this definition right is important. If we don’t understand the purpose and intent of an MVP, we can’t use the approach to its fullest potential, and may do more damage by putting bad products in the market.

With this definition in mind, let’s look at some “Vizzini” ways (bad MVP) that companies define their approach to MVPs and contrast them with the more appropriate “Inigo Montoya” (better MVP) perspective:

• Bad MVP: “We think we know what customers want, but we can’t get it all out in the first version.”
• Better MVP: “We have some ideas about what customers might want, but let’s test those ideas before we spend a lot of time building capabilities they don’t value.”

• Bad MVP: “We’ve figured out the absolute bare minimum that we can get away with putting into the product and still charge for it.”
• Better MVP: “We believe that we have created something of enough value that it can both drive revenue and inform what we do next.”

• Bad MVP: “We need a label to describe the fact that the product is buggy.”
• Better MVP: “The way we built this isn’t the best long-term scalable approach, but we believe it will provide enough value and appear to buyers and users as fully formed enough to enable us to learn more.”

• Bad MVP: “We don’t have time/money to do customer research, so we’ll just release an MVP and see what feedback we get.”
• Better MVP: “We’ve done enough research to form a solid hypothesis but we want to test it in the real world.”

If you’re interested in learning more about the best ways to define and structure MVPs, attend my session at SiriusDecisions’ 2019 Summit focused specifically on best practices for minimum viable products. Earlier, I mentioned that organizations should built their MVPs on a hypothesis. In my Summit session, I’ll share a framework we’ve developed for constructing an MVP experiment, including defining the hypothesis to test. Approaching MVPs in this way can ensure that product managers are using the term correctly – and leveraging the MVP approach to its fullest potential to quickly and cheaply learn about customer needs and deliver better products to market faster.

I hope you’ll join me in Austin on May 5-9 for Summit to learn how you can build great MVPs to deliver great results to your organization.