The Trouble with MVP (A Work-Related Post)

Too many of us have drunk the Kool-Aid. It used to be that "MVP" was "Most Valuable Person" or "Most Valuable Player" or "Most Valuable Product." In Agile, it becomes "Minimum Viable Product" - what's the least amount of effort/money/time that we need to put towards this and have something to show for it?

In being nimble and responsive and to avoid wasting effort, this is a great mindset. It's not laziness-as-an-artform, it's about executing quickly to get a proof-of-concept into someone's hands so that they can quickly affirm that you're on the right track or so that we can quickly discover that the business requirements were wrong.

from Amazon

But there must still be a group in leadership that concerns itself with "Most Valuable Product" - if the "Minimum Viable Product" mentality creeps too far up the org. chart you end up with "perpetual alpha" - a product that works as a proof of concept but then fails under load testing, fails security scans and fails to delight customers. Used to be that a really good prototype was also quite ugly. With technology kits like Bootstrap, your proof of concept can look extremely polished and be mistaken for the final product.

But as leadership, you must concern yourself with the whole, quality product. You may still want to iterate quickly, and if you've got a forgiving audience who enjoys living on the edge or is excited by continually discovering new features you've just added, but if you have paying customers, you may take the MVPs in bundles to release to your customers.

And it's at those releases of new features that become a great time to celebrate your other MVPs - the "Most Valuable Player" who deliver quality Minimum Viable Products that don't require a lot of refactoring to move from proof-of-concept to world-ready scalable secure releases.