MVP. Minimum Viable Product.
Terminology from the startup world is finding its way into the language of Business. Managers are latching onto the key words such as pivot, disrupt and the idea of the minimum viable product.
Unfortunately, few managers fully understand what each means to the startup world. The idea of the minimum viable product is widely misunderstood. It’s pretty easy to get most of its meaning, but unfortunately the point gets missed.
About the Minimum Viable Product, Eric Ries in his book ‘The Lean Startup‘, says:
“instead of spending years perfecting our technology, we build a minimum viable product, an early product that is terrible, full of bugs and crash-your-computer-yes-really stability problems. Then we ship it to customers before it is ready”
It is this type of definition that managers read about in HBR articles and similar media. So the modern-day manager thinks “Eric’s saying what I’ve suspected all along – my developers are taking too long to ship, we need to deliver less – no more than the absolute minimum viable product”.
Which is OK, but the manager that ends their learning there, is missing a huge point of MVP.
Why does Eric Ries endorse the shipping buggy, incomplete software?
You make MVP’s to learn more about your customer and the problems they have. You make MVP’s to test your hypothesis, your convictions, assumptions and value propositions. You make MVP’s to learn.
The Minimum Viable Product should be thought of as ‘What is the minimum thing we can build to test our assumptions and learn more”.
It’s not about releasing a half done product, just because it’s all the rage at the moment.
It’s not necessarily even about a product.
When you think Minimum Viable Product – think experiment
If you’re not approaching it from this perspective, you’re missing most of the point. So the next time someone endorses the Minimum Viable Product approach, ask yourself, what are we learning?
Thoughts, comments? Hit me up below?
Andy, this article really resonated with me — especially the reminder that when we think Minimum Viable Product we should think “experiment.” Sometimes it’s easy to forget that we should be measuring success by how much validated learning we get — not how much code we write. Thanks!
Hi Brian thanks for the comment. You’ve hit the nail on the head on another area of misunderstanding: Learning vs Validated Learning. Learning can’t just be ‘yeah we learned that didn’t work!’ – it needs to be validated – backed up with data. This then has an implication for the MVP – maybe it needs built-in analytics, hooks to capture user behaviour and engineered for things like easy A-B testing…