Learning to Love the MVP

A minimum viable spouse – plenty of room for improvement, but cheap and widely available

At the “surprise ending” of the Dog Food Diet series we ran headlong into a situation where the product became invaluable way before we’d finished the backlog.  Without aiming at it, or even thinking about it, we’d run into the Minimum Viable Product.

When I train Scrum, I run into lots of excellent people who hate the concept of MVP.  The idea of doing a “minimum” anything is repulsive to them.  They tend to be the craftsmen among us, and their philosophy of work is that whatever they build, it should be the best.  They’re the kind of people I want building my products for me.  The “minimum” in minimum viable product is like nails on a chalkboard to them.

V = R/E

It’s useful in those cases to think of MVP differently – as Maximally Valuable Product.  Value has a numerator and a denominator – revenue divided by effort – V=R/E.  If you’re prioritizing well, there comes a time in the product’s lifecycle where the revenue you get from the following incremental releases starts to decline.  If effort remains constant the “value” of that release declines relative to previous releases.

Graph of relative value delivered by sprint on the Dog Food Diet project

In The Dog Food Diet’s Sprint 7, Scrum product ownership pushed us off the edge of this cliff really abruptly.  The team, even the Product Owner, didn’t see it coming.  But in Sprint 7 the customer said, in pretty clear terms, “We’ve got this.  We’re good.  Stop helping.”.

The market told us what the minimum viable product was. By delivering just that and  no more as quickly as we could, we built the maximally valuable product for the business.