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.
