When everything is ‘high priority’: How PMs actually decide what gets done

Introduction

If you’ve spent even a few months managing a project, you’ve probably heard this countless times:

“This is high priority. Can we deliver it by tomorrow?”

The tricky part? It’s rarely just one request. It’s multiple stakeholders, each with their own version of “urgent,” all competing for the same team bandwidth.

And somewhere in the middle of all this, you’re expected to make the call – what actually gets done first.

At some point, everything becomes “high priority.” And when everything is high priority, nothing really is.

Over time, I’ve realised that prioritisation isn’t about tools, frameworks, or even Agile ceremonies. It’s about making trade-offs visible and forcing clarity where there is none.

Let me walk through how this plays out in real projects.

The Illusion of Priority

In one of my recent projects, we were dealing with:

• A production issue escalated by the client
• A new feature request from the business team
• A compliance-related change with a fixed deadline
• An internal push to reduce technical debt

Each of these came with the same label: URGENT.

If we had tried to treat all of them equally, the team would have been stuck context-switching, delivery would slow down, and ironically, nothing would get delivered on time.

That’s when it becomes clear: Priority is not what people say – it’s what we choose to act on.

Step 1: Convert “Urgent” into Impact

The first shift is simple: stop accepting “priority” at face value.

Instead, I ask:

• What happens if we don’t do this now?
• Who is impacted?
• Is there a revenue, user, or compliance risk?
• Is this blocking something else?

In the example above:

• The production issue had a direct user impact
• The compliance change had a non-negotiable deadline
• The feature request was important but not time-critical
• Tech debt was valuable but not immediately visible to stakeholders

Once you translate urgency into impact, the noise starts to fade.

Step 2: Make Trade-offs Explicit (Not Silent)

One mistake I made earlier in my career was trying to “adjust things internally” without involving stakeholders.

It never works.

Now, I make trade-offs explicit. For example:

“We can prioritise the new feature in the current sprint, but that will push the compliance change by a week. Are we okay with that?”

Suddenly, the conversation shifts:

• From “everything is urgent”
• To “what are we willing to delay?”

And that’s where real prioritisation begins.

Step 3: Align on One Source of Truth

Another common challenge is fragmented priorities:

• Client says one thing
• Internal leadership says another
• Tech team is optimising for something else

In one project, we were juggling multiple priority lists across emails, calls, and Jira tickets. The result? Constant confusion.

We fixed this by:

• Maintaining a single prioritised backlog
• Reviewing it weekly with all key stakeholders
• Ensuring everyone signs off on the order

This reduced back-and-forth significantly. More importantly, it removed ambiguity for the team.

Step 4: Protect the Team from Priority Noise

One thing I strongly believe in: The team shouldn’t feel the chaos of prioritisation – the PM should absorb it.

If every stakeholder pushes tasks directly as “urgent,” you lose control of execution.

In one situation, developers were getting pinged directly by multiple stakeholders. Everything felt urgent to them, and they kept switching tasks mid-way.

We fixed this by:

• Creating a single intake channel
• Routing all requests through PM/Product
• Shielding the team from ad-hoc escalations

The result? Better focus, fewer context switches, and faster delivery.

Step 5: Accept That You Can’t Please Everyone

This is probably the hardest lesson.

No matter how well you prioritise:

• Someone will feel their request was delayed
• Someone will question your decision
• Someone will escalate

And that’s okay.

Prioritisation is not about making everyone happy. It’s about making the best possible decision with the information available.

A Practical Framework I Use

Over time, I’ve started using a simple mental model:

1. Impact – Who/what is affected?
2. Urgency – Is there a real deadline or just perceived urgency?
3. Effort vs Value – Is it worth the investment right now?
4. Dependencies – Is something blocked because of this?

You don’t need a complex scoring system – just enough clarity to guide decisions.

Final Thoughts

In most projects, prioritisation is less about frameworks and more about conversations.

It’s about:

• Asking the right questions
• Forcing clarity
• Making trade-offs visible
• And standing by your decisions

Because at the end of the day, a PM’s role isn’t just to manage tasks – it’s to bring clarity to chaos and enable focused execution.

And that only happens when we stop treating every request as urgent – and start treating prioritisation as a deliberate, transparent decision-making process.