When everything is urgent: how to have a useful priorities conversation
Tech at Work Series
Three people need something by Friday. Each request sounds reasonable. The team is already busy, and saying yes to all three would depend on work happening faster than anyone can explain.
This is where a useful priorities conversation begins. Your job is to make the consequences and choices clear enough for the right person to decide.
You can be helpful without making a delivery promise you cannot support. That matters particularly when you are new to product or delivery and still building relationships with stakeholders.
Make the priorities clear
1. Find out what “urgent” means
Purpose: Understand the deadline and the consequences of waiting.
Ask what happens if the request waits. A deadline might be tied to a customer commitment, an internal preference or a dependency somebody has only just discovered. Those situations deserve different responses.
Start with curiosity and use concrete questions:
- What needs to happen, for whom, and by when?
- What changes if it happens next week instead?
- Is that date fixed, and what makes it fixed?
- What evidence supports the impact you describe?
- What is the smallest useful outcome by the deadline?
Record unknowns. “We have not checked whether the customer needs this on Friday” is useful information. A confident-sounding assumption can lead the whole team in the wrong direction.
For incidents or serious operational risks, use the organisation’s agreed response route. A routine prioritisation meeting should not delay an established incident process.
2. Make the trade-off visible
Purpose: Show which current work a new request would affect.
Before promising a change, ask the team what it would interrupt. Include investigation, testing, review and release work in that discussion. A request described as “just a small change” may still carry substantial uncertainty.
Try this wording:
“I understand why Friday matters. The team is currently working towards X. Let’s check the smallest useful response and what would need to move before confirming a date.”
You have acknowledged the need and created a path to a decision. You have also avoided volunteering the team for an unexamined commitment.
If you do not hold the decision-making authority, bring a recommendation to the person who does. In Scrum, the Product Owner is accountable for Product Backlog ordering. Changes to work within an active Sprint also require a conversation with the Developers about the Sprint Goal and the plan. Any change must protect the Sprint Goal and maintain quality.
Turn the conversation into a decision
Worked example: a campaign and a reporting request
Purpose: Compare the options using a concrete, fictional situation.
This fictional example illustrates a conversation, rather than a guaranteed delivery estimate.
A marketing lead requests a new registration field before a Monday campaign. An operations lead wants a dashboard by Friday. Both call their request urgent.
Questions reveal that the campaign needs to distinguish two registration sources. The operations dashboard would replace a manual report that can run for another week, although doing so has a real staff-time cost.
The team investigates whether the existing reporting setup can distinguish those sources without changing the registration form. That option still needs checking. It is not safe to promise it simply because it sounds smaller.
The decision-maker agrees to investigate the campaign option first, tells operations when the dashboard will be reconsidered and records the cost of continuing the manual report. If the investigation rules out the smaller option, the group will revisit the choice that afternoon.
The useful outcome is an explicit decision with a review point. Both requests remain legitimate.
Copy this priority conversation note
Purpose: Record the request, its impact and who can decide what moves.
- Request and person asking:
- Outcome needed and who benefits:
- Deadline and reason:
- Consequence of waiting:
- Evidence and remaining uncertainty:
- Smallest useful option to investigate:
- Current work affected:
- Decision-maker:
- Decision, explanation and next review:
Close the conversation clearly
Purpose: Make the agreement and the next update clear to everyone involved.
Send a short record through your normal working channel. State what was agreed, what has moved, who needs to act and when people will hear more. Distinguish a confirmed commitment from an option still being investigated.
Useful closing wording is: “Today’s decision is to investigate A before committing to a build. B will be reconsidered on Thursday. If A needs more work than expected, I’ll bring the options back this afternoon.”
If every request continues to override agreed priorities, raise that pattern with the accountable leader. Better phrasing cannot compensate for an organisation that gives people conflicting authority or punishes realistic forecasts.
Your next step
Take one current urgent request and complete the deadline, consequence and evidence fields. Then identify the person who can decide what moves. Those four answers will make the next conversation more useful.
The official Scrum Guide explains Product Owner accountability and how Sprint scope can be clarified and renegotiated as more is learned. The conversation note above is an optional working aid.


