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.
You Keep Using That Word, I Do Not Think It Means What You Think It Means
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.
What is a Prototype?
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:
- Contains the bare minimum features necessary to meet the desired goals/requirements of end users.
- Passes all the same safety and security standards as a full featured product.
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...
You have to get it right the first time
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.
Quantifying MVP Minimum Requirements
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:
- Load Testing: Will the product break under load of hundreds or thousands of requests?
- Penetration Testing: Is the product secure against malicious attacks and/or unexpected uses by users?
- Usability Testing: Does the product work in a way that is consistent and end users can understand?
- Accessibility Testing: Can users with disabilities use the product without significant barriers?
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.