The idea of a Minimum Viable Product (or MVP) has recently become popular to describe “a version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort” – Eric Ries.
An MVP is a balancing point between development effort put in and enough of the feature set built to gather meaningful feedback. Early architectural releases that solve some particular problems or demonstrate minimal requirements do not qualify as MVP because the amount of learning is limited.
MVPs are commonly misunderstood due to different interpretations of “minimum” and “viable” as well as their application to different contexts (e.g. services vs. products vs. product families). The concept is useful for establishing the balancing point between effort vs. progress that can be used to test if a Product is likely to succeed or not from an integration, adoption or sales perspective.
We do not recommend placing overdue importance on an MVP, or describing a multi-release lifecycle as a series of MVPs as this leads to confusion with classic prioritization schemes. Why would a team ever release anything that isn’t viable? Why would we ever do over the minimum necessary to achieve business value?
An MVP is a point on the way towards a Release of a Product or Product Family that is a reasonable representative of the intended system, and can be used to gather significant feedback to direct future development – it’s not a stopping point.
To help illuminate the confusion caused by different interpretations of MVP we recommend, based on Henrick Kniberg’s work, also considering at what point along a lifecycle various different stakeholders would identify the points of:
- minimum testable product - early sprints/iterations probing problem
- minimum usable product - first useful functional release
- minimum lovable product - feature rich, top of the game product
A collection of Integration Scenarios (described in the Requirements view) is a good way of defining this point.