The real value of focusing on the Minimum Viable Product (MVP) lies in the learnings gained along the way and the ability to adjust plans early. In this article, we will explore how to effectively communicate this idea and clarify common misconceptions.
The Minimum Viable Product or MVP is a widely spread concept in Product Development and Software Engineering, popularised by Eris Ries in his book “Lean Startup”. The key idea is to get valuable feedback as soon as possible, so you can course correct early. In this article, we are sharing a new visualization that can help you plan and communicate your MVP effectively.
The Skateboard-to-car Analogy
One of the most popular visualizations of the MVP concept says that your product is a car, you should begin by building a skateboard first. Then iterate through the stages of a scooter, bike and motorcycle. This metaphor has helped many people see the benefits of integrating and exposing early in the product development process. In fact, the phrase “building the skateboard” has become almost a proverbial statement.
Unfortunately, there are some widespread misconceptions about the MVP and this visualization either emphasizes them or fails to rectify them.
- “Either way we know from the start what we need to build.” WRONG. When building a new product – by definition, you’re building something no one has built before. You cannot know from the start how exactly your final product will work. Instead, iterations and feedback will guide you there.
- “You can already use the skateboard while you are building further iterations”. SORT OF. You can use early iterations, but the value you gain from learning about the product and customers at this stage should far outweigh the value of actually skating from point A to point B.
- “Going through iterations of an integrated, working product is faster”. THAT’S NOT THE POINT. It’s well established that late integration usually takes significantly longer than anticipated and often causes re-writes of essential parts (“Oh, this is how your part actually works”). However, the key here is that starting in the right direction earlier allows you to spend more time on activities that actually contribute to the product.
The Journey to Your Product is Not Linear
To visualize the benefits of an MVP approach without fueling these misconceptions, we propose a tree of iterations. Our visualization is also centred around the product that drives us at Delivery Hero: getting things from point A to point B, and it also includes a skateboard and motorized vehicles.
The essential part that it illustrates is that at each iteration, you can trial your product and assess its viability at the most important angle, in this case, “getting from point A to point B”. You can validate your riskiest assumptions e.g. a vehicle can get there faster. Moreover, you can discover various aspects you may not have even been aware of before e.g. customers cannot use it without a handle or customers actually want to move items rather than themselves or the ground is not smooth enough.
Now, just to state the obvious, this is not an example because no one has or would develop any of the depicted products like this. It’s a caricature because a real-world example would involve much smaller iterations and usually require a deep understanding of the product and business, not illustrating the argument very well.
Conclusion
With this image, we hope you will find it easier to explain to your stakeholders and team, why you are building an MVP, what it should and shouldn’t include, who should actually test it, and how to evaluate it. The goal is to reduce risk by testing your riskiest assumptions as early as possible and allow yourself to course correct in case of surprise learnings.
If you like what you’ve read and you’re someone who wants to work on open, interesting projects in a caring environment, check out our full list of open roles here – from Backend to Frontend and everything in between. We’d love to have you on board for an amazing journey ahead.
