The term MVP has become quite popular in recent years. As a general concept, it embodies the practice of “Release Early and Often” which is a key component of effective iterative development.
But is the term being used correctly, based on the definitions of each of the words?
We will start with “Product” – defined as “a thing produced”. For a software application, presuming a compiled language – this is most commonly an executable. Every time a build is done a new executable is produced, which will likely be different than the previous. This means that a new executable is a new product!
Next up is “Minimal” – defined as “the least possible”, per some criteria of measurement. This has an interesting interaction with the term product. Since each build represents a unique product, and sequential build typically have additions (more commits) than the previous, there will be only a small window of time where minimal can apply. Without extreme care, it is likely that one or more commits will occur that is not necessary to satisfy the minima before all the necessary commits occur which means that the minimal product is never produced.
The final part of the acronym is “Viable” and this is where most problems occur. The key definition here is “practicable; workable”. Though there are many other definitions that contain phrases such as “having the ability to grow, expand, develop, etc.”, these are all problematic as any type of development will result in a new executable, and thus a new product!
The concept of a viable product line, or sequence of products/builds is compatible with the concepts of growth, expansion and development. Such usage makes good sense; but is not the term that is being used which is referring to a single production.
So, what would it take for Minimal Viable Product to be an accurate term? A simple scenario would be a company that was created with a single product line. For a given product/build/release to be viable, it would need to provide sufficient value to the company to ensure that the company itself was viable. This is certainly going to be a more mature product than what is referred to as an MVP. In fact, the company waiting to release a product until it has met this strict definition could easily result in the failure of the company.
Perspective is also important. What is viable from a vendor point of view may not be viable from a client point of view. Consider Agile Principle #10 – “Simplicity–the art of maximizing the amount of work not done–is essential”. Minimizing the total amount of work does by both the vendors and the sum of both actual and potential clients is rarely going to happen if the product does not meet the needs and the clients must do significant work to move to the next product.
In the end, the older nomenclature of Alpha, Beta, Release-Candidate was much better at identifying the state of a product. Such naming conveyed the developmental state without making a presumption of declaring something viable.