When Everything Is Urgent
Time to read: 9 minutes
Time to apply: 1 hour
Your CEO wants the new enterprise feature. Sales needs the integration. Product wants to ship the roadmap. Security demands immediate attention. And you have capacity for 2 projects, not 5.
When everything is urgent, nothing is urgent. Someone has to make the hard call about what gets done and what gets deferred. That someone is probably you.
What You'll Learn
- How to identify true urgency vs noise
- Stakeholder mapping for priority decisions
- The "must do / should do / could do" framework
- How to say no without burning bridges
The Urgency Trap
Everything feels urgent because of three forces:
1. Stakeholder Pressure
When your CEO says "this is urgent," it feels urgent. When Sales says "we're losing deals without this," it feels urgent. When every stakeholder escalates, everything feels urgent.
2. Market Changes
Competitors launch features. Regulations change. Customer needs shift. Real market pressure creates real urgency. But not every change requires immediate action.
3. Reactive Mode
When you're always responding to the loudest voice, you lose the ability to plan strategically. You're constantly firefighting instead of preventing fires.
The result: You try to do everything and deliver nothing on time.
True Urgency vs Noise
Not all urgent requests are actually urgent. Use these 3 tests to separate signal from noise:
Test 1: Deadline with Consequences
Real urgency: "We have a regulatory deadline of March 1st. Missing it means £500k in fines."
Fake urgency: "The CEO wants this by Q2." (No specific consequence for delay)
Test 2: Window of Opportunity
Real urgency: "We can acquire this competitor for £5M but the offer expires in 30 days."
Fake urgency: "If we don't ship this feature, we might lose market position." (Vague, no timeline)
Test 3: Blocking Dependency
Real urgency: "5 other projects are blocked until we finish the API migration."
Fake urgency: "This would be nice to have before the next release." (Preference, not dependency)
If a request fails all 3 tests, it's not urgent—it's important. Important things can be scheduled. Urgent things must be addressed now.
Stakeholder Mapping
Understanding who cares about what (and why) is critical for priority decisions. Use this power/interest matrix:
Power/Interest Matrix
High Power, High Interest (Manage Closely):
These stakeholders can kill your decision and care deeply. Give them direct input.
Example: CEO, Board, Key Customers
High Power, Low Interest (Keep Satisfied):
These stakeholders have authority but don't engage daily. Keep them informed.
Example: CFO, Legal, Compliance
Low Power, High Interest (Keep Informed):
These stakeholders care deeply but don't control resources. Listen but manage expectations.
Example: Individual Contributors, Support Team
Low Power, Low Interest (Monitor):
These stakeholders don't impact or care much. Minimal communication needed.
Example: Peripheral Teams, External Partners
Map each "urgent" request to its primary stakeholder. This shows you who's really pushing and how much weight to give each request.
Must / Should / Could Framework
Once you've identified true urgency and mapped stakeholders, categorize every request:
MUST DO
Criteria: Passes urgency tests + high-power stakeholder + clear consequence for delay
Action: Do this now. Allocate resources immediately.
Example: "Security patch for critical vulnerability. High-power (CTO, CISO). Consequence: £2M+ breach risk. Deadline: 72 hours."
SHOULD DO
Criteria: Important but fails 1-2 urgency tests + medium-power stakeholder + manageable delay cost
Action: Schedule this. Commit to timeline but defer to next sprint/quarter.
Example: "Enterprise feature request. High-interest (Sales VP). No hard deadline but £200k deal value. Timeline: Next quarter."
COULD DO
Criteria: Fails all urgency tests + low-power stakeholder + no clear consequence
Action: Backlog this. Nice to have but not now.
Example: "UI polish request. Low-power (Product Designer). No customer complaints. No revenue impact. Timeline: If capacity allows."
Categorization Worksheet
Request: _________________________________
Stakeholder: _____________ (Power: H/M/L, Interest: H/M/L)
Urgency Tests:
[ ] Deadline with consequences
[ ] Window of opportunity
[ ] Blocking dependency
Consequence of delay: _________________________________
Category: [ ] MUST [ ] SHOULD [ ] COULD
Saying No Without Burning Bridges
Deprioritizing a request isn't rejection—it's reality. Here's how to communicate it:
For "SHOULD DO" Items
"I understand this is important. Based on our current capacity and the MUST DO items (regulatory deadline, security patch), we can commit to this in Q2 instead of Q1. Here's the timeline: [specific dates]. Does that work?"
For "COULD DO" Items
"This is a good idea. Right now we're focused on [MUST DO items] which have hard deadlines and direct revenue/risk impact. Let's revisit this in [timeframe] once those are delivered. I'll add it to our backlog so we don't lose track."
For High-Power Stakeholders
"I want to make sure we deliver this right. If this is a MUST DO, I need to understand the urgency: What's the deadline? What happens if we delay 30 days? Is this blocking other work? Based on your answers, I can either reprioritize or commit to a realistic timeline."
The key is acknowledging the request, explaining the trade-off, and offering a specific alternative (timeline, scope reduction, etc.).
Real Example: 5 Urgent Requests, 2 Delivered
Context: A VP of Engineering at a £20M ARR SaaS company receives 5 "urgent" requests in the same week:
The Requests
1. Security Patch (CISO)
Critical CVE. 72-hour deadline. £2M+ breach risk.
Category: MUST DO
2. Enterprise SSO (Sales VP)
£300k deal at risk. Customer deadline: 2 weeks.
Category: MUST DO
3. Mobile App Redesign (CEO)
CEO saw competitor app and wants parity. No customer complaints.
Category: SHOULD DO (Q2)
4. API Rate Limit Increase (Customer Success)
1 enterprise customer hitting limits. Not blocking but annoying.
Category: SHOULD DO (2 weeks)
5. Dashboard Customization (Product Manager)
Nice-to-have feature. No urgency tests passed.
Category: COULD DO (Backlog)
The Decision:
- MUST DO: Security patch + SSO (all team focus for 2 weeks)
- SHOULD DO: Mobile redesign in Q2, API limits in 2 weeks post-MUST items
- COULD DO: Dashboard to backlog, revisit in Q3 planning
The Communication: VP sent stakeholder-specific messages explaining trade-offs, offering timelines, and requesting confirmation. CEO pushed back on mobile redesign. VP offered to accelerate to Q1 end if CEO could free up 2 engineers from another initiative. CEO declined. Mobile stayed Q2.
The Outcome: Security patch delivered in 48 hours. SSO shipped in 10 days, deal closed. API limits resolved week 3. Mobile redesign on track for Q2. Dashboard still in backlog (no one followed up).
Summary
When everything feels urgent, use these tools:
- Urgency Tests: Deadline with consequences, window of opportunity, blocking dependency
- Stakeholder Mapping: Power/interest matrix to understand who drives what
- Must/Should/Could Framework: Categorize every request based on urgency + stakeholder power
- Clear Communication: Acknowledge, explain trade-offs, offer specific alternatives
Saying no is part of leadership. The goal isn't to make everyone happy—it's to deliver the highest-value outcomes with the resources you have.
Ready to Apply This?
List all your current "urgent" requests. Run them through the urgency tests. Map stakeholders. Categorize as Must/Should/Could. Draft your communication for each.
Need Help Applying This to Your Situation?
We use these frameworks with our clients every month to make priority decisions in 30 days (or less).