Backlog prioritisation breaks down when urgency is used as a proxy for importance. The solution isn’t a better framework — it’s a system that separates time-sensitivity from business impact, makes trade-offs explicit in the room, and protects capacity for work that no stakeholder will ever think to request.
When I was building my company’s first cross-team digital product roadmap, I inherited five separate team backlogs and no prioritisation framework for deciding what crossed team boundaries. Every team leader had a list of urgent things. None of them were wrong — from inside their workstream, the urgency was real. The problem was that urgency from five different vantage points produces paralysis, not a roadmap.
What I had to build wasn’t a prioritisation matrix. It was a prioritisation system — one that could hold up under stakeholder pressure, work across teams with different metrics and different leaders, and produce decisions that people could disagree with but couldn’t easily undermine. Here’s what that looked like.
Separate urgency from importance — they’re not the same thing
Urgency is time-sensitive: if we don’t act now, something bad happens. A regulatory deadline is urgent. A competitor shipping a feature that directly erodes your position is urgent.
Importance is impact-sensitive: if we do this, something measurably good happens. A feature that removes a conversion blocker for your highest-value segment is important. A reporting dashboard that saves one stakeholder two hours a week is less important, regardless of how loudly it’s requested.
When competing urgency claims land at the same time — and in a travel business with seasonal pressure, they always do — I ask each stakeholder two questions: what happens if this ships in six weeks instead of now? And what’s the current user or business cost of this not existing? The answers surface the actual urgency and importance far faster than any amount of priority scoring.
Use a framework to structure the conversation, not to replace it
RICE, WSJF, MoSCoW — the specific framework matters less than using one consistently. The value isn’t the score; it’s the conversation the scoring process forces. When a stakeholder says their feature is the highest priority, asking them to walk through reach, impact, confidence, and effort in concrete terms changes the nature of that claim immediately.
If you’re working in an environment where delay has a measurable cost, WSJF is worth understanding — it builds the cost of waiting directly into the priority calculation, which makes the urgency argument more rigorous and the decision more defensible.
Make the trade-off explicit — even if it happens in the room
The biggest shift in how I approach prioritisation is making the trade-off explicit. In practice, stakeholders don’t always come prepared to compare options — they come to explain why their request matters. That’s a different conversation. So part of the role is to reframe it in real time.
The framing I use is simple: “If we prioritise X next sprint, Y will move out by at least a few weeks. Is that the right trade?” That usually changes the discussion immediately.
Most stakeholders haven’t thought about backlog prioritisation as zero-sum resource allocation. They’ve thought about whether their request is justified — which can be true for multiple items at once. The decision only becomes clear when the cost of choosing one over another is made explicit. The goal isn’t to eliminate debate. It’s to anchor it in trade-offs that can actually be decided.
Protect capacity for work no stakeholder is asking for
Nobody raises tickets for technical debt. Nobody asks for platform resilience or internal tooling improvements. But that work often determines whether the features stakeholders are asking for can actually be delivered safely.
In practice, this doesn’t always come as a clean, separate allocation. A lot of it is addressed alongside feature work — improving parts of the system as we touch them, rather than waiting for a dedicated “tech debt sprint” that never quite happens. The important part is that it’s intentional. If it’s not discussed and accounted for, it gets deprioritised by default. And over time, that creates risk in the parts of the system that matter most — the ones under the most pressure.
How to build a prioritisation system that holds under pressure
A backlog where everything is urgent is a backlog without a system.
The stakeholder conversations, the scoring framework, the pre-meeting trade-off document, the protected capacity — these are the structural decisions that make prioritisation work under pressure. Build the system when the pressure is low. It’s the only time you’ll have the space to do it properly.
TL;DR
- Urgency and importance are different things — urgency is time-sensitive, importance is impact-sensitive; conflating them is where most backlog paralysis starts
- Frameworks (RICE, WSJF, MoSCoW) are valuable because of the conversations they force, not the scores they produce — use one consistently
- Making trade-offs explicit in the room changes stakeholder conversations immediately: “If we do X, Y moves out by weeks — is that the right trade?”
- Protect capacity for technical debt and platform work deliberately — nobody requests it, but it determines whether everything else can be delivered safely
- Build the prioritisation system when the pressure is low — it’s the only time you’ll have space to do it properly
Delphine Ragazzi is a Product Owner with 20 years of experience across digital analytics, CRO, and product delivery. She writes about product decisions, data, and AI at douli.com.
