How do you argue a priority escalation for a defect product ranked low?

## The argument you are actually making An escalation request is not a claim that the defect is bad — everyone already agrees it is bad, or it would be closed. It is a claim that the **cost of not fixing it now** exceeds the cost of displacing whatever currently sits above it. That framing decides everything about how to argue. It means you must talk about exposure and cost, must talk about the queue rather than about the defect in isolation, and must accept that the person who owns the release plan owns the decision. ## Convert observations into the units the decision is made in Product ranks work in reach, money, risk and dates. A defect report is written in reproduction steps. The escalation is the translation between them. - **Reach**: the share of traffic, accounts or sessions that cross the broken path — measured where possible, explicitly bounded where not. - **Frequency**: failures per attempt on that path, so an intermittent defect is not argued as if it were deterministic. - **Recurring cost**: support contacts per week, operator interventions per day, refunds, manual reconciliation. This is the number that most often changes minds, because it is already money. - **Commitment**: a contract term, a regulatory obligation, a launch that depends on the flow. - **Trend**: is exposure growing? A defect on a path whose traffic is doubling is a different argument from one on a path being retired. ## A worked escalation A video-transcoding queue has a partial-failure rollback defect: when a multi-segment job loses a worker mid-run, the cleanup deletes the completed segment outputs but leaves the job marked complete, so downstream consumers fetch an index pointing at nothing. Product ranked it low after triage — the reasoning was that an operator can re-queue affected jobs and the outputs regenerate correctly. The escalation is built from what triage did not have. Over 19 days the failure fired 143 times against 60,420 jobs, so about 0.24% of jobs — small. But the affected jobs skew hard to the long ones, and the two largest accounts submit 71% of long jobs, so the customer-level reach is 2 accounts out of 34, both on renewal within the quarter. The workaround is performed by an operator, not by the customer, and each re-queue costs a person roughly seven minutes plus a 27-minute suite re-run before the batch is released: that is around three staff-hours a week that nobody has budgeted. And the failure is silent — the job reports success — so customers discover it when playback fails, which is the shape most likely to become a support escalation rather than a ticket. That argument has a different character from "this is critical, please raise it". It names the population, the money-shaped cost, and the specific property (silent success) that makes the existing workaround unreliable, because an operator cannot re-queue what nothing flags. ## Rank it against something named Asking for "higher priority" is unfalsifiable. Asking whether this should go ahead of a specific item currently above it makes the tradeoff concrete and lets product answer with information you do not have — that the item above is a contractual commitment, say. Either you win the swap or you learn the real constraint, and both outcomes are better than an open-ended plea. ## Arguing a downgrade The same discipline runs in reverse, and being willing to argue *down* is what makes your escalations credible. If a defect was ranked high on an assumption that the evidence does not support — a path everyone believed was hot but which measurement shows is crossed by a fraction of a percent of traffic, or a workaround that turns out to be one the user finds unaided — say so, even when it is a defect you filed. A tester who only ever pushes upward is quickly read as a lobbyist and discounted accordingly. ## What never to do Do not raise the severity field to force the priority decision. It wins once, and it costs the team every measure that reads severity — escape analysis, release criteria, per-severity reporting all stop meaning anything once the field encodes urgency. Do not re-file the defect under a new title to get a second hearing. Do not escalate by volume or by seniority-shopping until someone agrees. And do not treat an operator workaround as free; price it, because unpriced manual labour is exactly how a low ranking survives evidence that should have overturned it. ## When the answer stays no Accept it explicitly and make it durable. Write into the record what risk was accepted, by whom, on what evidence, and — most importantly — the **trigger** that reopens the decision: the flag being enabled, the account going live, the intervention rate crossing a stated threshold. Put the defect on the known-issue list so support and the release notes carry it. A well-documented deferral is a legitimate outcome and often the correct one; an undocumented one is the same defect discovered again in six months by someone with no idea it was ever considered.