How to Build an MVP: The Best Feature Prioritization Techniques
Join the DZone community and get the full member experience.Join For Free
According to a study conducted by the SBA’s Office of Advocacy, four out of five small businesses survive one year. BCG Global Innovation Survey 2015 reports that 42% of innovations fail by virtue of long development time.
Choosing the wrong idea results in 32% of breakdowns. What’s more, business owners often spend a lot of resources on service improvement without engaging users to check their willingness to use it. As a result, the end solution doesn’t meet customer expectations. CB Insights found that “no market need” is the main reason for startup failure.
However, how do you make everything right building a user-tailored product, saving time, reducing costs, and generating profit? Well, start with MVP development.
Minimum Viable Product
When creating an MVP, you implement only the core functionality, which is generally 2-3 key features. This approach was invented to check hypotheses and avoid extra expenses. Once the first version is ready, you test it on users to collect their feedback, measure reaction, and learn how to improve the product.
Since today’s market is overwhelmed with numerous, similar applications, it’s difficult to fill a niche. Therefore, you need to propose real value by addressing a user problem and providing seamless user experience.
The best way is to listen to customers and enhance the product accordingly. MVP development is the safest, low-cost, and low-risk approach to see if your idea is reasonable and actually solves issues it aims to.
The 3 main ideas behind MVP development are:
In a short period of time, via a minimum but sufficient functionality, a software development team makes a product to verify high-risk hypotheses.
However, what is the minimum number of features? Is it only an authorization flow and a start onboarding screen, or is it a full-fledged application with a limited amount of the most necessary features? The latter is the closest to the right answer. But how can we understand what functions are critical and what aren’t? Prioritization will help you resolve this issue.
You may also like: 7 Common Mistakes When Developing MVP.
How to Define Priorities
Based on various criteria, the prioritization process is quite challenging. Here, you should define the product goal and the target audience, as well as to conduct competitor analysis. There are several questions that significantly simplify this task.
What problem does my product solve? Specify the primary objective of your future app/service.
Who is experiencing this problem? You can’t create a product for everyone. It also makes no sense to deliver a service that nobody needs. Therefore, think about who encounters the defined problem. This is your target audience.
How frequent is this problem? If users have to resolve the problem once a year, is it worth investing resources to address it?
How do people solve this problem now? Find the means that let customers cope with it. How can you facilitate this process? Is it possible to suggest a new, faster and more convenient way? How can the existing solutions be improved?
By answering these questions, you will get the vision of future functionality. Although the list of desired features may be very long, you need to differentiate critical things from wanted. When functions are listed by priority, it’s much easier to prepare a project roadmap and plan the entire work. Take a look at how to do it!
Distinguishing “the Needs” from “the Wants”
A list/backlog may contain dozens of features: from small to large, from easy to complex, from common to totally unique. How do you filter all of them and assemble the minimum, sufficient to verify the idea?
To get a better understanding of how prioritization techniques work, let’s consider a simple example. Say, you are going to deliver an MVP of a progressive web application for an international airport.
After several brainstorm sessions, a pull of features was prepared:
A detailed airport plan.
A route constructor between point A and point B — to navigate people helping them reach the desired place.
A list of flights including time, date, etc.
Search by flights.
Flights filtering and sorting.
Push notifications to inform about flight status changes, incidents, etc.
Airport transfers schedule.
List of duty-free shops with current promo offerings.
Online chat with airport service workers.
Online customized games for people who are waiting for their delayed flights with the ability to exchange game points to some merchandise in duty-free shops.
Now, let’s try to prioritize these features using some proven prioritization techniques.
Feature Priority Matrix
This is a popular visualization tool among engineers who adhere to Lean startup development and those who follow the Custdev approach. Being one of the simplest and most effective ways to prioritize features, it provides different modifications but the most well-known is a matrix that has two axes.
However, you can add more axes depending on your needs and goals. For instance, in our custom web development company, our team often employs one more axis to facilitate the prioritization process and increase its accuracy:
Effort: the number of resources (time/labor/material) required to implement a feature.
Impact: the value a feature adds to business and users.
Risk: demonstrates the overall feature’s risk level (for example, as some function is too difficult to integrate, the team is likely to waste too much time on it and not meet deadlines or/and budget).
What we have here:
Must-have, include in MVP: Low-risk features that aim to solve user issues and must be implemented in the first version. If their implementation requires little effort, congratulations! A perfect match for an MVP. We should place the features 1, 3, and 4 from the example above in this category
Can be done: Low-risk functions that demand little effort but provide less value for the end-user. Features 5, 7, 8, and 9 are placed into this category. They are delivered in the next app versions as the primary idea is to first check if customers really need this product and what functionality they would like to have in the future.
Nice-to-have: This category contains the “killer-features” that make the product stand out from the others. In most cases, they are harder to implement due to a higher level of difficulty and uniqueness. In practice, this functionality is rarely built in the MVP but added in the next versions. Feature number 2 falls into this category.
A waste of time. Don’t include in MVP. Lots of effort, risky, low impact on customer engagement. Not worth wasting time. Feature number 10 is a perfect example of this type.
One should note that after the product is launched and user feedback is collected, functions that were left in yellow, orange, and red areas can be reconsidered again. As a consequence, a new pull of features can be created and analyzed for further development.
Advantages of Feature Priority Matrix:
You validate features and define their priority in terms of three values: Impact, Risk, and Effort.
Higher focus on the target audience needs and expectations regarding your service.
Enables to get an objective vision of things based on feedback from real customers.
Can be time-consuming.
Assumptions can be ambiguous when nobody from the development team isn’t participating in prioritization.
Suggested by many famous project managers and product owners, this MVP development approach is the most common way of validating features and specifying the required minimum. Its founder Adam Nash, Vice President at Dropbox, says that Feature Buckets work best for prioritizing functionality in consumer online solution delivery.
In this technique, you divide the list of features into 3-5 buckets (3 is for the classic version).
Metric movers: Features that are intended to positively affect the main KPIs. Your project success or failure will be judged by the KPIs, so this bucket is essential in terms of reaching business goals.
Delights: Things that increase customer satisfaction, for instance, some cool animations, entertaining elements, leaderboard, etc.
Customer requests: Features that users would like to see in the app. This functionality is not required to solve the principal problem, but customers do want to have it. In a messaging application, for instance, it can be integration with Instagram, new funny sticker packs, or the ability to design emojis.
By classifying features of the airport progressive web application (see the example above), we will receive the following picture:
Advantages of this method:
Allows you to visualize and concentrate more on product development directions.
Helps the team clearly understand the goals behind developing a certain feature.
Doesn’t take too much time.
Doesn’t fit for deciding what to implement first.
You don’t see the efforts required to implement the functionality.
These two methodologies are suitable for planning MVP development and further work. Since they both imply manual work, we recommend using automation tools. For example, software solutions like Hygger and ProductBoard employ either Feature Priority Matrix or Feature Buckets but with some minor alterations. This will help you reduce time and effort on prioritization.
There are many different startup development approaches, but you should always keep these three, main points in mind when building an MVP:
Regardless of the chosen feature prioritization method, the main idea remains the same: MVP must solve a certain problem of your target audience.
Don’t try to test too many hypotheses at once. As they say, between two stools one falls to the ground. Test only the most essential ones.
The team responsible for feature prioritization and MVP development should be cross-functional including marketers, product managers, business analysts, and engineers. Therefore, you can guarantee a complete product view.
If you have questions about MVP development or want to resolve some technical issues, feel free to leave comments below. Good luck with your bright ideas and turning them into great digital products!
Opinions expressed by DZone contributors are their own.