2.3. Hello Agile: The Minimum Viable Product

Mohammed Rizwan
Sep 3, 2018 · 7 min read
Capri, Italy. Copyright: Mohammed Rizwan

It’s very likely that you already know the term “Minimum Viable Product” (MVP), and by extension, that you’ve previously been involved in the process of building one too. You may then appreciate how difficult (and frustrating) such an effort can be. If that’s the case, then why does Agile promote the pursuit of MVPs? To answer that question, let’s first analyse a famous Maths problem.

The Monty Hall Problem

As part of her column for Parade magazine, Marilyn vos Savant was asked to solve a puzzle. This in itself was not strange; Marilyn held the “Highest IQ” record in the Guinness Book of Records, and she received puzzles from readers regularly. Inspired by a game show hosted by Monty Hall, the reader posed the following:

Suppose you’re on a game show, and you’re given the choice of three doors. Behind one door is a car, behind the others, goats. You pick a door, say door number 1.

The host, who knows what’s behind the doors, opens another door, say door number 3, which has a goat. He says to you, “Do you want to pick door number 2?”

Is it to your advantage to switch your choice of doors?

Marilyn responded decisively: “Yes; you should switch”. This was a controversial answer. Following the magazine being printed and distributed, Marilyn received thousands of letters from readers from up and down the country, including Maths professors and scholars, to inform her she was wrong.

Whilst the Maths community was debating this amongst themselves, computer simulations and detailed analysis of the solution proved Marilyn to be right. The answer was perhaps a little too simple for many to accept. The essence of the solution was the new information revealed by the game show host.

Imagine you’re the contestant. Without any information about what is behind each door at the start, the probability that there is a car behind the door you choose is ⅓. The remaining doors also have a ⅓ chance each of concealing the car. Therefore, the doors you don’t choose at the start have a combined probability of ⅔.

When the game show host helpfully eliminates one of the doors, the probabilities do not rebalance. This means your chosen door continues to have a ⅓ chance of being the one you want, whereas the remaining door now inherits the ⅔ chance of concealing the car.

This extra information, combined with being able to make a different choice, means that if you were indeed a contestant on the show, you would double your chances of winning a car by switching.


On the face of it, this puzzle shows just how powerful new information is. But there’s another, more subtle lesson here for any aspiring Agilist: new information is only as good as our ability to act upon it. The contestant in the game show would not increase her chances of winning if she was unable to change her choice.

MVP vs MLP

Many Agile methodologies are therefore structured in a way to get usable information early, and to be in a position to act upon it. This is done through incremental delivery of software. After each increment, teams and businesses assess the new information they have gained, and use this to guide the next steps. To be considered useful, each increment must provide the information needed to prove or disprove the hypotheses which underpin the product or feature.

One of the most challenging questions teams and businesses face then is: what is the first increment? Given that this first increment must provide enough value to the customer, help the team validate their hypotheses and be small enough that a failure is something the business can absorb, teams must really drill down into the core value of their product, and find a way to build it. This increment is therefore referred to as the “Minimum Viable Product” the business can launch.

The trade-off here is clear: invest more time and increase the chances of the product providing the customer value, or spend as little as possible on the increment until the business knows the product is worth further investment.

This is a simple trade-off to understand, but actually executing on it is anything but. Team dynamics and the organisational culture will impact what the MVP looks like. And unhelpfully, Agile practices don’t necessarily agree on where you should invest your time with regards to this MVP.

Consider Extreme Programming (XP). For teams which practice this methodology, the quality of the codebase is sacrosanct, and thus good quality code with appropriate tests is non-negotiable: the team will always invest in this. This can mean that although the MVP may only offer a limited feature-set to the customer, the good health of the codebase allows further increments to be built fairly easily. As such, XP teams can claim to be Agile, as they can welcome change even late in the day. On the other hand, if the product proves to not be as valuable as the business hypothesised, then the feature is removed, and with it all the well written code and tests too. Depending on the time spent writing the feature, this can be costly.

Interpretations of “Lean” methodologies propose an opposite view: all investment, from design through to engineering is a potential source of waste until the product is proven to be valuable. Therefore, it’s not uncommon to see early iterations of products and features written in short-lived code and designs which target only the most basic user journeys. The prevailing belief is that a product which offers some value to the customer will be used, even if the implementation isn’t ideal. This lean approach aims to minimise losses: if the increment fails to make the impact the team hypothesised it would, the cost of implementation can be absorbed by the business. However, when the MVP is successful, the team must find a way to turn this basic MVP implementation into a long-lived solution. This is often not a trivial exercise, and in some cases can require a full rewrite of the feature for it to be maintainable long-term.

Although the idea of the Minimum Viable Product is accepted to be a worthwhile endeavour, what constitutes as being the ‘minimum’ is highly subjective and unique for each product. This subjectivity can open the door to conflict within teams and organisations. UX designers for example find their designs pared back to a ‘minimum’ state. Stakeholders fear that the product will be ‘dead on arrival’ and shunned by customers, leading to a push for additional features for the first increment. Or perhaps Product Owners find themselves in a position where they simply cannot believe their luck that their idea has made it onto the roadmap, and try to cram as many features into the MVP as possible.

This mix of conflict and fear can result in the complexity of MVPs increasing, the time to market being stretched and crucially, learning if customers value the release being delayed.

Another risk, often not acknowledged, is the impact to the team morale. An engineer who writes code only to serve the minimum, or a designer who designs only for the most basic interactions, can quickly lose motivation and love for their craft. To ward off this risk, some have adopted the “Minimum Lovable Product” (MLP) as the first increment, instead of the MVP. As the name describes, this increment supposes that the product must be loved by customers in order to be valuable. And given teams want to build products which customers love, this seems to be a great fit for customer-centric Agile teams. When teams get into the domain of what is and isn’t lovable, ideas begin to flow and the first increment starts to burst at the seams with all the lovable features packaged inside of it.

Yet, there is a reason why MLP does not feature in the literature of any Agile methodologies: it does not provide the early learnings which Agile principles strive for. Acknowledging this however is not very helpful — after all, the motivation issues caused by only ever pursuing MVPs still remain. So how can this be tackled?

Well, we’ve actually already covered this answer previously: teams have to truly accept that they might be wrong and that the only way to progress is to learn. If the whole team doesn’t buy into this, then MVPs (and MLPs for that matter) are destined to be morale-sapping activities, which provide few learnings and little benefit. This might fly in the face of advice which suggests that being Agile is as simple as picking Scrum or Kanban, but the reality is that the team’s thirst for learning about what their users want and how to best deliver that, is the key to high-performing Agile teams and effective MVPs.


In this chapter we introduced the idea that Agile is about the pursuit of information, and truly learning what the customer needs. Agile methodologies therefore are structured in a way to help such pursuits. In the next chapter we’ll take a look at the most popular methodology: Scrum.

About Agile Bites

Agile Bites is a series of posts written by Mohammed Rizwan which, when put together, intend to serve as a course for individuals and teams. Starting from Agile basics, we’ll move to more challenging topics such as Kanban’s work-in-progress limits and Scrum anti-patterns, whilst attempting to figure out exactly what an MVP is.

Follow Agile Bites to ensure you don’t miss a single post: https://medium.com/agile-bites

Agile Bites

Mohammed Rizwan

Written by

Agile Bites

Bite sized Agile - perfect with a cup of coffee

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade