Understanding the MVP - Value or Viability?
Minimum Viable Product (MVP) is an ideological approach to development that ensures the maximum return from the least effort, expense and commitment. The idea is that at each stage of development, a working product is put forward which allows for return on investment either through financial gain, user feedback or even understanding what’s actually needed. This allows development to be dynamic and enables fast feedback loops; allowing the direction of development to pivot.
How does MVP based development compare to Waterfall based development?
This is a common depiction of the ethos of the MVP approach. A typical Waterfall style development process may see deployment like the top image.
If your objective is to build a product that gets you quickly to work in the morning, you may think that building a car is the best way to achieve your objective. Therefore, you may build a car piece by piece; where each stage doesn’t bring any value towards your objective until you reach the end of development. An engine doesn’t help you get to work quicker unless you have a fully working car.
On the other hand, if your objective is to get to work quicker; you may first start with a skateboard; obviously it won’t be as fast as a car; but it’ll certainly be faster than walking. Next you may build a scooter, then a bike, then a motorbike, and then finally you reach a car. At each stage of development, you bring more value to the customer. However, what if you get in your car and realise you’ll be stuck in traffic all morning; maybe you’d wish you had a motorbike instead? Should you have stopped development early? Did you already reach your objective?
MVP approaches save your company time and money
Take this for example, a company moved their offices from London to Amsterdam and therefore thought that they needed a system to translate internal documents to Dutch.
The approach they chose was to write software from scratch to translate English into Dutch, this took over 3 months and at great expense. The objective was made clear, so the company chose a Waterfall approach; build the translator and then deploy the system.
Once the system went live, although it worked, the company realised there was no real necessity for it and nobody used the system.
What if they took an MVP approach?
Say for example, the company first used an existing translator and integrated it into their system. Of course it would produce the same results, the documents would be translated appropriately, the customers would have been able to use the system successfully. Yet what would have been different?
The integration of an existing system would not have taken 3 months and therefore would not have been so costly; whilst putting out a nearly identical system in terms of viability and bringing the customer value.
However, understanding the MVP comes down to this point.
Even if the company used an existing system and saved all that time and money, would there still be a customer for the system?
If the answer is yes, that’s great! After feedback from the customer and perhaps more investment, the developers could then choose to write a system of their own whilst incorporating customer feedback; bringing more value to the customer and the company.
If the answer is no, the company would have saved time and money in not developing their own translator and development can end.
Both approaches reach the same destination of the product being useless and unnecessary, yet the MVP approach reaches that conclusion at much less expense; whilst bringing the same value to the customer.
So how do you ensure that an MVP approach brings value to your company?
Understand what your objective actually is
Establishing a clear business objective is imperative to successfully deploying with an MVP approach. Work backwards, start with what you want to achieve in the end and identify the minimum viability associated with that objective. Given the translator example, push back against ideas that don’t achieve minimum viability.
Continuous Delivery
As shown in the car graphic, constantly putting out improvements to the MVP ensures that the customer always receives value; and in turn their feedback will help focus development to the next iteration of the objective.
Testing
Testing, with the customer, each iteration of the MVP can inform the next stage of development. However, more importantly, when issuing the minimum viability; you actually need to produce a viable product.
Conclusion - Knowing when to stop
An MVP approach to development demands a certain amount of self-reflection; throughout the deployment process. Consider the car graphic again, if our objective is to get to work as quickly as possible; you may think the car is the best choice and develop to the point of reaching that method. However, once you get there, you realise that the car gets stuck in traffic; and the motorbike actually fulfils the objective better even if it wasn’t the original plan.
Ask yourself, was the objective wrong in the first place? In our example the answer is yes, but given our process of continuous delivery; it’s easy to go back to the motorbike. With the Waterfall method of development, you realise the car gets stuck in traffic and you have to start from scratch again.
So, understand your objective, reflect on whether you're moving towards it or away from it, test your product at each stage; and most importantly, know when to stop.