How to Define an MVP Feature Set and Make Customers Fall in Love With Your Pilot Product

Published in

Product Coalition

7 min readJul 30, 2020

Reflection on what a minimum viable product ought to look like at the time of its pilot release to the market.

So, MVP. A topic that has been pretty well threshed out so far. There’s a 99% chance that anyone who has been the least bit involved with software development in the past five years has heard those three letters. But even with the copious information available, people continue to fall into the trap of the “ideal product” when creating their projects.

This article makes no pretense of being the supreme authority on the question. It is not about the importance or necessity of MVP or its role in prudent startup launching. I will simply reflect on what a minimum viable product ought to look like at the time of its pilot release to the market.

Let me start with a viral meme of startup development following the MVP model, which has been circulating on the internet and which you’ve very likely encountered.

90% of authors use this illustration literally in their texts, and thereby mislead their readers.

What’s misleading here?

The upper line has nothing in common with MVP whatsoever. That much is clear. It depicts a classic development cycle. The author has employed it as an exaggeration to provide context for the example below. Naturally, the initial phase — the single wheel — has absolutely nothing to do with a minimum viable product. The product goes through three stages of development (wheel, chassis, engine) before it can perform its intended function of being drivable.

But the second line, in my opinion, also does not accurately reflect the MVP model.

Why does this conceptualization differ from my personal understanding of a minimum viable product?

If we assume that it reflects the developmental cycle of a specific product, it becomes obvious that the product has been completely reconstructed four times. In the end, its creators have produced three categories of generic competitors: (1) the skateboard/scooter/bicycle, (2) the motorcycle, and (3) the automobile.

Yes, as we’re well aware, the buyer is not purchasing a product, but rather a solution to his problem. The skateboard would seem to solve the basic need (to move faster than when on foot). But a skateboard and an automobile are completely different modes of transportation, designed for different audiences, and each is ridden with a completely different goal in mind. The products take different approaches to meeting demands for convenience, price, maintenance complexity, speed, etc. As a result, each has its own target audience.

The automobile has the widest reach: the elderly and young people, people who travel alone or as a group, commuters and intercity travelers — all these need speed, a convenient space, and the ability to travel in any weather. A skateboard is intended for one person only, most often a child or teenager, and its purpose is primarily recreational. The skateboard audience would be furious at the prospect of that product being transformed into an automobile, which requires fuel, expensive maintenance, and a driver’s license, to say nothing of the cost of the car itself. Conversely, people who need a car will ignore your scooter from the start. Yes, each product can have its own MVP, but the products are not MVPs for one another.

Henrik Kniberg, the author of this drawing, has written on numerous occasions that his picture is not always interpreted in the proper context. The fact is, he meant it as a metaphor, in which the goal of development is not to build an automobile, but to solve the problem of “how to get from point A to point B.” And the simplest viable means of solving that problem is a skateboard. In other words, the picture presents an abstract and highly simplified concept of a product search. A skateboard or scooter is certainly not an MVP for a car. The picture merely depicts the concept that in the process of creating a product there can be several pivotal moments before an MVP is found.

This reimagined version of an MVP is more to my liking:

In the product business, the MVP is the product itself, but executed with various simplifications, reductions, and economizations. The MVP of a skyscraper is still a tall building, but five stories instead of twenty-four, without an elevator, waste chute, and other perks. The MVP of a car is the car itself, only simpler. It starts out made of boards and a hastily welded frame, with a less powerful engine (or none at all), and with old furniture for seats. But the three key functions that separate it from a skateboard or scooter — speed, cargo space, and extended range — are already in place.

What should be wrapped into the MVP so that people want to try it?

So much for the concept of an MVP. Now let’s talk about how to determine what goes into the pilot product, prioritize functionalities, and create demand for the first version of the product.

The first thing is to learn which tools, features, and capabilities will be on the “must-have” list for your product.

The Pareto Principle

“20% of the causes produce 80% of the consequences, and the remaining 80% of the causes produce only 20% of the consequences.” This is an empirical principle, meaning that many phenomena in the world, including development, adhere to this ratio. 80% of your users will use only 20% of the functionality.

So there’s no need to spend months polishing your product until you can see your face in it before launching. Write out a complete list of the functions of your future app and determine the 20% that will meet 80% of your users’ needs.

MVP = Essential + Simple

Have you ever heard of a priority matrix?

It’s a popular task prioritization technique that ranks features on scales of “essential” and “simple.” Draw two axes, with the horizontal axis representing the level of complexity of implementing a given feature, and the vertical axis runs from desirable to essential. Place each planned function on this schematic by answering two questions:

Is its implementation difficult or simple?
Is it essential or merely desirable for the user?

Once you’ve completed your list of features using this matrix, you can confidently take your product to the development stage.

The RICE score formula

This is another effective method of prioritizing ideas and features for an MVP. You need to evaluate each function based on four factors and process the values using a simple formula.

Reach — how many users’ lives will you improve?
(Evaluate over a specific time period and take your numbers from data — don’t pull them out of a hat)
Influence — how much will you improve your users’ lives?
(Vastly = 3x, significantly = 2x, adequately = 1x, not much = 0.5x, only a little = 0.25x)
Confidence — how sure are you that your hypothesis is correct and the product will take off?
(100% = high confidence, confirmed by polls or research; 80% = average confidence; 50% = weak confidence; less than 50% = considerable doubt)
Effort — how many man-hours and man-days will implementation require?
(1 man-day is the workday of a single developer)

Calculate a value for each feature using this formula:

Instead of a summary…

The MVP approach acts as an airbag, enabling you to reasonably predict your product’s commercial and technological potential. For this reason, when briefing customers, we insist that development begins with this. And, naturally, we help decide on a key feature set.

If you plan to create a minimum viable product, the best option is to construct it using no-code technology. Today demand for codeless app development platforms is simply through the roof. They make it quicker and cheaper to create web applications of any complexity, and existing freelance no-code communities help select the commercial technology and trusted specialist that best meet your needs. I would go so far as to suggest that the tendency toward simplification and expense reduction in development will only increase. And now is the perfect time to capitalize on its potential.

Note: This article has been written by skillum.org, a no-code freelance community. Translated and reposted with permission by Alconost, professional localization service.

You might also find useful:

Better Product Internationalization With Localization Best Practices

User Flows: How Popular Apps and Websites are Developed

How to Plan a Winning Product Strategy