[THIS POST ALSO APPEARS IN LINKEDIN https://www.linkedin.com/today/post/article/does-mvp-poc-km-mukku?trk=prof-post%5D
Is an MVP (Minimum Viable Product) and a POC (Proof Of Concept) the same thing? Reading through some of the write-ups one would conclude that these two concepts refer to the same thing. The truth is that there is a big difference between an MVP and a POC. This is an offering of a minimal differential diagnosis for the potential misunderstanding.
- An MVP is, “that version of the product that enables a full turn of the build-measure-learn loop with a minimum amount of effort and the least amount of development time”, Eric Ries.
- The above definition makes it amply clear how far removed an MVP is from a POC.
- “Minimum amount of effort” is not to be translated to quick time. It is important to ensure that the “measure-learn” part of the build-measure-learn has a logical self-sufficiency in the release.
- The “least amount of development time” is not just a number one chooses at random, but maps to the sprint duration and the measure of difficulty in the release.
- The MVP approach is best suited for software development in a start-up situation. Hence, customer feedback is of utmost important, and exactly why the “small effort” and “small development time” are required to allow for both “fast fail” and “fast feedback”.
- MVP works best in a Devops environment. MVP works best in the cloud environment with continuous integration/release/delivery.
- Without Devops the hand overs would elongate the delivery cycle. Without cloud deployment product release is just the legacy method with MVP attached for the sake of modernity.
- A POC is a short duration execution to validate an understanding of a domain issue. Technical issues are not resolved by a POC.
- A POC is always discarded after the exercise, of course the POC exercise might be repeated if the previous POC failed to provide the sought after clarity. But, more importantly one needs to know the reasons behind the failure, rather than blindly repeat the exercise.
- In all but very few software product development scenarios should the execution duration exceed a couple of days. If it is planned for more than two or three days then there is a bigger problem buried under this need for a POC.
- Executing a POC also requires a certain skill set; doing so with babies when seasoned young blood is required is to court certain failure.
- These two errors, of selecting the wrong resources and extending the POC to a full product are tragicomedies played out many times over in organisations.
- Organisations that outsource product development are keen on saving a sprint cycle; to save a horse a kingdom was lost.
- Do not confuse a POC with the future Product; it does not go through a cycle of build-measure-learn loop. It is basically build-clarify-stop.
- POC is a term that sits well with the design of physical products as evidenced in the design of cars, for example. Hence it also leads to a lot of questionable practices when applied to software development.
- It is the also the single most reason why a POC is misunderstood and extended to be the future product, particular organisations that outsource product development.
- All this is not to suggest that POC cannot be used in software development. But, its use will require a greater appreciation of the limitations when applied to software development.
- POC does not depend on agile or lean methods, and certainly does not need a Devops environment. Although, it can be used in such methods, it is essentially a small time-boxed execution.
- MVP cannot really do well without agile and lean methods, and neither is it really possible in a non-cloud, non-Devops environment. This does not preclude it being misused in these environments either.
- MVP cannot work without the stakeholder (particularly the client) feedback. It success is entirely dependent on the receipt of such feedback. But, this is mostly not true of a POC, unless we are talking of a physical product.
- MVP <> POC.