Introduction

In the world of product management, prioritizing effectively is not just a skill, it's an art. With a plethora of possibilities at their fingertips, product managers often find themselves at a crossroads, making critical decisions that will shape the future of their products.

How does one navigate this complex landscape to ensure that the most valuable and impactful problems are solved? The answer lies partly in utilizing robust prioritization frameworks.

This article delves into seven key prioritization frameworks: MoSCoW, RICE, Kano, Value vs. Complexity, Story Mapping, Eisenhower Matrix, and Buy a Feature. Each of these approaches offers unique insights and methods to streamline the decision-making process. From the MoSCoW method's straightforward categorization to the engaging 'Buy a Feature' game, these frameworks cater to diverse needs and scenarios, providing a structured pathway to prioritize effectively.

Whether you're a seasoned product manager or just starting out in the field, understanding and applying these frameworks can significantly enhance your decision-making process. Let's explore each framework in detail, uncovering the nuances and benefits they bring.

Note: It's important to note that one should ideally not prioritize features, but instead focus on problems. However, in this article we will sometimes refer to the prioritization of features. This is because features are often more concrete and hence easier for us to grasp. If you use a framework to help prioritize features, take extra care in articulating what underlying problem (user, business) that the feature address. Some of the frameworks, like RICE or Buy a Feature, implies that we need to know the required effort in developing the solution. This might not be known for a problem, and there might be several solutions that addresses the same problem. If this is true, it might be a good idea to do two rounds of prioritization, first at the problem level and later on the solution level.

1. MoSCoW Method

The MoSCoW method is a powerful, straightforward framework for prioritizing in product management. Its simplicity lies in its acronym, which stands for Must have, Should have, Could have, and Won't have. This method helps product managers and teams focus on what's truly essential, while also considering what can be deferred or omitted.

Must have: These are non-negotiable features that your product needs to function effectively. Without these, the product or feature will likely fail. For example, in an e-commerce app, a secure payment gateway is a 'Must have' feature.

Should have: Important but not vital features fall into this category. They are not critical for launch but should be included soon after. For instance, a product recommendation system in an e-commerce app is a 'Should have' – important for enhancing user experience but not essential for basic functioning.

Could have: These are nice-to-have features that could improve user experience but are not crucial. They are typically considered only if time and resources permit. An example might be a chatbot for customer service on the e-commerce site.

Won't have: Features that are identified as the lowest priority, often because they are least impactful or because their implementation is too complex or resource-intensive relative to their perceived value.

Applying the MoSCoW method involves engaging with end users to understand their needs and expectations. It requires a clear vision of the objectives and a thorough understanding of your user base. By categorizing features into these four groups, teams can effectively manage their workload, focusing on delivering the highest value in the shortest time, while also setting clear expectations about what will not be included in the current scope of work.

Remember, the MoSCoW method is dynamic. What is a 'Should have' today might become a 'Must have' tomorrow, depending on changing market trends and customer feedback. Regularly revisiting and reassessing your priorities is key to keeping your product relevant and competitive.

The MoSCoW framework can be applied together with the Story Map framework. We'll discuss this down in the Story Mapping section (5).

2. ICE and RICE Scoring

ICE and RICE Scoring are systematic methods used by product managers to prioritize features based on quantifiable data. ICE stands for Impact, Confidence, and Effort. The R in RICE stands for Reach. These frameworks helps in making informed decisions by evaluating how each feature will contribute to the product's success.

Reach: Estimates the number of people or transactions affected by the feature in a given time period. For example, how many users will a new login feature impact per quarter?

Impact: Measures the degree of effect the feature will have on the users. It is often rated on a scale (such as minimal, low, medium, high, or massive).

Confidence: Assesses how confident you are in your Reach and Impact estimates. It helps in recognizing the level of uncertainty in your predictions, usually rated as a percentage.

Effort: Estimates the amount of work required to implement the feature, often in person-months or another consistent unit of measure.

The RICE score is calculated by multiplying Reach, Impact, and Confidence, and then dividing by Effort. This provides a numerical value that helps in comparing different features objectively.

Using RICE or ICE involves not only quantifying each component but also engaging in discussions with team members and stakeholders to align on the definitions of each factor. This ensures a shared understanding and a more accurate prioritization process. Additionally, like the MoSCoW method, RICE and ICE are dynamic and should be revisited periodically as project goals and external conditions evolve.

Weaknesses of RICE and ICE: The Challenge of Guesswork

While RICE and ICE are invaluable tools for prioritizing features in product management, they are not without their challenges. One significant weakness lies in the reliance on estimates and guesswork for their inputs – Reach, Impact, Confidence, and Effort.

Estimation Challenges

Reach: Estimating the reach of a feature can be speculative, especially for new products or features without historical data. Predictions about how many users a feature will impact often rely on market research or assumptions based on similar features or products, which may not always be accurate.

Impact: Gauging the impact of a feature on user behavior or satisfaction is inherently subjective. It depends heavily on understanding user needs and behaviors, which can be complex and ever-changing. Misjudging the impact can lead to prioritizing features that don't offer as much value as anticipated.

Confidence: The confidence rating is a meta-estimate – an estimate about how accurate your other estimates are. This introduces another layer of subjectivity and potential bias. Overconfidence in estimates can skew the prioritization process, leading to unrealistic expectations.

Effort: Estimating effort is notoriously difficult, especially in software development where unforeseen technical challenges can significantly increase the time and resources needed. Underestimating effort can result in resource allocation issues and project delays.

Mitigating Guesswork

To mitigate these challenges, product managers can take several steps:

Data-Driven Approach: Wherever possible, use data to inform estimates. Historical data, user research, and analytics can provide a more solid foundation for these predictions.

Regular Reviews: Regularly review and adjust estimates as more information becomes available, especially after initial phases of development or user testing.

Stakeholder Engagement: Involve diverse stakeholders in the estimation process. Different perspectives can help balance biases and provide a more rounded view.

Incremental Development: Adopting an agile or incremental approach allows for testing and learning, which can validate or refute initial estimates and inform future prioritization.

Despite these challenges, RICE and ICE remain valuable for their structured approach to decision-making. By acknowledging and addressing the inherent guesswork in their application, product managers can use these frameworks more effectively to prioritize features that truly align with their product goals and user needs.

3. Kano Model

The Kano Model, developed by Professor Noriaki Kano, is a unique framework in product management for prioritizing features based on customer satisfaction and delight. It categorizes features into five distinct groups: Must-Be, Performance, Excitement, Indifferent, and Reverse, offering a nuanced approach to understanding how different features impact customer experiences.

Must-Be Features: These are the basic features that customers expect as a given. They won't necessarily increase customer satisfaction if present, but their absence will lead to dissatisfaction. For example, in a car, the expectation is that it should have wheels.

Performance Features: These features are directly correlated with the level of customer satisfaction. The better these features are, the higher the satisfaction. For instance, the fuel efficiency of a car is a performance feature.

Excitement Features: Also known as delighters, these features can significantly boost customer satisfaction, even though customers may not explicitly demand them. An example could be an advanced infotainment system in a car.

Indifferent Features: These are features that do not significantly affect customer satisfaction or dissatisfaction, regardless of whether they are present or not.

Reverse Features: These features, when present, may lead to customer dissatisfaction. They are typically features that some customers do not want.

Here is a fantastic video courtesy of Expert Program Management explaining the Kano Model, and how to use it in Product Management.

Strengths and Weaknesses:

The strength of the Kano Model lies in its focus on customer satisfaction and delight, encouraging innovation and the creation of features that can differentiate a product in the market. However, it does have its limitations:

Subjectivity in Categorization: Determining which category a feature falls into can be subjective and may require significant customer research.

Dynamic Nature of Categories: Over time, excitement features can become performance or even must-be features as customer expectations evolve. This requires continuous reassessment of features.

Resource Allocation: The model doesn’t directly address the effort or cost associated with developing each feature, which can be a critical consideration in prioritization.

Application of the Kano Model:

To effectively use the Kano Model, product managers should engage in continuous customer feedback and research to understand their evolving needs and preferences. This can be done through surveys, user testing, and market analysis. Prioritizing features using the Kano Model involves a balance between satisfying basic customer needs, improving key functionalities, and introducing innovative features that can create customer delight and set the product apart in the market.

4. Value vs. Complexity Matrix

The Value vs. Complexity Matrix, also known as Impact vs. Effort Matrix, is a strategic tool used in product management to evaluate and prioritize features based on two key dimensions: the value they provide to the customer or business, and the complexity involved in implementing them. This matrix helps in making informed decisions by visually plotting features against these two critical axes.

How It Works:

Value Axis: This measures the benefits or value a feature brings to the user or the business. Value can be determined through various factors like user demand, potential revenue, strategic alignment, or competitive advantage.‍

Complexity Axis: This represents the difficulty or resource requirements for implementing a feature. Complexity can include technical challenges, time to develop, cost, and resource availability.

Four Quadrants of the Matrix:

High Value, Low Complexity (Quick Wins, upper left): These features are highly desirable as they provide significant value with relatively little effort. Prioritizing these features can lead to quick gains and positive impacts on user satisfaction or business goals.

High Value, High Complexity (Major Projects, upper right): These are important features that require substantial resources and time. They need careful planning and consideration of ROI to justify the investment.

Low Value, Low Complexity (Fill-Ins, bottom left): While these features are easy to implement, they offer limited value. They are often lower in priority but can be useful for filling in gaps or minor enhancements.

Low Value, High Complexity (Thankless Tasks, botton right): Features that fall into this quadrant are typically avoided or postponed, as they require significant effort for little reward.

Strengths and Limitations:

The strength of this matrix lies in its straightforward visual representation, aiding in quick and clear decision-making. It also encourages a balanced view of both the benefits and the costs associated with implementing features.

However, there are limitations:

Subjectivity in Assessing Value and Complexity: Estimating the value and complexity can be subjective and may vary among team members and stakeholders.

Dynamic Market and Technological Changes: The categorization of features can change over time due to market trends and technological advancements, requiring regular reassessment.

Application of the Matrix:

Using the Value vs. Complexity Matrix involves collaborative discussions with team members and stakeholders to assess each feature. It's important to gather diverse perspectives to accurately place features in the matrix. Regular reviews are essential to adjust to changes in the business environment or user needs. This matrix serves as a dynamic tool, guiding product managers in making strategic decisions about which features to develop, prioritize, or set aside.

5. Story Mapping

Story Mapping is a user-centric framework used in product management for organizing and prioritizing features. Developed by Jeff Patton, it focuses on creating a visual story of the user's journey with a product, helping teams understand and prioritize features based on how they fit into the overall experience.

Creating a Story Map:

User Activities and Tasks: Begin by identifying the key activities users perform with the product. Break these activities down into smaller tasks or steps to create a detailed view of the user journey.

Arrangement in Sequence: Arrange these tasks in the order in which they occur or in a logical sequence from the user’s perspective.

Prioritization: Once the tasks are laid out, start the prioritization process. Identify the minimum viable product (MVP) - the most basic version of your product that still delivers value. The MVP includes tasks that are critical for the user journey.

Tip: You can combine the MoSCoW prioritization framework with the Story Map to help with prioritizing tasks. By adding rows beneath the Story Map representing the four MoSCoW categories you can more easily sort the tasks into Must haves, Should haves, and so on. This will replace the Iterations and Releases section below.

Iterations and Releases: Beyond the MVP, organize additional tasks into releases or iterations. This helps in planning the development of features in a way that continuously enhances and builds upon the user experience.

Strengths and Limitations:

User-Centric Approach: Story Mapping keeps the focus on the user experience, ensuring that the product is developed from the user’s perspective. This helps in creating a more intuitive and satisfying product.

Visualization: It provides a clear visual representation of the product and its features, making it easier for teams to understand the scope and the relationship between different parts of the product.

However, there are challenges:

Complexity with Large Products: For very large or complex products, the story map can become overwhelming, making it difficult to maintain a clear overview.

Dynamic Nature of User Needs: User needs and behaviors can change, necessitating regular updates and revisions to the story map.

Application of Story Mapping:

To effectively use Story Mapping, product managers should involve cross-functional teams, including UX designers, developers, and marketers, in the mapping process. Regularly updating the story map based on user feedback and market changes is crucial. It's also beneficial to use this tool in conjunction with other frameworks like MoSCoW or RICE for a more comprehensive prioritization strategy.

6. Eisenhower Matrix

The Eisenhower Matrix, also known as the Urgent-Important Matrix, is a time management tool that can be effectively adapted for feature prioritization in product management. It helps in categorizing tasks or features based on their urgency and importance, aiding product managers in focusing on what truly matters.

Four Quadrants of the Eisenhower Matrix:

Urgent and Important (Do First): These features have immediate deadlines and significant impact on the project. They are critical for the success and should be tackled first.

Important but Not Urgent (Schedule): Features that are important for the product's long-term success but do not require immediate action fall in this category. They should be planned and scheduled appropriately.

Urgent but Not Important (Delegate): These are tasks that need quick attention but may not significantly contribute to the overall product goals. If possible, these tasks should be delegated.

Neither Urgent nor Important (Eliminate): Features or tasks that are neither urgent nor important should be reconsidered or eliminated, as they do not contribute effectively to the product's progress or success.

Strengths and Limitations:

Simplicity and Clarity: The matrix’s simple format makes it easy to understand and apply, providing clear guidance on what to prioritize.

Focus on Critical Tasks: It emphasizes focusing on important tasks, preventing the common pitfall of only addressing urgent but less important features.

However, the Eisenhower Matrix also has its limitations:

Subjective Categorization: Determining what is urgent and important can be subjective and may vary among team members and stakeholders.

Dynamic Prioritization Needs: The urgency and importance of features can change over time, requiring constant review and adjustment of the matrix.

Application in Product Management:

In the context of product management, the Eisenhower Matrix can be used in conjunction with other prioritization frameworks to ensure a well-rounded approach. Regular team meetings to review and update the matrix can help keep everyone aligned and focused on the most critical features. It’s particularly useful in agile environments where priorities can shift rapidly.

7. Buy a Feature

"Buy a Feature" is a gamified approach to feature prioritization that actively involves stakeholders in the decision-making process. It is particularly useful in generating engagement and understanding the perceived value of different features from the perspective of users or stakeholders.

How It Works:

Feature List and Pricing: First, create a comprehensive list of potential features. Assign a hypothetical 'price' to each feature, reflecting its value or the effort required to implement it.

Stakeholder Budgets: Provide stakeholders with a fixed amount of hypothetical 'money' they can spend on features.

Feature Auction: Stakeholders 'buy' features by allocating their budget to the features they consider most important or desirable.

Analysis: After the 'buying' process, analyze which features received the most funding. This indicates the features stakeholders value the most.

Strengths and Limitations:

Stakeholder Engagement: This method provides a direct and interactive way to involve stakeholders, ensuring their voices are heard in the prioritization process.

Real-World Insights: It offers valuable insights into what users or stakeholders consider most valuable, potentially uncovering priorities the product team may not have considered.

However, there are some drawbacks:

Biased towards Familiar Features: Stakeholders might lean towards features they understand or are familiar with, potentially overlooking innovative or complex features that could be more beneficial in the long run.

Gamification Bias: The game-like nature of the process might influence stakeholders to make choices that are more strategic than reflective of their true priorities.

Application in Product Management:

To effectively use "Buy a Feature," it's crucial to set clear guidelines and provide sufficient information about each feature to ensure informed decisions. It's often beneficial to use this method in conjunction with more analytical frameworks like RICE or MoSCoW to balance subjective preferences with objective data. This method works well in workshops or group settings where direct interaction and discussion are possible.

UX for the Masses offers templates to get started playing the Buy a Feature game here.

Summary: Navigating the Landscape of Prioritization Frameworks

The various frameworks offer distinct pathways for prioritizing features. While each framework has its unique approach and focus, there are notable similarities and disparities among them.

Similarities Across Frameworks:

Focus on Value and Impact: Frameworks like RICE, Value vs. Complexity, and the Kano Model emphasize assessing the impact and value of features, whether it's in terms of user satisfaction, business goals, or a balance of both.

Stakeholder Involvement: Methods like the MoSCoW Method and "Buy a Feature" highlight the importance of involving stakeholders in the decision-making process, ensuring that priorities align with user needs and business objectives.

Dynamic Nature: Most frameworks, including Story Mapping and the Eisenhower Matrix, acknowledge the dynamic nature of product development. They require regular reassessment and adjustments based on changing circumstances and new information.

Disparities Among Frameworks:

Quantitative vs. Qualitative: The RICE and ICE methods rely heavily on quantifiable data, whereas frameworks like the Kano Model and "Buy a Feature" are more qualitative, focusing on user satisfaction and stakeholder opinions.

User-Centric vs. Business-Oriented: The Kano Model and Story Mapping are deeply user-centric, prioritizing features based on user experience and journey. In contrast, frameworks like RICE and the Eisenhower Matrix can be more aligned with business-centric priorities, like resource allocation and urgency.

Complexity of Application: Some frameworks like the Value vs. Complexity Matrix and MoSCoW are relatively straightforward and easy to implement. Others, such as the Kano Model and Story Mapping, require more in-depth analysis and ongoing adjustment.

Three main groups:

Data-Driven Decision Making: RICE and ICE are closely aligned in their use of quantitative measures for prioritization.

User Experience Focus: The Kano Model and Story Mapping share a common ground in emphasizing the user's perspective and journey.

Stakeholder Engagement and Simplicity: The MoSCoW Method and "Buy a Feature" both involve stakeholders directly but differ in their approach, with "Buy a Feature" adding a gamification element.

In conclusion, the choice of framework(s) depends on specific needs, team dynamics, and the balance between user needs and business objectives. Product managers often benefit from combining elements of multiple frameworks to create a comprehensive, adaptable prioritization strategy that best fits their unique context.