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.
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.
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.
Startups offer a product or service to meet the specific needs of the target audience. The higher the significance of the problem for the consumer, the more valuable the proposed solution. MVP implementation allows at the initial stages of business development to determine how the product meets the expectations and needs of the client. Accordingly, the company's management and investors receive the data necessary to make a decision about the future of the startup.
According to statistics, about 70% of startups fail. Failures are partly due to the release of useless or untimely goods. Recall, for example, the legendary story of the emergence of sugar sticker packets. Their inventor wanted to make life easier for users. He assumed that cafe visitors would be able to break the bags in the middle and empty the contents without spilling a crumb. However, the customers of the cafe continued to tear off the corner of the bag out of habit. At first glance, an ingenious idea turned out to be completely useless in practice. And although the stickers later gained popularity due to their ease of transportation, they did not bring profit to their inventor.
MVP helps to establish the required functionality of the product and efficiently use production resources based on the goals set at the start of development. By creating an MVP, a team can understand customer interest in a product without spending time and effort in perfecting the idea. The sooner creators get feedback from customers, the less effort and expense will be spent on a losing idea. MVP in software development projects gives a more reliable result than surveys of the target audience and allows you to observe the real interaction of the user and the program. This means that already in the process of creation, developers will understand the potential payback.
This concept is based on the philosophy of the Lean Startup and involves an iterative process of constructing a measurement-learning cycle until market needs are fully met. Starting with a minimum viable product, the team focuses on the core functions and value of the proposed idea. SIt clearly understands the most important tasks and implements them in a priority order. For example, in the case of software development, programmers move on to optimizing the user interface only after the release of the minimum viable product.
Answering the question why is mvp important for software development we learn that MVP prevents fear of "unfinished construction" and provides a clear direction for development. In addition, having a functioning product motivates the development team and reduces product managers' concerns about lack of functionality.
Below we have provided a list of benefits of the minimum viable product:
Launching a minimum viable product requires eight preparatory steps. The first four steps are aimed at preliminary refinement of the business idea. The fifth and sixth stages relate to the design of the product, and only at the seventh and eighth points it will come directly to development and testing.
Each product is created to solve a certain problem, and it's not about making a profit. This requires a customer-centric approach. Why does a user need a product?
By clearly formulating the answer, you will get an idea of the purpose of the product and its value to the user. So, by opening a service for short-term rental of parking spaces, you solve the problem that all drivers face - you make it easier to find a place where you can leave your car.
Focusing on the needs of a wider audience when designing an MVP is a flawed strategy. Narrowing down the target audience allows you to more accurately target the future product. To do this, it is necessary to formulate a portrait of an “ideal” user, a person who will buy your solution without hesitation and will be satisfied with its capabilities.
Typically, such a portrait includes information about the age of the user, education level, income, habits, interests and hobbies. These details are necessary to understand how well the product is suitable for the future user, and will help later, at the stage of advertising and promotion.
Don't overestimate the exclusivity of your product, especially if you know in advance about other companies in the industry. Analyze your competitors. Find out their strengths and weaknesses to determine the functionality of your future product. Rank your competitors based on how they compete for market share.
Identify your competitors. Analyze the three main market players, find out how long they have been on it, what products and services they provide. Determine if they have a competitive edge and rate your ability to offer something better.
Describe their market share. Research their past and current strategies, sales, earnings, financial and marketing goals. This data will help you understand how successful and cost-effective they are.
Use primary and secondary sources of information. Information that companies share themselves is the primary source and most reliable for analysis. Visit company websites, view presentations, white papers, annual reports, blogs, marketing materials, and other publications. Secondary sources of information - articles in magazines and newspapers, videos, reports and books - shape public opinion about market players. While these sources may be less reliable than the primary sources, they provide the most comprehensive insight into the industry.
Dig deeper. Feel free to attend business events with competitors, make contacts, use a competitor's product, and analyze reviews.
Use analytics software. Various online competitive analysis tools will make your life easier. Services like Similar Web, Ahrefs, Quantcast, App Annie, or AppFollow collect data about websites and apps. With their help, you can find out about the popularity of competitors' app / site, their monthly traffic, audience interests, geographic location of customers, as well as similar products. Some of the existing tools provide basic information for free. Others, like Moz and SensorTower, are subscription-based.
When you know the strengths and weaknesses of key competitors, you can understand what will make your product unique in the market and what it lacks to become one.
SWOT stands for Strengths, Weaknesses, Opportunities and Threats. This structure is commonly used in strategic planning. However, it is also fairly easy to use in ranking MVP ideas. To perform a SWOT analysis, you need to objectively answer several questions related to the above categories. Let's see what a SWOT analysis might look like using the food delivery example we mentioned above.
The purpose of a SWOT analysis is to focus on strengths, identify and minimize weaknesses, avoid threats, and leverage existing opportunities for further development. Strengths and weaknesses are usually related to internal factors. Opportunities and threats - with external ones.
SWOT analysis helps companies analyze competitors and choose a market positioning strategy.
User flow - the path that the user goes through when interacting with the product. It should be logical and understandable.
User Journey Map - Guidelines for content and site / app design requirements. When building a good user journey map, you need to understand what customers want when using your product. Make sure you provide additional information to users and identify potential issues that might prevent them from moving to the next step.
Let's use the example of Tamam food delivery App to consider a list of tasks that users must solve in order to achieve the main goal. The user's path will be as follows: placing an order, managing an order, paying for food, receiving an order. Once the steps are outlined, you need to define the functions for each of them.
You need to list the required features for the future product. The storytelling method (or user stories) will help you during this planning stage.
User Stories is a dual approach to managing user stories. It allows you to focus on specific parts of the functionality and at the same time not lose the full understanding of the product. The methodology aims to help developers choose useful features from the user's point of view. Its author and practitioner Jeff Patton believes that a function description should contain a human action.
We have listed 4 steps that users take with our product: placing an order, managing an order, paying for food, and delivering an order.
Now we have to describe the functions for each step and write them down on cards. For example, to customize an order, a user can:
After you are done with the descriptions, draw a horizontal line to indicate the user's path, and show the main steps and their functions on the map.
Now let's prioritize. You have to find out how important and valuable a particular function is, how often it is used, whether it has risks, how many users turn to it.
After you have ordered the features according to their priority, draw a vertical line and place them in the order you want. Put the most important and frequently used ones at the top of the list, and place the rest at the bottom.
Once you have prioritized the features, you can determine the scope of the MVP and role of MVP in your software development. The first horizontal row on the map is called the walking skeleton (frame). This walking skeleton is the smallest useful version of a product that lacks "meat", that is, functionality. First, we need to create a wireframe.
In some cases MVP is the same as the framework, and sometimes it has limited functionality. To understand the differences between the framework, the MVP, and its further concept, you must classify the features.
Let's draw a line to separate the main functions from the non-essential ones. The features that you give the highest priority represent the minimum viable product in software development. Others can be added after MVP deployment and feedback analysis.
Once you've identified the scope of work, you can finally start developing your minimum viable product. Let's find out what project management techniques apply to building an MVP.
One of the Agile software development methods, based on several principles: eliminating unnecessary costs, fast delivery, strengthening learning, and building integrity. In fact, Lean uses create-measure-learn iterative development. With Lean, developers can defer most design decisions, establish a fast feedback loop, and make sure they are creating a compelling product.
Another iterative approach to software development. It implies efficient allocation of workload that helps teams complete tasks faster. You can manage the development of MVP features in a sprint (short cycles of about two or four weeks). Define a scrum master who will monitor the stability of all scrum processes. MVP is implemented immediately after the first sprint. The development team can update the product in all subsequent sprints, responding to user feedback. While Scrum is more time-consuming than Learn, it can be less stressful for professionals - suitable for gradual and long-term development.
Focuses on the work-in-progress model and, unlike Learn and Scrum, does not have a cyclical progression. Instead, Kanban suggests focusing on tasks as they arise. This allows you to balance the amount of work with the capabilities of the team. Experts add tasks to the pipeline as soon as they receive feedback from users. Kanban can be applied after the first version of the MVP for a software development project is released and becomes a powerful method if feedback continues to flow.
This is a set of development practices such as code refactoring, small releases, simplified design, coding standards that allow you to improve the code and update it as soon as possible. Development cycles with XP do not exceed one week, so you can run the first version faster and then scale it up. XP is well suited for an MVP that relies heavily on code quality.
Choosing one of the iterative design approaches is critical because it allows you to create a sequential feedback loop.
Alpha - so-called internal testing, when a limited group of people (mainly friends or family members) evaluate a product. If the product passes this test, you can move on to beta testing - let real users try the product for one to two weeks. Analyze the feedback and determine what features need to be added or replaced to make the product better.
If you have collected enough feedback, you can update the product, then test it again and get feedback. The number of build-test-learn cycles and their time frame vary by product. After you've completed a few loops, you can go back to step 0, change direction, or continue to iteratively improve your product.
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.
“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.
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 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.
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.
CEO
Middletown
Warsaw
Kyiv
Lviv
