First, the MFP...
Early in my software career I was introduced to the concept of “maximum flexible product.” The concept was relatively simple and straightforward - value is greatest when you give the customer as many options as possible for accomplishing any specific task.
After all, we don’t want to put the customer into a “straight jacket” where they can only do things one way. And, we also knew that every customer does things a bit differently, so in order to sell to the majority of them, we’d need to accommodate their many differences. We also aren’t completely sure which single approach will be the most common, so to hedge our bets, we need to include as many different variations as possible. Finally, and this tends to be an architectural, platform issue - it can be notoriously difficult to go back and make changes, so better to get it all in up front.
I believe this orientation comes from several customer value deficiencies. First, it comes from a lack of focus on a specific intended customer. The fuzzy focus we have on our target customer profile leads us to trying to “please all the people all the time”. Out of this uncertainty, to minimize perceived risk we emphasize product features, functionality and flexibility. Unfortunately with all this comes the unintended consequences of cost, complexity and confusion for both us and the customer. Instead of offering higher value to specific customers, we end up offer lower value to all customers. And it’s a slippery slope, because as we pursue this approach we, by necessity, have to continually add more and more flexibility, which creates more barriers to value.
There are certainly times when flexibility is required to address the customer’s needs, but it needs to be used carefully and only where it is absolutely necessary and when clearly justified by the customer’s requirements.
The MVP, by contrast seeks to build value by only adding the the minimum amount of functionality and flexibility to address the highest priority needs of a well defined customer profile. To execute an MVP well also requires an intense amount of customer understanding. Out of this customer focus and deep understanding comes an ability to hone in on the minimum but highest value needs to address, along with an appreciation of how best to address them simply and cleanly. There isn’t a need to “throw in the kitchen sink” because we know when the customer isn’t looking for a kitchen!
This approach takes an incredible amount of courage and discipline. It takes discipline to avoid drifting from our original intended customer focus. And it takes courage to say “no” to the inevitable requests for “one last” capability feature.
I mentioned that early in my software career I ran into the MFP. Well, I also ran into a great MVP as well. One of our senior product architects, in developing a new, PC-based estimating program, could have easily taken the approach of re-creating our very complex (and flexible) mini-computer estimating software. Instead, he chose to build an MVP although we didn’t call it that in those days. He took his incredible body of customer knowledge gained from developing the previous software and used it to hone the initial offering to what appeared to many of us as an overly simplistic solution.
It clearly wasn’t because he spent more time figuring out what to leave out than what to include in the initial product. Precision Estimating went on to become the industry leading construction estimating software used by thousands of contractors to this day.
I’ll leave you with this great quote from Antoine Saint-Exupery I ran across the other day that I think speaks so eloquently to the MVP approach: “Perfection is achieved, not when there is nothing more to add, but when there is nothing less to take away.”