MVP is a rather hackneyed topic, in our opinion. There is 99% probability that anyone who has been somehow connected with software development over the past 5 years heard about these 3 letters. But even despite the abundance of information, people still fall into the same trap of the “ideal product” when creating projects.
How to make the users love your MVP:).
X
Thank you for Subscription!
In this article we discuss what should be the minimum viable product at the time of the pilot entry into the market.
Let's start with a viral sketch of the development path of a startup based on the MVP principle, which gets around the Internet and which you have probably come across with.
90% of authors use the illustration above in their publications in a literal sense, which misleads readers.
Let's analyze, shall we?
The top line has nothing in common with MVP. This is clear. It depicts a classic development cycle. The author used it as an exaggeration for the sake of context in the example below. Of course, at the first stage where the picture shows only the wheel, any minimally viable product is out of the question. The product goes through 3 stages of development (wheels, body, engine) before it could fulfill its mission, i.e. to enable you to drive.
But the second line also does not reflect the principle of MVP quite correctly. Why does our 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 have received three groups of commodity-generic competitors: 1 - a skate-scooter-bike; 2 - motorcycle; 3 - car.
Yes, the buyer, as we know, buys not a product, but a solution to their 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, with absolutely different specifics of the purpose of driving. The ways various products satisfy the demands for comfort, price, maintenance complexity, speed, etc are not similar. As a result, each product has its own target audience.
The car appeals to a wider range of users: elderly and young people, those who travel alone or in company, who go to work or travel to a random destination - they need speed, comfort and a possibility to drive 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 prospect of transforming the product into a car that needs fuel, expensive maintenance and the user being at least 17 years old may not go down very well with the skate audience - 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, repeatedly wrote 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, a certain concept of product search was transferred onto the picture in an abstract and very simplified form. Skates or scooters are not MVP for the car, it goes without saying. The picture only shows the idea that as a part of the creation of the product, you can make several pivots and eventually find the MVP.
And this revised version of MVP appeals to us more:
In the product business, the MVP of a product is the product itself, only made with some simplifications, reductions, and a cheaper one. MVP of a high-rise building is the same high-rise, but not of 24 floors, but of 5, without an elevator, a garbage chute and other conveniencies. MVP of a car is a car. First, it can be made from boards and a rough and ready frame, with a weaker engine (or no engine at all), with seats from a furniture set. But the three key functions that differ it from a skateboard or scooter - speed, spaciousness and long trips - will already be in it.
What to wrap in MVP so that users want to try it?
With the concept of MVP figured out, let's now 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 to do is to find out what tools, features and capabilities will become necessary 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 + easy
Have you heard about the priority matrix? It is 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:
- Is it difficult or easy to implement?
- Is it desirable or necessary for the user?
Having a ready-made list based on this matrix, you can safely contact the developers.
Rice Score Formula
Rice Score Formula is another effective method of 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’ lives will you improve?
(Rate over a period of time and take numbers from metrics, not making a guesstimate) - Impact - how much do you improve the lives of users?
(Very much = 3x, quite a lot= 2x, fairly = 1x, a little= 0.5x, insufficiently = 0.25x) - Confidence - how confident are you that the hypothesis will be 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) - Efforts - how many man-hours, man-days or just days will be spent on implementation?
(1 person-day = this is the day of one developer)
Instead of Conclusion
The 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, codeless application development platforms are in high 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. We 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.
