Maximum Unviable Product

Today, Ken and I reviewed our 1.0 release plan and discussed about some practical use cases against our latest Minimum Viable Product (MVP) definition. As we developed one particular use case, we quickly realized that our MVP would not be sufficient to support it, even though it was a pretty basic one. In other words, our Minimum Viable Product was not really viable anymore. Passionate exchanges quickly followed, during which we argued back and forth about whether we should ship this unviable product or not.

At that point, something fascinating happened: while Ken had been arguing for many weeks that shipping on time was of the utmost importance, he surreptitiously changed his mind and took the position that shipping an unviable product simply was not an option, and that we should delay the release instead. I took the opposite position, arguing that we should ship our product at the promised date, no matter how unfinished or unviable. It then occurred to me that while the Minimum Viable Product strategy is highly effective, it should be preceded by some kind of Maximum Unviable Product step. Let me explain.

According to Wikipedia, “a Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. The definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.”

One challenge with this approach  no matter how iterative you make it  is in defining what subset of features really belongs to the first release you will ship to your early adopters. As its name implies, the Minimum Viable Product should have the absolute minimum set of features that will make the product viable, in the context within which it will be used by the early adopters. Unfortunately, defining this minimum set of features before the product has been put in the hands of actual users is anyone’s guess, and this guess is very likely to be wrong, which is precisely why the MVP process is designed to be iterative. As such, if the first shipping version of your MVP is truly viable, it’s very unlikely to be minimum. In other words, the likelihood that it will be both minimum and viable is close to zero.

A way out of this dilema is to acknowledge that the first shipping version won’t be viable. That your product will be full of holes and missing features, and that you will rely on the feedback you receive from early adopters to define the absolute minimum set of features that will make the product viable. Therefore, instead of following a top down process whereby you start from an ideal product and remove features until you reach this ideal Minimum Viable Product, you should follow a bottoms up process whereby you start from nothing, add features that you believe belong to some hypothetical Minimum Viable Product, then ship at a date that was set in advance. What you ship then is called the Maximum Unviable Product, or MUP.

The MUP is maximum is the sense that you’re encouraged to build as many features as you can within a self-imposed timeframe. And it’s unviable in the sense that it has less features than a hypothetical Minimum Viable Product, and it is presented as such to your early adopters. In such a context, proper expectation setting is of the utmost importance. With the MUP in hands, your early adopters will start giving you feedback that will quickly reshape your understanding of what the real MVP should be, and if you do a good job at following the now well-understood MVP methodology, your second release should be both minimal and viable.

So, to set proper expectations, our first product release will be unviable. Let it be known.

blog comments powered by Disqus