A concept often used in the same breath as the Agile product development methodology is the Minimum Viable Product or MVP.
To my mind, this is a sorely abused descriptor.
Often I think, things get called MVP’s when they are nothing more than proving models or proof of a concept.
If you’re creating something from scratch or just a concept to show prospects and interest parties – is this really ready for prime-time – is it something you really want to put out in the wild and have to support, maintain and service?
As has been said elsewhere, POCs validate that something can in fact be built. MVPs validate that something should be built. POCs test feature validity, MVPs test market viability.
Back in the day I recall working with a phone circuit designer to create a switch that would do an off-hook dial automatically. It took several iterations before we created what we wanted. Every week I would get the prototype in a bubble wrap envelope, hook it up to my gear and test it. When it got to a level of prototype maturity that I felt made it good enough, we produced a few hundred units – those were MVPs.
The end-game was to consider how to integrate that piece of circuitry into a larger piece of hardware that didn’t have this little widget as an add-on or better still – avoid a circuit based approach altogether and move to something entirely based on a software digital switch that would work with VoIP.
The circuit board was an MVP, since those heady days it has in all likelihood been replaced with something more elegant and more sophisticated but at the time it was cheap and effective for what was needed.
You could argue then, that an existing product could simply be a MVP and the next generation version is a different MVP but in reality, if you don’t plan to do any new major investment in expanding appeal or broadening the market relevance or robustness of the product – why are you doing this?
The objective of any MVP, to me, is to help you determine where to make your next investment, I don’t think it should be considered as a mechanism to coerce existing customers to part with more cash unless the value proposition is considerably greater with your new offering.
I think this idea is especially true if you release a product that doesn’t even have all the capabilities of your legacy product. Consider why would a customer really consider making the switch?
I do think that MVP’s can help you in understanding your product development methodology mindset, though. If nothing else, an MVP perhaps helps bring clarity as to whether your product development methodology really is agile or not.