Stop Saying MVP
Photo by Thought Catalog on Unsplash
How you think is how you build, and one of the worst mental viruses to infect product teams is the idea of an MVP, Minimum Viable Product. If you dig in, the theory is sound, but in practice, the original meaning has been twisted in a wayward game of telephone. Much like data can be tortured to confess anything, so too can concepts like MVP be manipulated to justify any desired behavior — and so it has.
What do you hear when someone says MVP? Do you have a definition? Most consider it to be “the smallest product a customer would find valuable.” Given the acronym, it’s perfectly reasonable. In fact, it’s what I hear most expressed by product folks. But here’s the actual definition from it’s most vocal proponent, Eric Ries:
“That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Eric’s intent is not to define a product, but to provide a vehicle to get to a product. It’s a beaker in the lab, not a packaged prescription medication. Sadly, in practice, the term is wielded as a justification to deliver anemic, shoddy products under the cover of an unassailable product management principle.
It doesn’t help, that Reid Hoffman, successful VC, and Entrepreneur, manufacturers more ammunition for the MVP idea when he says:
“If you’re not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman [1]
Again, I can’t argue much with his theory — it’s useful. The natural tendency of humans is to keep creative works close to the vest too long. Reid’s notion is efficient, forcing feedback as soon as possible, reducing the errant paths your team could take on their journey. Time and resources aren’t limitless after all.
But again, it’s not the academic concept that’s in error, it’s the practical application that has become distorted. Too often I’ve found teams use MVP to justify low quality. Conversations orbit around cutting features to make a certain date — missing the original notion of learning so core to Reid and Eric’s approach.
In my view, we should be aiming for a narrow, but magical experience. Small enough that you can get it done with sufficient quality, and magical so early users will love it and share it. It may take some time and iteration to get there, but I’ve seen too many teams ignore this part of the equation, absolving themselves of any quality bar, delaying the hard, detailed work through a hollow promise of future iteration. Later is never.
“Build half a product, not a half-ass product.” — Getting Real
I only ask this — don’t shirk your responsibility to create something you’re proud to share. Consider the end to end experience and avoid inflicting something half-baked on your users under the mantra of MVP and the mirage of fixing it later. And please, stop saying MVP.
Like articles on building product? Subscribe to receive by email.
—
Footnotes:
Reid Hoffman has also noticed the confusion this quote has caused. He wrote a wonderful piece that clarifies his thinking. It’s fantastic and I encourage you to read it.