When everything feels urgent, no framework saves you. The team is overwhelmed, the stakeholders are competing, and the prioritisation matrix that worked last quarter just produces a tie.
The skill in those moments isn't picking a better framework. It's reading what's actually time-sensitive versus what's just been packaged as urgent.
Most things that feel urgent aren't. The ones that actually are have a different shape, and learning to recognise that shape is most of the prioritisation job in a real startup.
What urgency actually looks like
Real urgency has three properties. The thing breaks if it doesn't get done now. The cost of waiting is concrete. And the window to act is narrow.
A few examples that pass:
A deal is closing this week and the customer needs feature X to sign. Wait two weeks, the deal is dead.
A regulatory deadline is two months away. Miss it, the company has a legal exposure.
The product is failing for a key segment of users right now. The data is showing churn we can quantify, every week we don't fix it costs us users we can name.
These are urgent. They have a clock. The cost of waiting is specific.
Most things that feel urgent fail at least one of these tests. They're important — sometimes very important — but they don't degrade with time the way real urgency does. The exec who wants the new feature soon. The competitor who launched something. The internal stakeholder who's been pushing for months. All of these can wait two more weeks without anything actually breaking.
Calling them urgent is what makes them urgent. The framing creates the pressure.
What's actually happening when everything feels urgent
Three patterns that produce universal urgency:
The team has too many committed priorities. If the strategy says we're focused on three things, and the roadmap is full of work for all three plus five others, every individual ask gets defended as urgent because there's no clear ranking. The team feels constantly behind because they're trying to ship five priorities with three priorities' worth of capacity.
The stakeholders haven't been told no. Each stakeholder believes their request is in the queue. Nothing has been explicitly declined. So everyone is operating on the assumption that their thing is going to get done — they just want to know when. Every "when" question turns into a fight because the implicit answer (most of these aren't actually going to happen) hasn't been said out loud.
The team is solving symptoms, not causes. The same kind of fire keeps appearing. The team keeps reacting to it. The reaction work feels urgent because the fires are real. But the underlying cause never gets fixed because all the time goes to reacting. So the fires keep coming. The team is busy and not making progress.
How to actually decide
When everything feels urgent and you need to pick:
Sort by what genuinely degrades. Out of the list of "urgent" things, which ones actually get worse if you wait two weeks? Three? Most of them don't. The ones that do are the urgent ones. Everything else is important and asking for the urgent badge.
Look at the consequence cone. If you don't do this, what happens? Be specific. "We lose this customer" is concrete. "Our reputation suffers" is vague. The vague consequences usually don't survive scrutiny — and the things behind them aren't the ones to drop everything for.
Pick the one that buys the most future capacity. Some work, when finished, eliminates a class of problems. Other work, when finished, sits there. Under pressure, prefer the work that frees the team. It feels indirect. The team that does this consistently has more capacity in three months than the one that just chased fires.
Be willing to leave things undone. The instinct under pressure is to try to do everything. The team that ships the most is the one that did fewer things, finished, and well. Half-finished work isn't capacity used efficiently — it's capacity stuck. Sometimes the right move is to declare bankruptcy on a couple of items, tell the stakeholders, and clear the deck.
What to say to stakeholders
The conversation when everything feels urgent and you have to push back is the highest-leverage one a PM has. A few patterns that work:
Be explicit about the trade-off. "We can do X, but it would mean pushing Y by two weeks. Which do you want?" That single question converts the asker from a requester into a co-decision-maker. Most of the time they pick something more sensible than the original ask.
Show the queue. Let them see what's already committed and what their request is competing with. The implicit message — your thing is not unique, you're competing for capacity — is the one that calibrates the urgency.
Offer a smaller version. The request is often a maximalist version of what would actually solve the problem. A smaller scope, faster, often beats the original ask. Find that version.
The shift
When everything feels urgent, the answer is rarely "work harder". It's "decide better".
The decisions that matter aren't between the urgent things. They're between the things that are actually time-sensitive and the things that have just been framed that way. Get good at telling those apart and the urgency stops feeling like an emergency.
If you're saying no to protect what matters, telling actual urgency from manufactured urgency is most of the call. And stakeholder communication as a system is what keeps these conversations from happening in panic mode.