I am declaring death to the Minimum Viable Product!
And I don’t do that lightly considering our advisory board consists of the father of the Lean Startup, the author of Lean UX, the author of UX for Lean Startups, Marty Cagan, and several other awesome Lean thought leaders..
What is an MVP
Sounds simple…so what’s the issue
The MVP is the most misunderstood term I have ever experienced in business.
So many people have read/heard this definition and concluded that the MVP is really just a [crappy] version of your product that is an embarrassment to show to customers. I have heard so many times, “let’s just remove these features and call it the MVP version.” And so you get blog posts like this one from a company that I greatly respect, but really, really misses the point of the MVP.
Or tweets like this one..which..ugh, I don’t even know where to start.
Again, the point of the MVP is to LEARN about customer demand and usability before over-committing resources. To make sure that you are only building what customers want. An MVP is NOT a fully usable product that will delight customers. It is simply a learning vehicle. A focus on Learning before scaling is one of the core Principles of Lean UX. In Jeff Gothelf’s words:
Principle: Learning over Growth. It is difficult to figure out the right thing to build and scale a business around that thing at the same time. They are contradictory activities. Lean UX favors a focus on learning first and scaling second.
Why is there a disconnect?
I think the root of the disconnect between theory and practice is the use of the word Product in the term MVP.
Lean practitioners have a very different definition of the word Product than most Product Managers that I know. When Eric Ries says, “that version of the product..to collect the maximum..validated learning” he is much more focused is on learning, than on product. The point of an MVP is to validate or invalidate a specific hypothesis. That is why Lean uses the concept of a concierge MVP and heavily relies on user testing of prototypes. 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.” And so, they build that version, release it and guess what..no one likes it. Well…no duh!
What’s the MVE you ask? Well, it is a prototype or a concierge MVP or anything else that you can use to validate or invalidate a product hypothesis.
See what I did there? Genius, right? I basically hijacked the definition of the MVP but am using a word that [hopefully] won’t be misinterpreted. My hope is that by replacing the word Product with the word Experiment, that the expectations are now better aligned with the results (ie learning) that you are likely to get.
No one expects an experiment to grow or scale. So no one should be disappointed when it doesn’t.
Again Jeff’s book Lean UX gives us great guidance here:
Lean UX makes heavy use of the notion of MVP. MVPs help test our assumptions – will this tactic achieve the desired outcome? – while minimizing the work we put into unproven ideas..This concept is an important part of how Lean UX minimizes waste.
Your prioritized list of hypotheses has given you several paths to explore. To do this exploration, you are going to want to create the smallest thing you can to determine the validity of each of these hypothesis statements. That is your MVP. You will use your MVP to run experiments. The outcome of the experiments will tell you whether your hypothesis was correct and thus whether the direction you are exploring should be pursued, refined or abandoned.
Dude, will the MVE go Viral?
I doubt it. First, MVE doesn’t sound as sexy as the MVP, an acronym that sounds like an award for a pro athlete. Second, I am not going to market it beyond this post.
But popularizing the term MVE wasn’t the point of this post anyway…happy experimenting!