Common Product Prioritization Mistakes

Editor’s note: the following was written by a guest writer. If you would like to contribute to the blog, please contact ellen@productschool.com

Building a successful product isn’t about simply figuring out what to build. It also requires figuring out what to build first

Product prioritization has always been one of the hardest aspects of product management. Even with all the prioritization frameworks that have gained popularity over the past decade, such as RICE, MosCow, Kano Model, Opportunity Scoring, etc., product prioritization remains a universal challenge across organizations according to The State of Product Leadership 2020 report

Post it note

So, why is product prioritization still so hard?

The short answer is that many teams treat prioritization frameworks as cookie-cutter solutions instead of starting points. It’s like buying an off-the-shelf suit without tailoring it. It will look funky, guaranteed. 

To elaborate further, I’ll be breaking down six common prioritization mistakes that product teams make and ways to fix them.

Mistake 1: No agreed-upon scoring guide

What does an impact score of “5” mean? A 1% growth or 10%? In conversion rate or MRR? Do other teammates think the same?

Without an agreed-upon scoring guide, you can’t make an apples-to-apples comparison between initiatives. This makes prioritization pointless. To make the matter worse, it increases the likelihood of conflicts between team members, as you are essentially disguising opinions as objective decisions. 

How to fix it

Develop a shared scoring guide for your prioritization criteria. Define what each level entails with a concrete description and examples.

Here’s an example guide for determining the confidence level:

Confidence Level graph
This scale is partially inspired by Itamar Gilad


A scoring guide can be created for any prioritization method, as long as it is:

  • Specific to your product and team context
  • Objective and clear

It’s important to point out that even with a guideline, there will still be disagreements — and that’s okay. Team members should be comfortable explaining their decisions and giving feedback to others. These discussions will help your team uncover blind spots and build alignment.

Mistake 2: Mixing discovery and delivery

Software development isn’t the only thing that takes time when building a product. So do problem analysis and solution design, commonly referred to together as product discovery.

However, discovery tasks usually get either:

  • Lumped in with development work → Creates messy dependency issues.
  • Left out of the prioritization process → Introduces a selection bias from the start. In other words, you build only what you have already decided is important, but how did you decide that?

How to fix it

Divide your product development into discovery and delivery, and prioritize the two backlogs separately. This is called Dual Track Development

You can even break down discovery into problem analysis and solution design if that fits how your team works. 

Do note that having separate tracks doesn’t mean you should have separate teams. For any given project, the same team should carry out both discovery and delivery work to maximize quality and velocity. 

Discovery and Delivery graphic

Mistake 3: Recency bias

Your team will always add items to the backlog faster than it will clear them. Over time, you will build up a long backlog with items from the previous century (year). Because it’s human nature to favor shiny new ideas (a.k.a. recency bias), old items tend to get forgotten for no good reason. 

How to fix it

As new evidence emerges, situations change, and your team’s estimation skills improve, you must constantly review old items to correctly prioritize the backlog.

My recommendation is to track the “freshness” of each item. When something has not been updated for longer than X period of time, groom it again using the latest information. If it’s no longer relevant, simply kill it.

Mistake 4: Not considering constraints 

Barrier fence

Product development is inherently messy. Besides the core value-vs-cost consideration, there are also dependencies, deadlines, skill fit, strategic fit, and other constraints that influence your prioritization decisions.


No matter how ruthless you are with prioritization, you can’t simply dismiss these constraints. However, you also shouldn’t let them override your core prioritization criteria every single time. 


Teams that lack a good system to deal with these external factors often end up losing confidence in their prioritization processes altogether. 

How to fix it

Define a set of rules to work with these constraints, and make them part of your prioritization system.

Here are a few examples:

  • Time-sensitive projects → Set aside a fixed amount of resources each month to fast-track projects with non-negotiable deadlines (e.g., scheduled launch events, seasonable campaigns). Everything else will follow the regular process, even if it means not getting done at all.
  • Dependencies → A project blocked by other tasks will resume its position in the backlog as soon as the blocker is removed. However, it shouldn’t interrupt projects that have already started.
  • Strategic alignment → Assign more weight to projects that align with the company’s strategic priorities. This can be done with the Weighted Scoring method.

When you have a consistent guideline, people will trust the system, knowing that every decision is made objectively. 

Mistake 5: Over-complicating the process

Perfect prioritization does not exist.

The information you use for prioritization is simply a set of estimations, and estimations are always wrong. There is no need to treat your prioritization process like you’re planning a rocket launch. 

Prioritization is an exercise that helps you maximize your execution value. If you constantly direct more resources toward prioritization than execution, you are doing it wrong. 

Some product teams (usually at larger companies) spend months debating the relative value between small features when they could have shipped them all in the time lost.

How to fix it

Timebox your prioritization discussion. If your team gets stuck comparing initiatives, introduce a tie-breaker rule. For example, items that entered the backlog first go first. 

The point is, if you have to pull out your hair to prove that one project deserves to be worked on first, that trivial difference will not matter in the long run. Accept the slight margin of error and move on.

Mistake 6: Not iterating the prioritization system 

No one gets prioritization right the first time. 

Even if you are satisfied with your current system, there will always be room for improvement if you look hard enough.

Additionally, just because something works today doesn’t mean it’ll continue to work as the company scales. It’s dangerous to think you can create a prioritization system that requires minimal iterations. 

How to fix it

Treat your prioritization system (and other internal processes) like your product. Monitor how it’s working and iterate continuously. Because the “users” in this case are your team members, there should be an open channel for everyone to give feedback.

Generally speaking, frequent and small iterations are better than drastic revamps. However, be aware that:

  • It takes time for a new process to show its effects.
  • A new process can hurt productivity in the short term.
  • Not every problem has an easy solution.

To avoid interrupting team momentum with ad-hoc fixes, I recommend doing a quarterly or bi-yearly process review to go over all the feedback and discuss solutions as a team.

Person working

Bonus: Management interference

Having to rearrange your backlog due to management input, usually without a convincing reason, is one of the most frustrating yet common things that can happen to a product team.

It can happen for two reasons:

  1. Management believes it has the best ideas and doesn’t respect the system.
  2. A disconnect exists between company strategy and product strategy.

How to fix it

For the first scenario, there isn’t much you can do. You might want to consider how much you can really contribute and grow as a product professional in that environment.

The second scenario is fixable but complex. It arises at every company at some point. The larger the company, the worse it gets.

Such a discrepancy exists for a combination of reasons:

  • Management mistakes tactics for strategies. It dictates solutions instead of creating a direction for potential solutions.
  • Management doesn’t explain the “why” behind a strategy.
  • There is no clear process for teams to share learnings and evidence (both horizontally and vertically).
  • There is no agility in the company strategy, even when it no longer makes sense.

If you are a product leader (CPO, director, team lead, etc.), you have a critical responsibility here to bridge the gap between individual teams and senior management. Make sure to communicate information bi-directionally and fix misalignment proactively. A good way to start is by examining:

  • How are we sharing insights other teams should know?
  • Does every team have the same access to key information (ICP, positioning, data dashboard, etc.)?
  • What information does my team want to know but is out of their reach?

You might also be interested in: Prioritization for Impossible Product Decisions

To sum it up

Creating a product prioritization system doesn’t stop at applying a popular framework. Make sure you…

  • Develop an agreed-upon scoring guide
  • Separate discovery and delivery
  • Update old backlog items
  • Set rules to deal with constraints
  • Don’t make it harder than it needs to be
  • Iterate regularly

Even if you are not in a position to implement these changes, you can still apply elements of them in day-to-day work.

Don’t get discouraged if your system doesn’t improve overnight. The truth is, prioritization is counterintuitive. It’s against how human brains work. As long as you intentionally improve this craft, it’ll become your product team’s competitive advantage. 

Meet The Author

Austin Yang

Austin Yang is a Senior Product Manager at Landbot. He was previously a Growth PM at Klook, a unicorn travel startup backed by Softbank and Sequoia.

For more of his writings on product management, product-led growth, SaaS, no-code tools, and marketplaces, follow Austin on Twitter or his blog

Product School Pro

Enjoyed the article? You may like this too: