How to Prioritize When Everything Is Urgent
Here’s the reframe that changes how you handle this: how to prioritize when everything is urgent isn’t really a prioritization question at all. “Everything is urgent” is not a prioritization problem. It’s a communication problem that’s been allowed to become a prioritization problem.
When every request lands as urgent, it usually means one of two things. Either urgency is being used as a negotiating tactic (stake your flag loudly enough and your request jumps the queue) or the team genuinely has no shared framework for what actually matters this quarter, so everyone’s filling that vacuum with their own judgment.
Both are fixable. But you won’t fix them by getting better at prioritization frameworks. You fix them by having a different conversation with your stakeholders. The teams that struggle most with this aren’t lacking a framework — they’re lacking a shared definition of what “matters” means this quarter, and no scoring model fixes that gap on its own, no matter how many decimal places you add to the formula.
Why Everything Feels Urgent (And Why That’s Yours to Solve)
When a sales rep calls something urgent, they usually mean: “This is blocking a deal I care about.” When a customer success manager calls something urgent, they mean: “This customer is unhappy, and I’m the one on the call with them.” When a founder calls something urgent, they mean: whatever they’re focused on right now.
None of those is wrong. They’re all legitimate from inside that person’s perspective. The problem is that “urgent” from inside a perspective isn’t the same as “should be prioritized above what we’re currently building.”
The PM’s job is to hold the full picture. Nobody else in that conversation has the context to do it. When you accept urgency at face value and keep reshuffling the backlog in response to whoever pushed hardest last, you’re not prioritizing; you’re just managing incoming pressure.
This pattern shows up most clearly on teams without a designated PM, where whoever escalated most recently effectively set the roadmap for the week. It’s not usually a malicious dynamic. It’s just what happens when nobody is explicitly responsible for holding the line between “loud” and “important.” The fix isn’t a better spreadsheet. It’s someone in the room whose job is to say “here’s why not,” out loud, and mean it.
The cost of saying yes to every stakeholder request is real and cumulative. Every reactive priority shift has a cost: context switching, scope confusion, and team morale from constant direction changes. A rough rule of thumb worth tracking: every unplanned mid-sprint priority swap costs a team about half a day of pure context-switching overhead once you count the ramp-down on the old task and the ramp-up on the new one. That cost often doesn’t show up until the retrospective, by which point it’s too late to avoid it.
The Prioritization Frameworks PMs Actually Use
Prioritization Method Comparison
| Method | Best For | Weakness | When to Use |
|---|---|---|---|
| RICE (Reach × Impact × Confidence ÷ Effort) | Comparing features with similar user impact | Confidence scores are subjective; easy to game | Mid-stage teams, feature backlogs |
| ICE (Impact × Confidence × Ease) | Fast, lightweight sorting | Too simple for high-stakes decisions | Early stage, quick triage |
| MoSCoW (Must/Should/Could/Won’t) | Scoping a single release or sprint | Doesn’t help compare across releases | Sprint planning, release scope |
| Value vs. Effort matrix | Cross-functional buy-in conversations | Effort is often underestimated | Stakeholder workshops |
| Opportunity scoring (Ulwick) | Outcome-focused discovery | Complex to set up; needs good data | Teams with mature research practices |
The truth: most PMs use a combination of RICE and gut. RICE was built at Intercom specifically to make reasoning visible rather than to produce a perfect number, so stakeholders can challenge the inputs rather than just disagree with the output. If you haven’t run a full RICE scoring model pass on your backlog before, it’s worth doing once even just to see where your gut instinct and the math disagree, since that gap is usually where the real argument is hiding.
What the frameworks don’t solve: they assume you’ve defined what “impact” means relative to a goal. If there’s no agreed-upon objective for the quarter, the same feature gets different RICE scores depending on who’s filling out the spreadsheet. Lenny Rachitsky has made a similar point in his writing on prioritizing a roadmap: the framework only produces a trustworthy ranking once the inputs feeding it are shared and agreed on, not just plugged in by whoever got to the spreadsheet first.
How to Prioritize When Everything Is Urgent: A Step-by-Step
Step 1: Get to a shared objective first. Before you can prioritize competing urgent requests, you need a shared definition of what this quarter is for. If you have OKRs, use them — and if your OKRs keep getting overridden by whoever’s loudest that week, that’s a sign the OKR process itself needs a trust repair, not just a prioritization fix. If you don’t have OKRs yet, define the objective with leadership: “What’s the one thing that, if we get it right this quarter, would be unambiguously good for the business?” That answer becomes your filter.
Step 2: Classify requests as “serves the objective” or “doesn’t.” This alone cuts through most of the urgency noise. A sales request might be genuinely urgent, but if it doesn’t serve the quarter’s objective, the honest answer is: “We can get to this in Q3 — here’s what we’re focused on now and why.”
Step 3: For requests that DO serve the objective, use a lightweight framework to rank them. RICE if you have data. Value vs. effort matrix if you need stakeholder buy-in. Don’t overcomplicate it — the framework is a communication tool as much as a decision tool.
Step 4: Separate urgent from important. Urgent is time-sensitive. Important is high-impact. Most things that get called urgent are actually neither; they’re high-salience (they’re on someone’s mind right now). If a request is genuinely time-sensitive (a contractual deadline, a live production issue affecting retention), it might legitimately jump the queue. If it’s just being called urgent, it doesn’t. A useful gut check: ask what specifically breaks, and for whom, if this waits two weeks. If the honest answer is “nothing breaks, someone’s just annoyed,” you have your answer.
Step 5: Make the trade-off visible. “If we do X, Y gets pushed by two weeks.” Always name what’s being displaced. This is the most powerful tool you have, and most PMs underuse it. Stakeholders who are told something else is being delayed to accommodate their request often de-escalate their urgency fast.
This step alone changes outcomes more than any framework does on its own. Take a stakeholder who’s been pushing for a “quick” reporting tweak every sprint for two months: the moment a team starts naming the specific thing it would displace, usually a piece of onboarding rework already in flight, the requests tend to slow from weekly to roughly monthly. Nothing about the underlying need changed. What changed was that the cost became visible instead of invisible.
The Conversation You Have to Have With Stakeholders
The conversation most PMs avoid is the one where you tell a stakeholder directly that their “urgent” request isn’t going to be prioritized this sprint — and explain why.
The avoidance is understandable. It’s uncomfortable. The stakeholder might escalate. But the alternative, perpetually reshuffling to avoid confrontation, is worse. Teams that work in constant reactive mode burn out. And eventually, nothing ships because the backlog is in a perpetual state of churn, with every item half-started and nothing carried through to done.
The framing that works: “I hear that this is important to you. Here’s what we’re committed to delivering this quarter and why — [one sentence]. If we add this, here’s what moves out — [one thing]. Which do you want?” You’re not saying no. You’re making the trade-off real.
One workable version of this: a simple rule that any request displacing in-sprint work requires a written one-liner from the requesting stakeholder explaining what they’d accept delaying in its place. The urgent requests tend to get a lot quieter, not because people stop caring, but because being explicit about trade-offs changes how urgency gets deployed. Teams that adopt this typically see mid-sprint escalations drop from three or four a week to maybe one within a matter of weeks, and the one that remains is usually a genuine production issue, not a loud opinion.
Pitching effectively to leadership is the complement to this: when you do take something to leadership, you need the same clarity about trade-offs. “I’m proposing we do X” needs to come with “which means Y is pushed to next quarter, and here’s why that’s the right call.”
Where Prioritization Frameworks Break Down
Frameworks don’t work when the inputs aren’t shared. A RICE score is only useful if everyone agrees on what “reach” means. If engineering defines reach as “users who could theoretically use this” and product defines it as “users who’ve expressed this need,” you’ll get different scores, and the framework becomes a source of argument rather than alignment. Recovery: write down the definition of each input variable before anyone scores anything, and put it somewhere everyone can see it during the session, not after the disagreement starts.
They also break down when the team is at feature zero, meaning early enough that there’s no usage data, retention data, or meaningful user base to measure impact against. In that context, you’re making judgment calls, and pretending otherwise by dressing them up in a scoring model doesn’t help. Recovery: name it as a judgment call explicitly, and revisit the decision on a fixed date once you do have data, rather than letting the “temporary” judgment call quietly become permanent policy.
And they break down when organizational dynamics override the output. If leadership is going to override the framework whenever they don’t like the result, running the framework is theater. This isn’t just an abstract risk. Harvard Business Publishing’s research on what it calls the “urgency trap” found that teams under constant time pressure default to reactive decisions precisely because nobody built in space to challenge the loudest voice in the room. The honest conversation to have at that point is about decision rights, not prioritization methods.
How to Know If Your Prioritization Is Working
The signal isn’t whether you have a clean backlog. It’s whether the thing you shipped last quarter actually moved the metric you were targeting. A tidy Jira board tells you the team is organized. It tells you nothing about whether they were organized around the right things.
If you’re consistently shipping features that don’t move metrics, either you’re solving the wrong problems (a discovery issue) or you’re shipping the right solutions to the wrong problems (a prioritization issue). Both look the same from the outside. The diagnostic is: did we ship what we said was the highest priority, and did it do what we expected? Teams avoid this diagnostic for months at a time because the honest answer is uncomfortable — it’s easier to blame the market than to admit the backlog was never actually ranked by what mattered.
A product metrics dashboard reviewed regularly, not just post-launch, is the feedback loop. Priority decisions without outcome tracking are just opinions with a spreadsheet attached.
The question to answer this week: look at your top three “urgent” requests sitting in the backlog right now. For each one, ask: Does this serve the objective we’ve committed to this quarter? If the answer is no for all three, you don’t have a prioritization problem. You have a stakeholder expectation problem, and that’s where you need to spend your energy.
References
