How to Prioritize Your Product Backlog When Everything Feels Urgent

At some point in every product role, the backlog becomes a political document. Every item on it has a sponsor. Every sponsor believes their item is the most important thing. And you, the PM, are supposed to make a rational decision in the middle of all of it.

This is not a prioritization problem. It is a prioritization problem disguised as a relationship problem. And solving it requires both.

Why Everything Feels Urgent

The reason most backlogs feel unmanageable is not that teams have too many ideas. It is that there is no shared definition of what makes something important.

When a founder says "this is urgent," they usually mean: this is the thing I am thinking about most right now. When an engineer says "this is urgent," they usually mean: this will become significantly more expensive to build the longer we wait. When a customer says "this is urgent," they mean: I cannot do my job without this.

All three uses of the word "urgent" are legitimate. None of them is the same thing. And when you treat all three the same way, the backlog becomes a list of competing urgencies with no principle for choosing between them.

The first step in prioritizing is naming the criterion. What does the team mean by important? Not in the abstract. In the specific context of where the product is right now.

The Framework I Actually Use

I have tried most of the standard frameworks. RICE (Reach, Impact, Confidence, Effort), ICE, MoSCoW, Kano. They each have value in specific contexts. The one I return to most consistently at early stage is a simplified version of RICE, with a modification that most implementations miss.

RICE scoring works like this: multiply Reach (how many users does this affect per time period) by Impact (how much does it move the North Star for those users, rated 0.25 to 3) by Confidence (how sure are you of these estimates, expressed as a percentage), and divide by Effort (person-weeks to ship).

The modification that matters: before calculating the score, ask one pre-screening question. Is this in service of the current strategic priority, or is it adjacent to it?

In my experience, the biggest time sink in backlog prioritization is spending hours scoring items that should never have been in the scoring conversation. The founder's new idea that belongs in Q4. The customer request that is genuinely valid but only for their specific use case, not the target segment. The tech debt that is real but not blocking anything currently on the roadmap.

A simple yes/no screen before scoring eliminates most of the noise.

The Stakeholder Push Problem

The hardest part of prioritization is not choosing between good options. It is saying no to a specific person who is invested in a specific outcome and doing it in a way that maintains the relationship and leaves room for the item to be reconsidered later.

The best language I have found for this: "Here is how I am thinking about it, and here is what would need to be true for this to move up."

The second part is what most PMs skip. Telling someone their feature is not prioritized is easy to dismiss as politics or bias. Telling them what evidence or condition would change the priority gives them something to work with. It transforms "no" into "not yet, and here is the specific thing that would change my answer."

In practice, this sounds like: "The challenge is that this change affects fewer than 15% of our current users, and we are at a stage where we need the product to work well for the majority. If we see this segment grow to 30% or if the retention data for this segment drops below baseline, this moves up significantly."

That response documents the reasoning, anchors it in data, and gives the stakeholder a clear path forward.

What To Do With Tech Debt

Technical debt items belong in the backlog, but they need a different evaluation criterion than feature work. The question is not whether paying down the debt is good (it almost always is). The question is what the debt is costing the team right now, in concrete terms.

Debt that slows down shipping by 20% is a feature with a Reach of the entire team and an Impact on every item below it in the queue. Debt that is messy but not blocking anything is real but lower priority than items that directly affect user outcomes.

In my experience, engineers often undersell tech debt because they feel like they are being asked to translate a judgment call into a business case. PMs can help by asking: what would we be able to ship in the next quarter if we addressed this, that we currently cannot? Turning the debt into a capability unlocked makes it a strategic conversation rather than an engineering preference.

The Ruthless Question

For every item in the backlog, the most important question to ask is this: if we do not build this in the next 90 days, what specifically happens?

Sometimes the answer is: "Nothing, because it is genuinely optional." That item goes to the bottom.

Sometimes the answer is: "A key customer churns." That item goes to the top, and the conversation shifts to verifying whether the churn risk is real.

Sometimes the answer is: "We ship something slower next quarter." That is a tech debt conversation with a specific cost.

The items that produce no concrete answer to that question are the ones most likely to sit in the backlog for 18 months, accumulating legitimacy simply from their age. Removing them, or explicitly deferring them to a future review, is one of the most valuable things a PM can do.

What I Have Learned

Backlog prioritization is a communication skill as much as it is an analytical one. The framework gives you something to point to. The relationships determine whether anyone follows it.

The teams that prioritize well are teams where everyone, including founders, understands what the current strategic priority is and why. That understanding does not come from a prioritization framework. It comes from the conversations that happened before the framework was applied.

Get the strategic priority agreed upon first. Then let the framework do what it is actually good at: giving you a defensible, documented basis for the decisions you were probably going to make anyway.