What Minimum Viable Product is?

Dominik Szczepaniak
6 min readJun 7, 2020

The article has been originally posted on my Polish blog — devszczepaniak.pl.

In short — Minimum Viable Product ( MVP ) is a product that has only the basic features that are required to run and use a product. The MVP term, according to Wikipedia, was created by Frank Robinson in 2001.

The MVP approach has some important advantages. The biggest one is the relatively short development and releases time. Almost every product or application like Netflix, Facebook, and so on looked significantly different than the current version. Since the MVP release, they evolved and still are improved — new features are added and bugs are fixed.

The other advantage is that developing MVP is cheaper than developing the final and complete product. What’s more, if you make a decision that the product is not satisfying or not profitable you can stop developing it at a very early stage without wasting too many funds and time.

A great example could be Facebook Messenger. For that product, the MVP is an application that is able to send and read messages. All improvements like sending GIF files, stickers, video calls, games were added later when the product evolved.

MVP in the work of a programmer

Programmers are a group that uses the MVP approach for most of their work. The most obvious is creating a product roadmap, but also MVP is pretty useful during writing code.

If you write, for example, a signing up form you can split it up for a few phases. The first phase is to create a form that allows registering a new user, the second phase can be adding a validation. Probably this form will contain some bugs or performance issues ( caused by e.g. an invalid regular expression ). Fixing it could be the third phase.

Another place where you can notice the MVP approach is the Test Driven Development approach. TDD includes three phases: red, green, and refactor, where the green phase is the MVP. After creating a piece of code that works properly and meets the requirements ( MVP ) you refactor it, fix bugs, and improve the performance.

How not to use the MVP approach?

Here and in the further part of the article, I’ll use a vehicle as an example of a product to develop. To not complicate the example I’ll be using some simplifications and generalizations.

What is most important in a vehicle? Ability to drive. After this short explanation, we can make a conclusion — the most luxurious and advanced car that can’t drive does not the assumptions of the MVP approach.

Even the ugliest, rusted, without lights, turn signals, or even doors or a hood but that can drive meets the assumptions of MVP. Of course, it is only theoretical contemplation — that vehicle couldn’t be approved for road traffic because of law restrictions.

So how to use the MVP approach?

First of all, you need to set the goal you would like to achieve. As I mentioned earlier in the case of a vehicle the goal is to make it driveable. To make a vehicle you will need a wheel, preferably a few wheels. Now you don’t even need an engine — to move you can use the power of your legs. After mounting wheels to a wooden plank you have created a skateboard!

And here’s your MVP! The created product gives you the ability to move from point A to point B. Although it is quite poor and imperfect it meets the basic requirements. Let’s improve it!

You could improve the steering of your vehicle. Of course, you can use body movement for turning but it is quite inconvenient. Let’s add some steering systems. And here’s your skateboard became a scooter! It still is able to drive but now it is simpler, more convenient, and comfortable. At this step, you can also add brakes.

The vehicle drives and turns but its speed is not amazing. The way how it accelerates isn’t also satisfying. What’s more, a small curb can be an insurmountable obstacle.

Let’s modify the vehicle — let’s improve the construction and accelerating mechanism. The next step is a huge refactor. The result of this refactor can be a bike. Thanks to this our mobility, acceleration, and safety were strongly improved!

At this moment your vehicle is able to drive, turn, and is quite convenient but a huge inconvenience is that you have to use the power of your body to move. The most obvious solution is adding an engine, so let’s do it. Don’t forget to add a fuel tank, turn signals, lights, and mirrors. Now your bike became a motorbike!

Now you are able to move with satisfying speed without using the power of your legs. However, you are not able to take any additional baggage. Also in case of a rainy day, your vehicle becomes inconvenient. These changes need the second huge refactor. Let’s replace the current engine with a better one, add seats, wrap it into a steel cage and your motorbike was transformed into a car. Now your vehicle is safer, more convenient, and is able to take additional baggage and use it in a case of bad weather.

You are almost there! At the last step, your product needs only some amenities like a radio, GPS, air condition, and other visual additions. After a few iterations of improvements and refactors, you have the final product.

Done!

Your final product is ready to use and does not resemble the initial product. You started from a skateboard and finished with a luxurious car, but both products are able to move from point A to point B.

Of course, this example is full of simplifications and generalizations. In real life, it is not possible to create a car from a motorbike but I wanted only to show a product evolution process.

However, there are examples of huge refactors like making a car from a motorbike! You can read a case study of Facebook Messenger refactor where the application size was reduced by 84 percent, from more than 1.7M lines to 360,000.

Personally I use the MVP approach for most of my projects and I find it as extremely useful. This approach is also very useful from the marketing point of view. Publishing the very early version of the product and testing it on real users can give a better perspective and receive a lot of feedback. It helps us to detect UX issues, bugs, and suggestions for improvement. Another opportunity is selling pre-orders or starting a crowdfunding campaign on Kickstarter or Indiegogo.

The only disadvantage of the MVP approach I’ve found is that some users may be discouraged after using the not ready products but still, I think it is worth taking the risk.

Please let me know in a comment what do you think about the MVP approach!

Image sources:

--

--

Dominik Szczepaniak

Professionally Software Engineer at CKSource. Privately a blogger, a fan of Italian cuisine, and a fan of cycling and weight training.