The Urgency Test

You only need one question to ascertain whether a sudden customer problem is urgent or not. I call it the urgency test.

ICE·T is my preferred method for feature prioritization. It is simple and easy to understand. It combines a feature’s expected impact (I), confidence (C), effort (E), and time criticality (T). Product teams can often assess the urgency or time criticality of features from dependencies and deadlines: certain components need to be in place before downstream work can commence, and contractual agreements with a customer can increase a feature’s urgency.

But how do you best assess the urgency of ad hoc requests? How do you decide whether to drop everything and focus on such a request, especially when requests are piling up and exceed the allocated maintenance and support time of the team? Urgency is not transferable: just because something is urgent for someone, does not make it urgent for everyone else.

When people approach a team with their pants on fire, it is on the product manager to figure out if they are truly in need of immediate assistance or if they prefer to walk around with their trousers flambés to keep warm during the cold winter months. The question to ask is this:

What is the worst thing that could happen if we don’t do … now?

The answers range from “Nothing much, really” to “Catastrophic collapse of the entire organization” with an entire spectrum of replies in-between. The beauty of the urgency test is that it forces people to think about the worst possible outcome of not acting right now. If a delay of a few hours, days, or weeks is no biggie, it becomes clear to everyone. Sometimes it suffices to ask the question for people to realize that their request was actually not that urgent. You can often figure that out from the way the request is phrased: “Would it be possible to…?” or “Could you please…?” That trick does not work with people who are overly polite, though politeness has a tendency to disappear vis-à-vis imminent disaster.

If any delay can cause a serious problem, a sensible follow-up question is “And how likely is such an outcome?” In cases of near certainty, the team has a good reason to refocus. If it turns out to be a remote possibility, the request can be placed in the larger context of the team’s tasks. Such information enables a product manager to inform people of the choices made. While they may not agree with those decisions, at least they can follow the rationale.