Top 5 Mistakes Made With Defining a Minimal Viable Product “MVP”

Recently I read a great article by Nis Frome on Making the case for Minimal Viable Experiments and it reminded me of all the mistakes we made with our “MVP”s over the years.

In Nis article, he wrote: When “The Lean Startup” author, Eric Ries, realized the value of validated learning, the easiest way for him to get in front of prospective customers was by building an initial version of his product, launching it, and evaluating the feedback. After all, his startup consisted primarily of engineers so building products was what they were good at, what they did quickly, and perhaps one of the only things they could do efficiently. Hence the minimum viable product.

But the primary goal of utilizing MVPs is not and never was to actually build something. Our CEO, Thor Ernstsson, wrote definitively that “The goal of an MVP is not to launch the first version of a product. It’s simply to start gathering feedback and observing users actually interacting with something. This distinction is critical.”

As I read this article and the e-book, I realized the mistakes we had made:

1) We let the term MVP mean something different to everyone – We passed around Eric’s book “The Lean Startup” as if it were a bible, though everyone seemed to interpret the concept of the MVP differently. The most common misuse was to say the V1 of the product is a MVP, so the term became synonymous with a version one product, vs an experiment. Better said is was "viable" and not necessarily "valuable".

To quote Cohn:

An MVP can be coded, but the key is creating a product version focused on hypothesis validation, not growth.

But for some reason, most people hear the the word “product” and assume that it means the first version of a product that is coded and “launched”…

2)  We thought of “minimum” the wrong way. As the picture illustrates, we were thinking “how to build a car” vs. how to get from point A to point B.  Looking at the problem or need from a perspective of what is the minimum way to solve this vs. envisioning the feature/product and planning out the road-map or addition of capabilities over time.

3) Viable to us meant, would a user pay for the product, such as; if we don’t put this feature in, is it a viable (or competitive) product.  As Nis mentions, viability is all about user sacrifice. One of the most common mistakes made by lean product managers is to simply ask users ‘do you want this?’ Sure, anyone will take anything for free. But that tells you very little, besides that your product doesn’t physically repel people.

4) We never did true experiments. We would show customers a preview of the product, but we never really did any sort of A-B tests or other simple experiments. It’s critical to think of it as experiments rather than products because the objective is to find the quickest route to validated learning.  There are many examples of this in the industry and Nis called out the DropBox experiment of gathering email via email from one of their original videos.

5) We focused on the delivery date and not the validated learnings. In a large organization, the pressure to ship and ship sooner than later is high.  Unlike startups, there are often fixed dates, immediate revenue expectations, and a long tail of cross-functional release activities that you need to plan for that shrink your time to deliver.  Given all of that, you start to rely more on your opinion and your teams consensus to make decisions than you do on customer’s feedback, especially in the form of experimentation.

In summary, use the term MVP cautiously and make sure you are focusing on value and validation. Get alignment on the meaning of MVP and educate not only the team members but leadership as well