Let’s examine one of the most-shared images relating to agile software development from last year. There are a few variants of the idea (and I apologise for not knowing who to cite as the original source), but the basic theme is the same. Instead of developing a car in progressive phases, they show the delivery of simple, usable evolutions of vehicles until the product vision is reached. I’m not sure this is actually a great example of what a minimum viable product is – or what we are trying to achieve.
What is an MVP?
Very simply, a minimum viable product is the very essence of what you are trying to achieve, leaving any non-essential functionality or other features to be added later.
If your product vision is to create a new e-commerce site, your MVP would perhaps include enough to display a list of products, allow users to add them to a basket and then checkout (handling delivery and payment). That’s about it.
Going back to the featured headline image, if your product vision is to create a sports car or a family saloon (sedan), my expectation of an MVP would be a very basic car. It would be drivable, and include the key basic functions you’d expect any car to have (a chassis / body shell, wheels, brakes, steering, seats and a source of propulsion). It’s not going to be a skateboard or a bicycle…
An MVP will not deliver everything you want, its scope is just the bare-bones of your product. Additionally, it will probably not be something you could use commercially (that would be a Minimal Marketable Product – which I’ll cover in another post) or necessarily include everything that you know you’ll need.
Why create a Minimum Viable Product?
There are two important reasons (for me) why I always aim to create an MVP before trying to add all of the “desirements” to the scope of our work:
Prioritisation
Creating an MVP forces you to prioritise, with the benefit (hopefully) of reducing the chance of a Boolean outcome – not delivering a working product by the end – and instead creating an outcome spectrum.
It takes an amount of maturity and a good understanding of the product vision, as it’s very easy to create a long list of “must-haves”, but if you don’t learn to chop away at some of the nonessential functions, you may not be focusing on the areas that enable the basic purpose of you product. We don’t have an unlimited amount of time, so what we do needs to occur in an order that reflects any technical dependencies, as well as business priority. A great satellite navigation system isn’t much use on a car that can’t drive anywhere.
A Learning Tool
Most importantly, an MVP should help you to understand some of the key decisions you’ll need to make – and expose any fundamental challenges in what you’re trying to achieve.
There is no value in creating something that doesn’t meet your product vision, unless it answers some of the questions you’re going to face getting there. Does producing a motorcycle provide any experience that will influence your cars design? Not many of the more important aspects, I’d imagine…
Now, I don’t develop cars as a profession, but I’d guess that some of the elements you’d need to consider early on would be the passenger compartment (how many occupants it needs to carry), how it’ll be propelled (combustion engine or electric motor) and how the chassis and wheel layout interact with the design. When you discover that the size of the battery required to power the vehicle means that something will have to be moved or changed to make enough space for it, you’ve learning something. Something useful.
Thinking back to our e-commerce site, we’d need a way to access our product data and display it. How will our web application connect to this repository? Where do we store our images – are they suitable for the web – do we require different sizes etc? Payment integration may provide its own set of challenges. If your e-commerce site can’t take payments, how important is a search auto-complete feature?
Your team’s velocity is another thing you’ll start to understand. Building the basic elements of a more complex product will help you to assess the overall effort required to reach the product vision – but what you do has to be relevant.
Some elements of your MVP may even be throwaway. You might find that something you’ve developed has a significant shortcoming – enough to merit a return to the drawing board. The lessons learned bring you a step closer to the right solution. Learning about a bicycle derailleur isn’t a useful lesson towards producing a car.
If your product is a car, your MVP is a car. Not a skateboard, scooter, bicycle or motorcycle.
Setchu - Agile at Scale 