How to efficiently prioritize product features
These techniques and methodologies will help you prioritize your MVP features to generate the most impact on user experience.
When working on their MVP, many startups have a tough time prioritizing the features they should include in the first version of their product in order to provide a pleasant experience and to satisfy users’ needs without going over budget.
Deciding which features deserve a team’s time, resources, and energy is one of the most challenging tasks of a Product Manager’s job.
We’re going to explain the main techniques and methodologies you can use to prioritize product features to generate the most impact on users’ experience with the least amount of effort.
Important: Sometimes decision-makers propose solutions on risky assumptions. Before jumping into the prioritization of features, it is very important to prioritize and then validate the hypotheses you have about users’ pain points through Lean experimentation and validation. That way, you ensure your product focuses on what actually matters for your customers before dedicating expensive time, resources, and energy. We will discuss how to prioritize and to validate pain points in a future post.
Why it’s essential to prioritize features for your product
Successfully managing a software development project involves finding the right balance between the users’ needs, business goals, and project realities.
Following a rigorous feature prioritization process is critical to controlling resource management and eliminating waste, as it allows the teams to focus on the most urgent and important things at all times.
It also helps you manage stakeholder expectations, keep your budget and deadlines in check, and significantly improve long-term success chances.
In addition, incorporating some of the most useful feature prioritization techniques into your software development process can provide several benefits for your team:
– It allows you to make more objective product decisions, as it helps teams prioritize features based on hard data and research.
– It enables you to focus on the most critical tasks first and keep a more efficient workflow.
– It helps Project Managers to communicate priorities more efficiently and keep a constant track of the tasks.
– It provides a way to manage risk and complexity as your product grows.
Feature prioritization: what techniques to use
The MoSCoW Method
Developed by Dai Clegg, the MoSCoW method is one of the most used techniques in software development. It helps teams prioritize product features and time-sensitive requirements, ensuring the most critical functionalities get delivered first.
Although the MoSCoW method can be applied to any project, it works great when it comes down to deciding which features will best meet users’ needs and expectations.
One of the primary benefits of this technique is that it forces teams to make hard decisions regarding the direction the product will take. It’s called MoSCoW because it weighs features based on the following categories:
– Must have: As the name suggests, this category consists of features that are fundamental for the product. These are usually mandatory, non-negotiable functionalities that, if not delivered, the product would be a total failure.
– Should have: These are the features that are important for the product but are not critical for success. They add significant value to the user experience, but If they are left out, the product would still function. Most of the features in this category are typically delivered in subsequent iterations.
– Could have: The features in this bucket are usually small enhancements that delight users but are not essential to the product. They’re less important than the previous two categories, but can be implemented if time permits.
– Won’t have: Here go the least important features. They don’t match the users’ needs or provide any measurable value to the product.
If you want a more in-depth look at the MoSCoW Method, we recommend reading The power of the MoSCoW method by René Morency.
Desirability, Feasibility & Viability
In order to meet both users’ needs and business goals, a product feature needs to be desirable, feasible, and viable for a project’s scope.
Developed and popularized by IDEO, this simple but effective model evaluates product features following these three criteria, allowing development teams to weigh and prioritize them.
Desirability
How able is a feature of solving a user’s problem or helping them perform a critical task?
Considering desirability means understanding whether a feature is critical to provide a satisfactory experience to the user. Desirability allows teams to comprehend if the product is solving the right problem.
If a feature helps users to complete a needed task, then that feature is desirable. To properly test desirability, it’s important talking to UX designers, Product Owners, and marketers, as well as going through user tests and different validation approaches.
Feasibility
How difficult is it for you to develop a particular feature in terms of time, resources, and costs?
Prioritizing features based on feasibility means measuring your operational capabilities. That is, looking at your internal organization and objectively assessing strengths and weaknesses and the possibilities to complete any given task on schedule.
At this point, it is important to talk with your technical team members to understand what can be done and what’s impossible or highly improbable.
Viability
How will this feature contribute to the project’s success via profit, revenue, or other indicators?
Prioritizing features based on viability means ensuring that a particular functionality fits the way customers use and pay for the product. Viability not only considers profit. It also looks at sustainability to ensure that your business contributes to the community and society.
To evaluate a feature’s viability, you can talk to relevant executives and other product managers to understand how this feature works in a bigger ecosystem—both your own and the industry as a whole.
The Eisenhower matrix
Another popular prioritization technique in software development is The Eisenhower Matrix —also known as Urgent-Important Matrix—.
This method allows teams to prioritize product features based on urgency and importance, highlighting the most critical functionalities and sorting out the ones that can be either delegated or dismissed altogether.
The Eisenhower Matrix values tasks based on the following categories:
Do First: These are the most important and more urgent features for your product. Without these functionalities, your product wouldn’t be able to accomplish its essential task. Features that fell in this category should be a top priority for the project.
Schedule: The schedule quadrant is for features that are important, but not as urgent as the ones in the previous category. Project managers‘ mission is to manage the requirements that go into this bucket, prioritizing tasks by their urgency and importance throughout the product roadmap.
Delegate: The third quadrant is for those tasks and features you could delegate as they are not crucial to the user experience but are still urgent for other stakeholders.
Delete: The fourth quadrant is for features that are not important nor urgent. So, to keep an efficient prioritization process, you shouldn’t focus on these features at all.
Impact vs. Effort Matrix
With a similar concept to the Eisenhower matrix, another rather simple prioritization method is the Effort vs. Impact Matrix. In this technique, features are assessed according to these two variables.
– Impact: The effect a new functionality can have in the user’s experience with the product. Since it is a subjective variable, it requires a lot of research and consensus.
– Effort: The amount of work and resources required to build and deliver a particular feature. It involves the effort of the development, UX design, and research teams.
While the Impact vs. Effort Matrix is a fairly straightforward concept, it requires a lot of discipline and consensus between teams and stakeholders to keep the process consistent and efficient.
Suppose you’re using a relative estimation on any axes. In that case, it’s worth isolating some examples from the past that can represent the smallest and the largest amounts of work to assign numeric values to each type of task and define a scoring system.
After coming up with the scoring system, you can divide your matrix into four areas:
– Thankless Tasks: These features have a low impact on the user experience and require a high degree of effort from your team. These are usually classified as «not worth it» or «money pit.»
– Major Projects: The features in this category have a high impact, but also require high effort. Usability redesigns and major features often go in this quadrant. These might be worth doing if you have the time and resources.
– Fill-Ins: Low impact and low effort features. These are the tasks you can attack when your team is idle.
– Quick Wins: The best of the four categories. These features require a low degree of effort but can have a high impact on your product. These are the functionalities of your product you should focus on first.
The Kano Model
The last methodology that we’ll be talking about is The Kano Model. This technique helps teams prioritize features based on how likely they are to satisfy users’ needs and expectations.
The Kano Model can be a helpful framework for teams with limited time and resources who want to prioritize the features with the most impact on user experience.
Thanks to this method, product teams can weigh high-satisfaction features against implementation costs to determine whether adding them to the roadmap is a strategically sound decision.
This method classifies users’ preferences into five categories:
– Basic: Users usually expect these features and take them for granted. These are the functionalities your product must-have. When these features are done well, customers are neutral about it. However, if they’re done poorly, it will cause them dissatisfaction.
– Performance: Items in this category increase users’ satisfaction linearly. The more you have to offer; the more valuable your product would be. For example, the amount of free storage space your storage app provides.
– Excitement: Here go features that are not expected by users, but can cause a positive reaction when present. The lack of these features does not cause dissatisfaction but can increase the overall satisfaction with a product when implemented.
– Indifferent: Features users’ feel indifferent about. These do not result in either satisfaction or dissatisfaction, and in most cases, it is not worth it to put effort into developing them.
– Reverse: The absence of these features can cause satisfaction, while their presence causes dissatisfaction. These are features that frustrate users, and you should avoid building them. For example, excessive steps to fill a contact form.
The five categories can be displayed in this graph. One axis represents the level of satisfaction, while the other the level of execution.
Conclusion
Deciding what features you need to include in the first version of your app and its further iterations is critical for your product and your business’s success.
As a rule of thumb, when it comes to choosing your app’s main functionalities, try to live by the mantra of less is more. That involves being as conservative and objective as you possibly can. Big features can just as easily be big risks if you haven’t conducted the proper user research and validation processes to back them up.
Focus on what is the most important and urgent for your users now, and work from that point forward.
At Bixlabs, we help innovative startups to build their digital products. We’ve developed an iterative product development process, including several validation stages that ensure your product aligns perfectly with your users’ needs and expectations.
If you’re looking for an experienced team to help you build your product, give us a call.