MVPs Are Not Products
Yesterday I wrote about the biggest issue with a sequential waterfall product development process. It is that the value risk is realized only at the very end, when countless time and resources have already been spent.
One obvious solution to that is to spend less time and fewer resources. Enter the Minimum Viable Product, or MVP.
The thrust is in the right direction: Address value risk earlier.
But the traditional (i.e. misunderstood) way of employing an MVP is to still go through all the wasteful steps of the sequential model while cutting a few corners here and there. What you end up with is something that is neither minimum nor viable, and therefore can't be called a product that's fit to release. It's not unheard of for a team to work for several months on an MVP. If it takes that long, how can you call it minimal?
Compressing the "build" phase a little won't solve the issue that value risk is only addressed at the very end. Think back to yesterday's post. How could Bart and friends have found out faster that the World Fair wasn't open? By driving faster and skipping washroom breaks? That's the traditional MVP way.
The MVP is asked to achieve two separate things that are in strong tension with each other:
To address value risk as quickly as possible
To be a small version of an actually releasable product
In other domains, this would be absurd. An architect's model (or, these days, 3D rendering) lets you quickly decide whether you like the style, but you can't actually live in it.
To resolve that tension, we need two different notions:
Marty Cagan in his book Inspired asserts that an MVP is really meant as a prototype. Nothing you would mistake for a real product, built solely to address value risk. According to him, the best product teams build more than ten such prototypes each week.
Jason Cohen asserts that what you put in front of users as an actual product should be simple, loveable, and complete. (or "SLC", i.e., slick)
Jason says we should use SLCs instead of MVPs, but I say that, with Marty's concept of MVP as prototype, those two can coexist. The MVP is the truly cheap not-a-product-ever version to validate the value hypothesis, and an SLC is the thing you build for an actual first release.
If that all makes perfect sense, go and apply it to your product strategy. But if you're facing a tough product situation where you don't know what to build, what not to build, and how else to validate your ideas, I'm here. Just reach out and start a conversation.
