So, MVP. A rather hackneyed topic, in my opinion. Anyone who has somehow connected themselves with software development over the past 5 years, with 99% probability heard these 3 letters. But even despite the abundance of information, people still step on the rake of the “ideal product” when creating projects.

This article does not claim to be the ultimate truth. It is not about the importance and necessity of MVP. And not about his role in a lean startup startup. I’m just thinking about what should be the minimum viable product at the time of the pilot entry into the market.

I'll start with a viral sketch of the development path of a startup based on the MVP principle, which walks on the Internet and which you probably met.


90% of authors use illustrations in their publications literally , which is misleading to readers.

Let's analyze?

The top line has nothing to do with MVP. This is understandable. It depicts a classic development cycle. The author used it as an exaggeration for the sake of context in the example below. Of course, there can be no talk of any minimally viable product at the first stage with a wheel. The product went through 3 stages of development (wheels, body, engine) before it could fulfill its mission - to drive.

But the second line, in my opinion, also does not quite correctly reflect the principle of MVP.

Why does my internal understanding of a minimally viable product not converge with such a concept? Assuming that it reflects the development path of a product, it becomes obvious that it has undergone 4 fundamental changes. As a result, its creators received three groups of commodity-generic competitors: 1 - a skate-scooter-bike; 2 - motorcycle; 3 - car.

Yes, the buyer, as we know, does not buy the product, but the solution to his problem. And the skate seems to solve the basic need (move faster than on foot). But after all, a skate and a car are completely different means of transportation, aimed at a different audience and the purpose of driving for each of them has completely different specifics. Different products satisfy the demands for comfort, price, maintenance complexity, speed, etc. As a result, each has its own target audience.

The car has a wider coverage: elderly and young people, those who travel alone or in company, who go to work or wander to another city - they need speed, comfortable accommodation and driving in any weather conditions. The skate is intended solely for one person, more often a child or teenager, and the purpose of the ride is more entertaining in nature. The skate audience will take with hostility the prospect of transforming the product into a car that needs fuel, expensive maintenance and age 17+, not to mention the price of the car itself. And those who need a car will not initially pay any attention to your scooter. Yes, each of these products can have MVP, but they are not MVP for each other.

Henrik Kniberg, the author of this picture, wrote more than once that his image is not always interpreted in the right context. The fact is that he invested a metaphorical meaning in it, in which the goal of the development was not to build a car, but to solve the problem of “getting from point A to point B”. And the simplest viable solution to this problem is a skate. That is, on it abstract and very simplified passed a certain concept of product search. Skate or scooter are not MVP for the car. It is a fact. The picture only shows the idea that as part of the creation of the product, you can make several pivots and eventually find the MVP.

And this rethought version of MVP I liked more:


In the product business MVP of a product is the product itself, only implemented with some simplifications, reductions, and cheaper ones. MVP of a high-rise building is the same high-rise, but not on 24 floors, but on 5, without an elevator, a garbage chute and other benefits. A car’s MVP is a car. Only simpler. First, from the boards and a whipped-up frame, with a weaker engine (or no one at all), seats from the furniture set.But the three key functions that build it from a skateboard or scooter - speed, spaciousness and long trips - will already be with him.

What to wrap in MVP so that people want to try it?

With the concept of MVP figured out. Now let's talk about how to determine the stuffing of a pilot product, prioritize the functionality and make the first version of the product in demand.

The first thing you need to do is find out what tools, features and capabilities will become have for your product.


Pareto principle

"20% of the effort gives 80% of the result, and the remaining 80% of the effort gives only 20% of the result." This is an empirical principle, which means that many phenomena in the world, including development, are subject to this ratio. 80% of your users will use only 20% of the functionality. Therefore, you do not need to spend months polishing your product to a crystal shine before launch. Write down a complete list of the features of the future application and identify those 20% that will cover 80% of the needs of users.

MVP=required + simple

Have you heard about the priority matrix? A popular task prioritization technique that distributes features on the “required” and “simple” scales. Draw two axes where the horizontal axis will show the increase in complexity of the implementation of a particular function, and the vertical axis will represent the path from the desired to the required. Scatter all the planned functionality on this diagram, answering 2 questions:

  1. Is it difficult or easy to implement?
  2. Is it desirable or necessary for the user?


Having a ready-made list using this matrix, you can safely contact the developers.

Rice Score formula

Another effective method for prioritizing ideas and features for MVP. You need to evaluate each function by four factors and substitute the values ​​in a simple formula.

  • Reach - how many users will you improve your life?
    (Rate over a period of time and take numbers from metrics, not from the ceiling)
  • Impact - how much do you improve the lives of users?
    (Very strong=3x, strong=2x, good=1x, weak=0.5x, quite a bit=0.25x)
  • Confidence - How confident are you that the hypothesis is true and the product will fire?
    (100%=high confidence, confirmed by surveys or studies, 80%=average confidence, 50%=low confidence, 50% and lower=a lot of doubt)
  • Effort - how many man-hours, man-days or just days will be spent on implementation?
    (1 person-day=this is the day one developer worked)

Calculate the score for each feature, according to the formula:


Instead of a total

MVP approach plays the role of an airbag and allows you to adequately predict the commercial and technical potential of the product. Therefore, when we brief our customers, we insist that it is better to start development from it. And, of course, we help to determine the key functionality. If you plan to create a minimally viable product, then the best option is to build it on NoCode technology. Today, platforms for developing applications without code are in great demand. They allow you to create web applications of any complexity faster and cheaper, and existing NoCode freelance exchanges help you choose the technology that suits your business needs and a proven specialist. I dare to assume that the tendency to simplify and reduce the cost of development will only intensify. And now is the time to harness its potential.