But before we talk about the Minimum Viable Product (MVP), it’s important to understand agility. The purpose of agile development is to put products into the hands of real users as often as possible, and use their feedback to inform the future direction of development.

Many teams are following implementations of agile frameworks with all of the how and the what, but none of the why. The value of agile development is not measured by how well a team refines its backlog, facilitates collaborative daily standups, accurately estimates its user stories, or pair programs. All of these are useful tools, but their only purpose is to enable the team to quickly respond to changing requirements.

If a team is not regularly releasing incremental value to real users (meaning the intended end user), receiving feedback from real users, and using that feedback to decide what to do next, the team is effectively working on a waterfall project.

How does this relate to the minimum viable product?

Many readers will have seen these images, or images like them:

In the case of the image on the left, the user wants to get from A to B, and the skateboard allows them to do that more quickly than walking. It provides real value. Compare this to the wheel, and then four wheels on an axel. These are not viable products, they’re not capable of getting the user from A to B, and therefore it’s impossible to get actionable feedback.

What these images fail to explain is that when we make the skateboard, we do not know that we are making a car or even that the next step is a scooter. This progression is the result of user feedback:

• “I need something more stable than a skateboard”
• “I need something faster than a scooter”
• “I need something faster than a bicycle”
• “I need something that can carry more people than a motorbike”

In a different scenario, it’s possible that the skateboard, or the bicycle, is the desirable solution to the problem. We could learn that the routes which the user intends to take are too narrow for a car, or that the user needs a vehicle which can go offroad, or that what they really need is a unicycle.

The value of building based on feedback is that we minimise the amount of effort that we waste building based on assumptions.

Requirements Gathering

“If I had asked my customers what they wanted, they would have said a faster horse.”

Henry Ford

The agile process starts with requirements gathering. As engineers, we are technical experts and our clients hire us for that expertise. Instead of expecting clients to provide us with solutions, we should aim to identify:

• The problem which we need to solve
• The minimum set of features, and non-functional requirements, which can solve it

This should involve input from the intended users. Executives and agencies rarely have the ground-level experience needed to understand what the users actually want. We also need to take into account any non-functional requirements, such as:

• Regulatory compliance
• Suitability for the end user (a command line application may be fine if the end user is a platform engineer, but would be wholly unsuitable for non-technical users)

This is where we start to emphasise ‘viable product’. A software product which cannot be used in production is a prototype, not an MVP.

A Concrete Example

Imagine that we live in 1985, years before the dawn of instant messaging.

Our client tells us that whilst they like face-to-face meetings and telephone calls, they’re struggling to establish a way for people in their London office and people in their Sydney office to communicate. The two offices don’t share working hours, so synchronous communications are out.

We speak to some of the intended users, and they tell us that their main use case is sharing reports and strategic discussions between the Sydney team and the London team. They also tell us that they need to be able to have multiple people in a single discussion.

What’s the minimum viable product? Slack? IRC?

My initial thought would be to offer an e-mail list. It’s an easily configured off-the-shelf product with a common standard, it allows the users to share documents and to discuss strategy in threaded discussions, and we can have it up and running much faster than bespoke code.

It solves the initial problem.

It’s possible, though unlikely, that this will be exactly what our user wants, but if not, it will be better than what they had before, and it will allow us to capture requirements to incrementally improve on the value we’ve already delivered.

Perhaps they need something more immediate, in which case we’d be looking to implement an early stage instant messaging platform with file sharing. Perhaps the speed of response is fine, but they want something where the threads are easier to organise, in which case we’d be looking at something closer to a BBS or a forum.

Conclusion

Feedback-driven development allows us to spend the least amount of time possible building the wrong thing, and the greatest amount of time possible building the right thing.

The Minimum Viable Product, in its most simple form, is the smallest unit of development which delivers value to real users, and kickstarts that feedback loop.

Cover photo by Paolo Nicolello on Unsplash.