Do Product Prioritization Frameworks Work in the Real World?

For me, the last month of the year has always meant catching up with friends and family who come back home for the holidays. A lot of these traveling peer groups work in technology and are leaders in the foremost organizations in the world. This means some amazing conversations on trends, innovation, work cultures, and, of course, product management. In almost all the interesting product conversations that we have, the one thing that notoriously turns up in some shape and form is the ‘P’ word, ‘prioritization’ or product prioritization frameworks. 

What are Product Prioritization Frameworks?

In product management, the process of determining the order in which features, improvements, or projects should be addressed or implemented is called product prioritization. And it is often done using one or more product prioritization frameworks. 

Product teams get inputs from business leadership, customers, market research, data analytics, compliance regulators, tech teams, and other stakeholders. They are called upon to deliver to everyone’s expectations. The ethos of a product role is balancing inputs from different stakeholders to make informed decisions about the product’s development. 

Types of  Product Prioritization Frameworks

Without prioritization frameworks, the product roadmap usually turns into a never-ending buffet where every feature is labeled as “all-you-can-eat,” and stakeholders start treating it like a food fight.” Every aspiring or working product manager will tell you that there is a truckload of literature on product prioritization frameworks. To name a few:

• RICE/ ICE scoring
• MoSCoW
• Kano Model
• Weighted Shortest Job First (WSJF)

These product prioritization frameworks are used to make prioritization decisions by classifying opportunities (or features) according to some measurable parameters. Once you’ve assigned prioritization scores, you can arrange your feature list accordingly, giving higher priority to those with the highest scores and tackling them first, while lower-scoring items are addressed later.

This process, especially imagining one well-organized spreadsheet, allows for the swift scoring of numerous features. It sounds magical, doesn’t it? However, I must admit that I don’t advocate for these frameworks. In reality, they often guide teams toward a form of prioritization facade – creating the appearance of assistance but frequently falling short of delivering meaningful results in most cases. So much so that one of my colleagues, who is an ex-MAANG, said that product role candidates with too much framework talk in interviews were succinctly filtered out. 

What are the Constraints for Using Product Prioritization Frameworks?

1. Complexity and Overhead

Some product prioritization frameworks can be complex and time-consuming to implement. Teams may find themselves spending more time on the process than on actual product development, leading to a decrease in productivity.

Example: Using the MoSCoW method, which categorizes features into must-haves, should-haves, could-haves, and won’t-haves. The complexity arises when teams struggle to differentiate between “should-haves” and “could-haves,” leading to time-consuming debates and potential confusion.

2. Lack of Flexibility

Product prioritization frameworks are often rigid and may not easily adapt to rapidly changing project requirements or market conditions. In fact, this lack of flexibility can hinder a team’s ability to respond quickly to emerging opportunities or challenges.

Example: The Kano Model, which classifies features into basic, performance, and excitement categories. However, this model may lack flexibility when faced with rapidly changing market demands, making it challenging to adapt and prioritize new, unexpected requirements effectively.

3. Subjectivity

Product prioritization frameworks often involve subjective judgments and input from various team members. Thus, this subjectivity can lead to biases or disagreements, potentially resulting in decisions that may not align with the overall goals of the project.

Example: Using the RICE scoring system (Reach, Impact, Confidence, Effort). The subjective nature of assigning confidence levels and impact scores can introduce biases, as different team members may interpret and assess these factors differently.

4. Overemphasis on Data

While data-driven decision-making is crucial, relying solely on prioritization frameworks may neglect valuable insights gained from qualitative research, user feedback, or the experience and intuition of stakeholders.

Example: The Weighted Scoring Model, where features are scored based on predefined criteria and weighted values. This approach may overlook valuable qualitative insights or user feedback, as it heavily relies on quantitative data, potentially leading to a lack of innovation.

5. Risk of Analysis Paralysis

Teams may become overwhelmed with the multitude of criteria and factors involved in some prioritization frameworks, leading to analysis paralysis and an inability to make timely decisions.

Example: Using the ICE prioritization framework (Impact, Confidence, Ease). Moreover, teams may become paralyzed by the multitude of criteria, especially when struggling to assess confidence levels accurately, delaying decision-making and hindering progress.

The Biggest Challenge of Product Prioritization Framework

Arguably, the biggest concern that I have experienced with these frameworks is a mindset problem. Product prioritization frameworks encourage a bottom-up approach, focusing on feature lists. Now, it is so easy to get lost in the barrage of product backlog, circumstantial problems, and tactical measures, leading to a narrow outlook in product building. A short-term/ narrow focus, neglecting strategic, complex initiatives that contribute to long-term product success. This leads to what one of the leaders I work with often says, ‘missing the woods for the tree’. 

In reality, prioritization begins with objectives, strategy, market problems, and user scenarios. When dealing with features (i.e., implementation specifics), a significant prioritization process has already occurred. Any crucial features should inherently carry importance without complex calculations.

How Does Prioritization Actually Happen? 

In product teams without a formal framework, prioritization often involves open discussions and collaboration. Team members share their perspectives on what needs attention based on customer feedback, business goals, and market trends. It’s a mix of intuition, experience, and a collective understanding of priorities. 

Urgent issues and high-impact opportunities take precedence. Regular communication keeps everyone aligned. In fact, this informal approach allows for flexibility and quick adjustments as circumstances change. While it may lack the structure of a formal framework, this method relies on the team’s shared vision and responsiveness to guide decisions and keep the product on the right track.

And still, how often are business-led product decisions inexplicable? Do you feel that leadership teams enforce certain prioritizations without due consideration of the on-ground reality? 

The Biggest Benefit of Product Prioritization Frameworks

Having discussed the shortcomings of the frameworks, they do have a benefit. An advantage of using prioritization frameworks lies in their ability to communicate why certain ideas should not be pursued. When stakeholders, particularly seniors, propose ideas or seek product changes, a prioritization framework can serve as a communication tool. Additionally, it helps explain to stakeholders the reasons behind deprioritizing their suggestions. 

For example, consider the Eisenhower Matrix, a product prioritization framework that categorizes tasks based on urgency and importance. By recognizing and deprioritizing the not urgent, not important tasks, teams can avoid investing time and resources in non-essential or low-value tasks, ensuring a more focused and impactful product development process.

However, it’s essential to recognize that the framework is more of a communication tool than a decision-making one. Additionally, if product teams are fully empowered, they should be capable of justifying their prioritization decisions without having to debate every idea that didn’t make the cut. ‘Empowered product teams’, well, that is a topic for another day.

NOTE: The views expressed in this article are those of the author and not of Emeritus.

Write to us at content@emeritus.org