Minimum Viable Product (MVP) is a term that I hear used a lot, and the concept seems pretty simple;
When developing a new product or feature, only develop the bare minimum requirements so that it can be released to the public. Then based on various forms of metric gathering and feedback determine if it is worthwhile (cost/benefit analysis) to flesh out the new product to its full potential.
This concept is particularly useful in agile software development. Here is a good breakdown of the benefits of mvp in agile [link].
That is not what I want to talk about here though.
The unfortunate reality that I keep encountering is people (management) using the term MVP when in reality they mean is "working prototype", and thinking that because it is called MVP that it is deliverable to end users.
However there are very clear and distinct differences between a prototype and a MVP.
Prototype is another one of these words that should not need explaining but still does so here is my take:
A prototype is a working or partially working example of a product or feature that demonstrates how the final product would work in theory. It's purpose in existing is to cheaply demonstrate a concept so that the potential of the end product once full development is completed can be evaluated.
For this reason it almost never includes additional features or behaviors and is not expected to pass the same level of testing that the final product would be subject to. Things like load testing and security vulnerability testing are side considerations that are maybe not critical to the first few iterations of a prototype.
The most important point of a prototype is that it is the bare minimum required to demonstrate a concept and is never a deliverable product in of itself to be given to end users.
So what do we need to go from prototype to MVP?
Speaking purely from a software point of view, a prototype can only be considered a minimum viable product when it:
It is this second point that I have found unfortunately that management tends to ignore/misunderstand. I attribute this to willful ignorance. After all if something looks like it works and money can be made off it today then why bother to invest additional time/money/resources into making sure everything is secure. If something breaks we can always fix it later right...
HA. The amount of applications I have found in the wild with "temporary" hacks to work around a problem that never gets properly fixed would terrify you. It is a sad reality that if code looks like it is working then there is no economic incentive to ever make it better later.
If code does gets fixed it is virtually always only because a customer has complained about a bug, by which point the damage to your companies reputation is done, and this is why MVP is such a dangerous concept when spoken by management.
Now since I do not expect management to ever admit to their own willful ignorance I've tried to compile my own checklist for what a minimum viable product needs to pass to actually be viable.
To be viable a production needs at minimum to pass:
Only if a product passes these four hurdles do I consider it potentially viable and not simply a working prototype. Just because your code appears to be working does not mean its good enough. It just means you and your customers have not seen it fail....yet.