How to Prioritize Software Development Feature Requests

Feature prioritization is an important aspect of product development. Adding new features to your product allows you to improve it by meeting customer demands and staying ahead of the competition. However, it can be a difficult operation. 

Prioritizing feature requests is an ongoing process in which product teams must collaborate to determine which new features to prioritize. Decisions must consider market competition, cost, time, and available resources, as well as align with business objectives. 

So, how do you know you’re making the right choice? 

In this article, we’ll show you how to prioritize feature requests by considering the dimensions of each feature, as well as popular frameworks for implementing them and how the process looks from various perspectives. 

11 Dimensions of Feature Prioritization

The process of determining which features or functions of a product should be developed or improved first is known as feature prioritization. To prioritize features, the following dimensions can be used: 

1. Estimated Profit

Profit is a significant factor to consider when deciding which features to prioritize. The first step may be to focus on the feature that will cost your team less to build rather than one that will cost more. However, the construction cost isn’t the only figure to consider. Consider the following example, which breaks down the figures involved in two feature requests: 

Cost to build

A: $1,000,000     B: $5,000

Revenue

A: $2,000,000   B: $100,000

Profit

A: $1,000,000   B: $95,000

At first glance, it appears that feature A has the potential to generate $2 million, so why would it not be prioritized over feature B? However, if you do the math, you’ll see that B has a higher profit margin. 

2. Business Value

This dimension factors in how much value the feature adds to the company or organization developing the product. Features that are more likely to increase revenue, lower costs, or improve the organization’s competitive position are typically prioritized higher than features with less business impact.

Market research, such as analyzing customer needs and behaviour and examining the competition, can be used to determine business value. Prioritizing features that align with business goals and objectives is critical to ensuring the product’s financial and strategic success. 

3. User Value/Market Risk

This dimension refers to how much value the feature adds to the product’s end users. Features that have a direct impact on the user experience, improve the user’s ability to achieve their goals, or provide significant benefits to the user are typically prioritized higher than less impactful features.

If you don’t have specific profit figures, you must estimate market risk. The market risk can influence where a feature should be placed on your priority list. 

It is not uncommon for features with higher technical risks to be associated with lower market risk. A social media app, for example, is something that can be built over the weekend, but that means that almost anyone can build it, which increases market risk. Building a teleport device, on the other hand, would take much longer than a weekend and would require a lot more effort, but it would pose a much lower market risk. 

Conducting user research, such as user interviews, surveys, or usability testing, can help to determine user value. To ensure the product’s success, it’s critical to prioritize features that align with the user’s needs and goals. 

4. Technical Risk

Each feature request brings with it its own set of technical risks. Delays, additional costs, or a feature inadvertently affecting other parts of your software in unexpected ways are all possibilities during development. Ideally, you should weigh in on each feature request and prioritize those that will not overburden your development team or process. Less risky features or those with a lower potential for negative impact on the product or project are typically prioritized higher than riskier features.

A risk analysis can be used to determine the risks associated with a feature, which examines the potential impact of the feature on the product, the likelihood of the feature causing issues, and the ability to mitigate any potential issues. To ensure that the product is stable and reliable, prioritize features that have a low risk of causing problems. 

5. Technical Complexity/Effort/Resource Availability

In addition to costs, the availability of resources should be considered when prioritizing feature requests. This can include but is not always limited to, the number of development work hours, time, and effort required to create and maintain each feature. 

Features that can be quickly and easily implemented are typically prioritized higher than features that require a significant amount of time or resources. A feasibility analysis, which examines the technical feasibility of the feature, the availability of resources, and the timeline for implementation, can be used to determine the effort required to implement a feature. To ensure that the product is delivered on time and within budget, it is critical to prioritize features that can be implemented efficiently. 

Here’s an example of how this could work: 

Feature A will take 10 weeks to complete, while Feature B will take 5 weeks. 

You currently have your entire team available, but keep in mind that the holiday season is approaching. Will you still have the same amount of power in 10 weeks? If yes, then perhaps feature A should be prioritized; if no, perhaps feature B should be prioritized right now. 

Thinking ahead can help you avoid problems or delays that could arise if only half of your team is available in the final stages of development. 

6. Team Risk

Because there are many different people involved in product development, and everyone wants to add their two cents, team risk is another dimension to consider when prioritizing feature requests.

Developers, for example, may not take an idea rejection lightly if the reasons are not adequately explained. Other stakeholders may be disappointed that their latest brilliant idea will not be realized for very valid technical reasons. As a result, issues concerning the people who work on the product can sometimes outweigh technical risks.

7. Team Value (aka. “Eating your own dog food”)

“Eating your own dog food” is a saying in the software industry that refers to companies testing their products internally in real-world scenarios to get a sense of how their customers would use them. 

Inquiring about the value of a product from the team that created it is both quality control and good marketing. Consider this: no one knows the product better than the people who created it. So, asking everyone involved how much value they place on a potential new feature could help you decide which requests to prioritize and which to reject. 

8. Development Cost

This dimension includes the cost of developing each feature. It entails determining the resources (time, money, and manpower) needed to construct each feature. In most cases, if the estimated profit is significant, you would usually continue with the feature development. However, there may be times when a feature is too expensive to justify the effort (even if it has the potential to generate a large profit!). 

Asteroid mining, for example, has the potential to generate enormous profits, but the costs associated with carrying it out may make it prohibitively expensive to pursue right now. 

While other, more attainable features are prioritized, the asteroid mining feature request equivalent may have to take a back seat.

9. Time-to-Market

This dimension emphasizes the importance of each feature. It entails determining the time required to develop and release each feature, as well as the consequences of delaying its release.

10. Dependencies

This dimension addresses how the feature interacts with other features or functionalities of the product. Features that rely on other features or functionalities that are already prioritized higher are typically prioritized higher than standalone features. A dependency analysis, which examines the relationships between different features and functionalities, can be used to determine the dependencies associated with a feature. To ensure that the product is cohesive and functional, prioritize features that can be seamlessly integrated into it.

11. Urgency

This dimension considers how urgently the feature is required. Features that are critical to the success of the product or project or have a tight deadline are typically prioritized higher than less urgent features. Examining the project timeline, customer needs, and business objectives can help determine the urgency of a feature. It is critical to prioritize time-sensitive features to ensure that the product is delivered on time and meets the needs of the customer.

By taking these dimensions into account, product managers and teams can effectively and efficiently prioritize features and ensure they are delivering the most valuable features to users and the business. 

Popular Feature Prioritization Frameworks

Prioritizing feature requests for software development is a critical task for any software development team. Here are some tips for effectively prioritizing feature requests:

Kano Model

The Kano model is a framework for understanding and categorizing the needs and desires of customers. Noriaki Kano, a Japanese researcher, invented it in the 1980s, and it has since become widely used in product development and customer satisfaction analysis. 

The Kano model divides customer needs into three categories: 

1. Basic Needs: Customers expect these features as a bare minimum for a product or service to be considered acceptable. If these requirements are not met, the product or service will fail. Reliability, ease of use, and safety are examples of basic needs.
   
2. Performance Needs: These are features that customers are explicitly looking for in a product or service. Meeting these needs can help a product differentiate itself from competitors and increase customer satisfaction. Examples of performance needs might include speed, design, and quality.
3. Excitement Needs: These are features that customers do not necessarily expect to see, but when they do, they delight the customer and create a memorable experience. Innovative features, personalized experiences, and unexpected benefits are examples of excitement requirements.

   

Product designers and developers can prioritize which features to include in their products and services by understanding the various types of customer needs. Additionally, the Kano model assists businesses in identifying areas where they can exceed customer expectations and gain a competitive advantage. 

RICE Score Model

The RICE framework is a product development prioritization model that helps teams decide which projects or features to work on first. It takes into account four factors that are commonly used to assess a project’s potential impact: 

• Reach: The number of individuals who will be impacted by the project or feature. This includes both the size of the target market and the level of engagement or interaction with the project that users will have.
  
  
• Impact: The extent to which the project or feature will have an impact on the user or the business. Revenue generation, cost savings, customer satisfaction, and brand reputation are examples of such factors.
• Confidence: The degree to which the project or feature is certain to have the desired impact. This can be based on customer feedback, market research, or previous experience.
• Effort: The time, resources, and complexity needed to complete the project or feature. This includes both the development effort and any post-launch support or maintenance. 

The RICE framework is used to assign a score to each project or feature based on the four factors. The following is the formula for calculating the score: 

RICE Score = Reach x Impact x Confidence / Effort 

Projects or features with the highest RICE scores are prioritized first because they are expected to have the most impact with the least amount of effort. The RICE framework provides a systematic and objective approach to prioritization, assisting teams in making data-driven decisions and focusing on the most likely-to-succeed projects or features. 

MoSCoW Method

The MoSCoW method is a technique for prioritizing tasks that is used in project management, software development, and business analysis. It is a simple framework for determining the priority of requirements and features that are critical to the success of a project. 

MoSCoW is an acronym that stands for: 

• Must-Have: Essential requirements or features that must be delivered for the project to be considered a success.
• Should-Have: Important but not critical requirements or features. They can be delayed, if necessary, but they should be delivered as soon as possible.
• Could-Have: Requirements or features that are desirable but not required for the project’s success. If time and resources allow, they can be included.
• Won’t-Have: Requirements or features that aren’t part of the project’s current scope, either because they aren’t necessary or because they can be added later. 

Project stakeholders can use the MoSCoW method to prioritize requirements and features, allocate resources, and focus on delivering the most critical elements first. This helps to ensure that the project achieves its goals and provides value to the stakeholders.

Value vs. Complexity

The Value vs. Complexity framework is a software development tool for prioritizing and managing project requirements. It assists teams in assessing and evaluating each requirement along two dimensions: the potential value it adds to the project and the level of complexity involved in implementing it. 

The Value dimension refers to the value that a requirement brings to the project in terms of business value, customer value, or strategic value. The higher the value of a requirement, the more critical its implementation. 

The level of technical complexity involved in implementing a requirement is referred to as the Complexity dimension. The more complex the requirement, the more time and resources will be needed to implement it. 

Teams can prioritize their work based on the relative importance of each requirement by plotting it on a Value vs. Complexity matrix. High-value, low-complexity requirements should be prioritized first, while low-value, high-complexity requirements should be deprioritized or deferred. 

The Value vs. Complexity framework assists teams in allocating resources and focusing on delivering the most critical requirements first, all while minimizing risk and avoiding unnecessary complexity. It can also assist teams in identifying opportunities to simplify complex requirements or divide them into smaller, more manageable pieces. 

WSJF

The Weighed Shortest Job First (WSJF) framework is a prioritization model used in Agile software development and product management. It assists teams in determining the order in which to work on backlog items (such as user stories or features) based on their relative importance and urgency. 

When prioritizing backlog items, the WSJF framework takes four factors into account: 

• Business Value: The extent to which the backlog item contributes to the overall business goals and objectives.
• Time Criticality: The extent to which a backlog item is time-sensitive and must be completed within a specific timeframe.
• Risk Reduction/Opportunity Enablement: The extent to which the backlog item reduces risk or opens new opportunities.
• Job Size: The amount of time and effort required to complete a backlog item. 

The formula for calculating the WSJF score is as follows: 

WSJF Score = Business Value + Time Criticality + Risk Reduction/Opportunity Enablement / Job Size 

Teams can prioritize their work and focus on the items with the highest value and urgency by calculating the WSJF score for each backlog item. This enables teams to provide value to the business more quickly and reduces the risk of delays or missed deadlines. 

The WSJF framework is especially beneficial to teams working in a Lean or Agile environment, where the emphasis is on delivering value quickly and efficiently. It enables teams to make informed decisions and optimize their workflow by providing a structured and objective approach to prioritization. 

Cost of Delay

The Cost of Delay (CoD) framework is a decision-making tool that assists organizations in prioritizing their work by calculating the cost of delaying the delivery of a feature or project. Don Reinertsen popularized the framework in his book “The Principles of Product Development Flow: Second Generation Lean Product Development.” 

The CoD framework takes into account four factors: 

1. Value: The worth of a feature or project to the organization, its customers, or stakeholders.
2. Time criticality: The feature or project’s urgency or time sensitivity.
3. Risk reduction or opportunity enablement: The extent to which a feature or project reduces risk or opens up new possibilities.
4. Effort or cost of implementation: The effort or cost required to implement the feature or project. 

By taking these factors into account, the CoD framework enables teams to quantify the cost of delaying the delivery of a feature or project and use this information to make informed prioritization decisions. The framework also assists teams in identifying the most valuable work to prioritize and reduces the risk of delaying critical work. 

By using these frameworks, software development teams can prioritize features more effectively and efficiently, ensuring that the most valuable features are delivered to users and the business. 

How to Prioritize Software Development Feature Requests in 7 Steps 

Prioritizing feature requests for software development is a critical task for any software development team. Here are some tips for effectively prioritizing feature requests: 

1. Collect and Analyze the Requests

The first step in prioritizing feature requests is to collect all requests from various sources. Customer feedback, internal team members, stakeholders, and market research are examples of these sources. It is critical to organize the requests in a single location, such as a product backlog, to make them easier to review and prioritize. Analyze each request by evaluating its potential business value, technical complexity, development cost, and potential impact on the user experience. 

2. Evaluate Each Feature Request

Once the criteria have been established, compare each feature request to them. Score each request against each criterion and assign a weight to each criterion to reflect its importance. You can use a scoring system or a simple categorization method such as high, medium, and low priority to categorize the requests. A critical user value criterion, for example, may be given more weight than an urgency criterion. Use a spreadsheet or another tool to assist with the evaluation and scoring process. 

3. Rank the Requests

After evaluating each feature request, assign a score to each one. This order will aid in determining which features should be prioritized first. Begin with the most popular feature requests and work your way down the list. 

Various ranking methods, such as weighted scoring, cost-benefit analysis, and comparative analysis, are available. You should also define and agree on the prioritization criteria for the feature. Defining the criteria for prioritization is critical to ensuring that everyone is on the same page about the important factors for the product. User value, business value, effort, risk, dependencies, and urgency are typical criteria. To avoid future disagreements or confusion, ensure that all stakeholders agree on the criteria. 

4. Align with Company Goals

Ensure that the prioritized feature requests are in line with the overall goals and objectives of the company. Prioritize the features that are most important to achieving those objectives. 

5. Consider Time and Resource Constraints

Consider your team’s time and resource constraints. Prioritize the features that can be delivered within the time and resources available. 

6. Communicate the Priorities

After prioritizing feature requests, communicate the priorities to stakeholders such as the product owner, development team, and customer support team. Ensure that everyone is on the same page with the priorities so that the team can focus on the right features. Consider using a visual aid, such as a product roadmap, to help communicate the priorities and timeline for each feature’s delivery. 

7. Re-Evaluate and Adjust Priorities

Review and adjust feature prioritization on a regular basis based on market conditions, customer and stakeholder feedback, and the development team’s progress. 

Priorities should be established on an ongoing basis, and they can shift at any time. Periodically re-evaluate the prioritization criteria and adjust the priorities accordingly. Make sure to notify stakeholders and the development team of any changes in priorities. 

Following these steps will allow you to effectively prioritize feature requests and ensure that your team delivers the most valuable features to users and the business. 

Final Thoughts

Building new features can be exciting, but if the prioritization process isn’t up to par, it can strain the team and take the fun out of development. 

Taking into account the various dimensions of each feature request, as well as implementing a framework and evaluating the process from various perspectives, can make feature prioritization a more enjoyable experience for everyone involved. 

What criteria does your team use to prioritize feature requests? 

Benjamin Argyle-Ross A Zenkit aficionado and ardent communicator. Published on November 8, 2019, updated on March 1, 2024 · 16 min read