The problem with urgency
Urgency can come from different directions.
From customers, especially when a request is framed as a deal breaker. From sales or business pressure tied to specific opportunities. From leadership, where priorities shift quickly, and expectations follow.
And sometimes, it comes from the system itself, when something is broken or not working as expected.
Not all of these signals have the same weight, even if they often sound equally urgent.
The biggest mistake teams make is allowing stress and pressure to reach engineers before any real decision has been made.
When a request is framed as urgent, it creates immediate uncertainty. Should we stop what we are doing? Do we need to change priorities right away?
Focus is lost, and the discussion becomes driven by pressure instead of clarity.
This often happens when information is shared too early, or when stakeholders bypass product and engineering leadership and go directly to teams. When urgency comes from higher up, it immediately influences the conversation becase few people are comfortable pushing back.
When urgency is not real
Some of the strongest urgency signals come from high-value customers.
A request is framed as a deal breaker and: if we don’t act, they will leave.
High-value customers raising urgent requests are not the problem. Their needs are often real and important.
The challenge is how those requests are interpreted and translated into product decisions.
To avoid creating pressure to react quickly, it is worth asking a few simple questions.
-
Would this still feel urgent if it came from a different customer?
-
How many other customers would benefit from it?
-
Is this improving the product, or solving a single use case?
In those moments, what looks like an urgent request is often a trade-off decision in disguise. And in many cases, reacting quickly leads to building something very specific for one customer.
That is not a product improvement. That is closer to what consultants or integrators would build.
I have seen requests that looked urgent not being addressed simply because other priorities were more important. Months later, nothing happened. The customer was still there, and the request was no longer urgent.
Real urgency looks different
Real urgency usually comes from problems.
Something is broken. Something is slow. Something prevents customers from using the product.
When this happens, the impact is clear.
-
Adoption is affected
-
Key metrics move
-
Multiple customers are impacted
And when addressed, the value is immediate.
Managing urgency
Not all urgent requests should be treated the same.
Some can be handled quickly using existing support or maintenance capacity.
Others require proper planning and should be scheduled like any other piece of work.
In some cases, the right response is to wait rather than act immediately.
Urgency often compresses the time available to think and react. Decisions are made faster, but not necessarily better. And what is gained in speed is often lost in clarity.
When neither is possible, and plans need to change, the disruption should be explicit. The reason behind the decision should be clear and shared with the team. Alignment matters. Without it, there is a risk of losing focus, motivation, and trust.
The role of product and engineering leadership
Product managers and engineering managers are responsible not only for deciding what to do, but also for how and when information reaches the team.
Their role is to filter noise without hiding information.
It is not the same to say:
We might need to do this quickly.
and:
Here is a new request. Let’s understand if it is something we should address, and when.
The difference is subtle, but the impact on the team is significant.
Choosing not to react
Urgency often pushes teams to act immediately. But not acting is also a decision.
In many cases, waiting allows teams to validate whether a request is truly important. This connects closely to how product decisions are mostly trade-offs, and why waiting can sometimes be the most responsible choice.
Closing
Real urgency comes from clear problems that demand action.
Everything else should be treated as a decision, not as an emergency.