Minimum Viable Product by Henrik Kniberg
In software development, the Minimum Viable Product (MVP) is the quickest time to release for something useful. All these words are loaded: “quickest,” “release,” and “useful.” Noting that development is a change, the definition [of a one-time] MVP depends on your planned current vs. future business state. Yes, I emphasize that your MVP vision depends on many things and is a temporary target. What is an MVP today is probably not an MVP next month because, there will be a different situation then.
Minimum Viable Product (MVP)
MVP is great strategically because it is just enough stuff to satisfy early adopters, get some sales, demonstrate future benefit, gain critical feedback, etc. Also, tactically, there is a business vision that drives the funding plan for the MVP. But then, operationally, the phrase MVP becomes the banner for garbage execution. Really, how could this critical project be so poorly funded/planned!
This is because execution of a development project includes gobs of little decisions on the ground. But, we want smart folks to make decisions during execution. So, where’s the problem?
Maximum Value Product (MVP)
All those little decisions are either a thousands cuts to failure or a thousand steps to success. Staying true to the MVP takes a top-notch Product Owner (PO). The more minimum the MVP, the more work for the PO and the more experienced the PO must be. Among other things, optimized value is the charge of the PO. The tighter the target, the more gymnastics on the ground. No magic here, this is a the 80/20 rule.
If we want a more minimum MVP, then we require greater precision in product backlog decomposition, acceptance criteria, product vision, and backlog ordering. And, this is a lot of work! If we want a more minimum MVP, then we must expect the need for deeper communication. Again, more work.
The most valuable product is more than the minimum viable product
A better original phrase for MVP is “most valuable product.” From a change management perspective, this is also a much better message. The development folks should hear that they are creating optimum business value, not a minimum product.
In fact, the most valuable product is more than the minimum viable product!
How is that possible?
I always worry when people throw around optimization terms like maximum and minimum. They are nearly meaningless without precisely stating what is being optimized. I don’t think that anybody really wants the minimum viable product.
In this case, its simple, set your agile team on a cadence/trajectory that will get any viable product with the least effort. Oh and, don’t forget to communicate the desired change to the smart people.
