Close the panel
Part of
MVP: The Marmite of Agile
MVP: The Marmite of Agile
Introducing the viability scale as an improvement on Minimum Viable Product (MVP).
No items found.
MVP: The Marmite of Agile
Introducing the viability scale as an improvement on Minimum Viable Product (MVP).
Written by
Niall Lavery
Minimum Viable Product (MVP) is the Marmite of agile. You either love it or hate it.

In the UK, we have a food spread called Marmite. It is a constant bone of contention for tea and toast lovers across the country, as you either love it or hate it! If you have been involved in an agile product team you probably have a similar love-hate relationship with the term Minimum Viable Product (MVP).

It is a term that divides opinion.  The challenge being that the term can mean different things to different people. It is totally subjective. Due to the difference between these (often wildly different!) interpretations, grey areas and cracks can appear between stakeholder groups, which causes product teams to fail or underperform.

In my product adventures, MVP can become a swear word as it is often used as an excuse for feature light, or poor-quality products. This often happens as timelines get squeezed and expectations across your stakeholder group of what will be delivered, and when it will be delivered vary. So, in a bid to buy our teams more time, we classify the slightly underwhelming product as an MVP with the promise of something better.

In order to manage expectations, it is important to clearly define what you mean by MVP.

Inevitably, you will have your own relationship with the term and, whether you love it or hate it, it is a common term used in agile. So, collectively defining your team’s understanding of MVP is so important as it will help you to set, align and track stakeholder expectations from the outset.

By communicating and agreeing a clear definition, product teams introduce clarity about the team’s journey along the product roadmap. Expectation setting is fundamental to the success of product teams and the delivery of an MVP is often the first shot that a product team has to align a group of stakeholders, so it is important to get it right.

People’s understanding of the term, rightly or wrongly, range from something that is very lightweight, like a prototype, to fully functioning, production ready solutions and everything in between.

When I train, I like to discuss 3 example definitions of MVP from some of my favourite product folk so that my students can think about what works for them (and I throw in another definition that I’ve come across once or twice too often!).

The possible definitions.

Meaning One: Next Best Test

Coined by Jeff Patton, the ‘next best test’ means developing the lightest or simplest thing that validates a hypothesis, to facilitate learning.  

For example, this could take the form of a prototype where no code is written or a light proof of concept with a limited amount of code written to demonstrate if there is value in undertaking a larger scale development.

Think of this as validating an idea conceptually and technically.

Meaning Two: Minimum Marketable Product

Described by Roman Pichler as the highest quality, yet lightest version, of production ready software to successfully facilitate and satisfy actual users, and to facilitate learning.

For example, this could be a soft launch of a new case management tool to a small number of pilot users. MMP can serve a specific user persona and does not need to satisfy all types of users. It should provide just enough features to add enough value to the user base to be functionally better than what was there before and enable learning for future iterations and user base expansion.

This is where the confusion sets in. What does ‘successful’ mean? And how long should it take? Success must be defined and subsequently appraised using measurable key performance indicators (KPIs) and hypothesis statements to validate learning.

This is often where people jump to when thinking about MVP as they think about real users, go-live and return on investment.

Think of this as validating an idea operationally.

Meaning 3: Minimum Loveable Product

From Henrik Kniberg, this means the minimum number of features to provide the maximum amount of appeal and delight to users, and to facilitate learning.

This comes down to a product that creates satisfaction as well as function. For example, the Pokemon Go app was initially loved by users as it offered a new augmented reality experience that delighted and excited users from their first login – albeit performance was by no means perfect!

Think of this as validating an idea commercially.

Meaning 4: Minimum Maximum Product

Used by no-one sensible ever, using MVP to refer to a feature-rich product with all features may seem crazy, but I have been in the position where stakeholders optimistically hope that MVP means that all the identified, potential features will be squeezed into the agreed timescale.

If your stakeholders start here, it is important to reign them back quickly to one of the above definitions!

Product teams should adopt the Viability Scale to clearly define MVP.

At the end of the training session, I then provide a framework that students can actually use in their day to day work. When it comes to defining clear test and acceptance criteria during product development, I find that there is a Viability Scale that works really well for development teams, business sponsors and staged investment decisions:

  • Conceptual viability – does a prototype excite and fit a market opportunity?
  • Technical viability – can we build it well and efficiently?
  • Operational viability – will the product work sustainably and effectively with the people and systems that would rely on it?
  • Commercial viability – the final test: does it sell?

There is a place for all stakeholders to be accommodated across the Viability Scale. In most of the products that I have led, MVP as a prototype was meaningless to senior stakeholders and users. Inevitably, product sponsors and users find it much more understandable to talk about the features required to go into a first release; they want to see it, feel it and touch a real working solution.

Technicians on the other hand, need to see and try stuff soon!

I accept that MVP can mean whatever you want it to mean: the word viable is so ambiguous there is no ‘right’ definition. But whatever narrative you choose, simply be clear about what you mean. Then, and only then, can your team can move forward with clear expectations and with (hopefully) less hate and more love.

Here is some of our research and thinking in this area.