How to decide what to build when everything is urgent

There are weeks when prioritisation feels less like ranking a backlog and more like comparing apples with oranges.

In one planning cycle, my squad had four pieces of work competing for attention.

One was a compliance change being monitored by regulators. The outcome was non-negotiable.

One was an enhancement for our back-office representatives. They worked in a high-pressure, real-time environment and the change would make their work faster and easier.

A strategic initiative was blocked by a feature that needed to be delivered by my squad because the relevant product and domain knowledge sat in our area.

We also had an opportunity to automate an important risk control and reduce our reliance on a manual process.

All four mattered. All four had credible stakeholders behind them. All four could be called urgent.

But they were urgent for different reasons.

Four kinds of urgency

The compliance item carried an obligation. The operational enhancement could improve a difficult working environment. The strategic feature would unlock value outside my own squad. The control automation would reduce risk and ongoing manual effort.

If I forced all four into one narrow definition of value, the result would be neat and probably wrong.

This is where product judgement matters. The aim is not to make unlike things look identical. It is to understand what each item gives the organisation, what it costs to deliver and what happens if it waits.

I use three simple lenses.

1. 01
   Is the outcome genuinely non-negotiable?Separate obligations from choices.
2. 02
   What is the value compared with the full effort?Look beyond revenue and coding effort.
3. 03
   What is the cost of waiting?Time changes the decision.

Start with the constraint

When work is linked to a regulatory obligation, formal commitment or monitored remediation, the first question may no longer be whether we should do it.

The better questions are more precise.

• What outcome is required?
• What date is fixed?
• What evidence will show that the obligation has been met?
• Which parts of the proposed solution are essential and which are enhancements?

This distinction protects both compliance and capacity.

A mandatory outcome does not make every proposed feature mandatory. Product judgement still matters in scope, sequencing and implementation.

Sometimes the most responsible decision is to deliver the smallest safe and compliant outcome first, then return to the desirable extras later.

Use Value versus Effort, but define both properly

My usual starting point is Value versus Effort. I like it because it is simple enough to use in a real conversation. It creates a common page for people who may define value very differently.

But value is not only revenue.

For this decision, value included regulatory assurance, operational efficiency, strategic enablement and risk reduction. In another organisation it may include customer retention, cost avoidance, resilience or employee experience.

Effort is also more than the engineering estimate.

I consider architecture, integration, testing, data, assurance, operational readiness, dependencies and release risk. A small code change can be a large delivery change when several teams and controls sit around it.

I do not always need an elaborate formula. High, Medium and Low can be enough when the criteria are clear and the discussion is honest.

Then ask what happens if we wait

Value versus Effort gives a useful comparison, but it does not always tell us why something needs to happen now.

That is where Cost of Delay helps.

I keep it practical.

What becomes more expensive, risky, difficult or harmful if this work moves by a month or a quarter?

For the compliance change, delay could increase regulatory exposure or put a commitment at risk.

For the operational enhancement, delay meant colleagues would continue carrying avoidable friction in a stressful environment.

For the strategic dependency, delay could hold up a much larger initiative.

For control automation, delay meant accepting manual effort and exposure for longer.

Two items can have similar value and very different costs of waiting. That is often where the order becomes clearer.

When the score is not enough

Sometimes the options are still difficult to compare. Stakeholders advocate strongly. Some escalate. Seniority raises the temperature of the room.

That is when I use WRAP, a decision framework I first came across during my MBA. Chip and Dan Heath describe it as widening your options, reality-testing your assumptions, attaining distance before deciding and preparing to be wrong.

I do not turn WRAP into another scoring exercise. I use it to ask better questions.

The framework is useful because it slows down the pressure without slowing down the decision.

Escalation is a signal that a stakeholder cares deeply about an outcome. It is not evidence that the outcome creates more value than everything already committed.

The question that changes the meeting

Eventually every prioritisation discussion reaches the capacity constraint.

Teams do not gain capacity because a new request is important. Something else may need to move, reduce in scope or wait.

So instead of asking, “Can the squad fit this in?” I ask a different question.

This makes the trade-off visible.

It also changes the tone. The product owner is no longer defending the roadmap against a stakeholder. The group is deciding which outcome matters first and which consequence it is prepared to accept.

That is not resistance. It is responsible product ownership.

The decision desk

When several urgent items arrive together, I use this short sequence.

The roadmap is not a list of everything important.

It is a record of what we chose to do first, what we knowingly chose to delay and why.

When everything is urgent, the job is not to produce a louder version of urgency or a more complicated score.

The job is to separate obligations from choices, understand the value, consider the effort, ask what waiting will cost and make the trade-off visible.

Then decide.