Just occasionally I get involved in a project meeting where the term ‘MVP’ is banded about, and although I’m not normally a pedant, for some reason misuse of this term seems to press my agile buttons and its very hard for me to not intervene and correct people.  Being a generally convivial person I normally let the conversation flow,  and then at the end of session explain why their use of MVP was incorrect.

How an MVP approach to software development will save you time and money

For those few of of you who haven’t visited ”Planet Agile’ over the last decade, then ‘MVP’ is an acronym for ‘Minimal Viable Product’.  For laymen in these project meetings MVP has become synonymous with two situations:

  1. Determining the minimum project scope that can be delivered in a tight project timescale and/or
  2. Mid way through a project that is behind schedule,  deciding what minimum set of features can be shipped when not all the headline features can be delivered.

I suspect even a significant number of agile enthusiasts have the same mistaken view of the purpose behind ‘MVP’.  In a lighthearted pedant mood I thought it would be useful to point out what ‘MVP’ is really meant to cover, and how ‘MMF’ is the proper acronym to employ for the two situations described above. By way of explanation ‘MMF’ is an acronym for ‘Minimal Marketable Features’  – also sometimes referred to as ‘MMP’ for Minimal Marketable Product.   Each term is used to to denote different stages of a project/product life, where:

  • MVP is about ‘proving’ business value
  • MMF is about ‘delivering’ business value

A MVP is a project scope that has sufficient capability to prove the commercial viability of an idea .  The flow chart shown below summarises the main steps with building a ‘MVP’:

mvp flow chart

Lean/agile advocates like to talk about “Hypothesis-Driven Development” and how the motivation is about “proving value opportunity”.  An MVP is simply anything that can demonstrate that value to the target audience That ‘anything’ could be:

  • A new product opportunity concept paper,  or
  • A slide deck,  or
  • A wire frame mock-up,  or
  • Working software prototype, or
  • Even an early alpha drop.

However, the reality is that 99.9% of all MVP driven projects are going nowhere near a live/production real world situation, and are usually very thin prototypes used to demo a key business value concept.  Also its worth noting that if there is code underlying a MVP  that this very rarely becomes the basis for the next stage of development.   One key concept behind MVP is the ‘pivot’.   This is where the original hypotheses is not fully validated with the stakeholder audience, but in the process the MVP authors gain a new insight in how their idea can be applied to a slightly different problem.  Don’t mistake this for ‘technology looking for a problem’; its just that not every MVP arrow hits the bulls eye first time.

In contrast a ‘MMF’ is a project vehicle that will deliver value to a client. The scope for an initiative that delivers business value is markedly different to a MVP, in particular:

  • It will need to have a rounded/holistically complete feature set
  • It will almost certainly have to address ‘hygiene’ factors – that’s business speak for having to support features that cover general user/market expectations (e.g. export to PDF)
  • The product has to be sustainable – include factors that address support and cost of ownership aspects.

For a MMF project it is far better to qualify a feature list with a priority rating, something along the lines of:

  • Mandatory – stuff that absolutely has to be completed
  • Firm – stuff that will most likely be completed
  • Contingent – work that may get done if progress on the project is good,  but will be dropped if progress is below expectations
  • Optional – stuff that is unlikely to be addressed,  and will be only be tackled if progress is well above expectations

Typically all features tagged as ‘Mandatory’ and ‘Firm’ become the content that can be labelled as ‘MMF’.    Back to the two situations mentioned at the top of the article. The focus on ‘deliver’ means that the discussion should have been about ‘MMF’, not ‘MVP’ and if the project leadership had used the prioritisation categories mentioned above at the start of the project then the discussions become moot.

In summary…

What’s really interesting about this lack of awareness about MVP and MMF, is that it probably highlights just how few organisations are using hypothesis-driven development to validate new market opportunities.  If nothing else I hope this article will encourage people to start investigating MVP based methods for validating new business ideas, that way giving their organisations a true reason to understand the difference between ‘MVP’ and ‘MMF’.   As a wise man once said, “‘KTA’ – know thy acronyms”.