Building an MVP - You are doing it wrong

The term MVP - Minimum Viable Product is no longer a new word. The term was first coined by Frank Robinson in 2001 and is now used very frequently.

The basic idea of an MVP is to make a version of a product available to the customer as quickly as possible. The goal is not to generate sales, but to learn. Of course it’s not a bad idea and it’s also the intention to earn money with your product, but the idea here is to put yourself in the customer’s shoes and better understand their needs and requirements. This allows you to use early feedback and improve the quality of your product.

As you can see, the concept is very simple. But the problem arises during implementation. When we develop a product, we usually already have a fairly clear idea of what the final result should look like. To define how the associated MVP should look, we start cutting features at various points.

The result of this process is then certainly minimal, but is it also viable? Many teams forget this point and develop a prototype with limited functionality, which is simply not usable. As I mentioned in my article about [Scrum]({{site.baseurl }}{% post_url 2018-07-15-agile-get-started-with-scrum %}), the goal of every sprint is to add a working increment to the product. After each iteration the user should have a basic version of his product, enhanced by features of the last sprint.

The easiest way to illustrate this is with an example: If you want to sell a vehicle to someone, there are (in theory) different levels, each working standalone. From a scooter, a bicycle and a motorcycle to a car, each level has its own functionality that offers the customer added value. Also, each level adds features and functionality to the previous version.

The approach, which you might find in practice however, could look more like this: The customer receives the tires first, then the mounted underbody, through the body to the fully assembled car. So you can only really do something with the end product.

So when developing a prototype, keep the goal of adding value in mind. Updates should complement and improve the functionality, but the original product should already be usable.