Minimal VIABLE Product (MVP)

The term Minimum Viable Product (MVP) in my experience gets tossed around and even may be abused quite a lot. .

In this blog I am trying to define the term and its ideal usage considerations. .

Definition:

“Minimum Viable Product (MVP) is a strategy used for fast and quantitative market testing of a product or product feature – Wikipedia”

“An MVP is not a minimal product, it is a strategy and process directed toward making and selling a product to customers - Wikipedia”

Relative Terms and their definitions:

Minimal Desirable Product: same as MVP but from a Business user perspective

Minimal Feasible Product: same as MVP but from engineering feasibility perspective

Prototype:” A prototype is an early sample, model or release of a product built to test a concept or process or to act as a thing to be replicated or learned from – Wikipedia”

POC: Proof of Concept: “A proof of concept (POC) or a proof of principle is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used – Wikipedia”

My Definition:

A strategy, a Product Management approach built to test waters of a product, architected  beyond minimalistic, Business Viable, technically feasible, sufficiently desirable to the point of usability, open to add on all bells and whistles.

With the advent of agile development, the innovative organisations and the start-ups adapted this change in development paradigm. Release early, Release often. Start small, smart. MVP proves to be an excellent strategy to test market, acceptability, reception, traction, and momentum. Iteratively build BIG. I believe although the term is more recent the concept isn’t.

Given the above definitions:

A POC is done if there is a technical challenge, a concept, a hypothesis to be proven. POC can also implement an extensible architecture, however in most scenarios POC is not architected to the roadmap. 

Some Considerations

·         MVP is not for demonstration purposes only.

·         Idea/Concept if it is disruptive innovation, new and never before tested, then there are chances that a minimal product would change the world, at least the part of the world targeted, however when the Idea/Concept is after well-known domain, predictable, where traditional business methods are sufficient, somewhat existing market in the segment of sustaining innovation minimum will never be enough, always build a viable product (with the minimum features that would make it so).

o    Minimum must be enough to compete against existing products and possibly differentiate

·         If the product is trying to serve an underserved area, but does have dependency on other functionality, make sure that the product enables (links, integration points) the dependent functionality appropriately

·         MVP architecture should not be short sited, example: if the intent of the final product is to be Omni channel the architecture should be considered upfront and prevent a complete Re-architecture post MVP. I believe that architectural investment beyond minimalistic approach will produce best results

·         Cost being the key, Architecture with Bells and Whistles (not done right) will be expensive, but cost will remain a concern hence redoing architecture all over again is just bad design,  architecting in such a way as to prevent the re-architecting is the key

·         Group of users or early adopters as they are called, must be able to come back to use the MVP again and again, hence it is not a once up, demonstrate, use and shut down exercise

·         MVP may be incomplete from functionality, but not low quality

·         MVP should not be looked at as “MP”, market values functionality

·         MVP where fits should support in place upgrades

·         MVP should be built in such a way that the user feedback should be incorporated and turned around quickly 

Understanding the difference between gold plated requirements vs. must haves, Over-Architecting vs. Architecting, scalable vs. Unscalable architecture, Scoping functional and non functionals, etc. while being part of the product management, calling it MVP should not be a reason to take inappropriate short cuts in product development. Iterating enough to find the viability in the product requirement and looking at the architectural roadmap and architecting for the same according to me, are key to a successful MVP implementation.