From Jeremy Bishop
Here in the building-software-and-tech-company corner of the internet, there are a lot of people with strong opinions (myself included).
We’ll happily debate the minutiae of story point estimation scales. We’ll wax poetic about the benefits of analytics and data-driven decisions. We’ll fight tooth and nail about the importance of reducing user pain.
But in the shadows of our well-reasoned debates, we pathologically ignore a massive source of pain and confusion surrounding us.
For many of our friends and colleagues, working with Agile teams is awful.
It’s a huge problem with no single silver bullet. But a large part of the pain can be traced back to a simple misunderstanding. At its root is a simple truth.
There are two types of MVPs. And for the life of us, we can’t keep them straight.
There are Minimum Viable Products.
And there are Minimum Valuable Products.
A Minimum Viable Product is a dirt simple but useful-for-your-users product. It has a few UI and usability blemishes. The feature set is slim. But at the end of the day, your users can grab hold, use it, and make their lives better.
Minimum Viable Products are viable in the marketplace.
A Minimum Valuable Product is a tool. It’s the tiniest possible thing you can make to help you learn. It might be a piece of working software released into the world. It might be a paper prototype shown to a few friends. It might be a napkin sketch doodle that only your rubber duck sees. If it helps you learn, it’s a Minimum Valuable Product.
Minimum Valuable Products are valuable for the team.
Minimum Viable Products help users.
Minimum Valuable Products help the team.
Once you decide which you’re building the world gets much simpler.
And for goodness’ sake, digital ink’s cheap. Do yourself a favor and ditch the acronym.