For a long stretch, bug priority on one client's project was set by engineers reading ticket descriptions in a tracker. It was reasonable and it was consistently wrong about which bugs actually mattered, because severity in a tracker and severity in a support inbox are not the same measurement.
The gap
A bug that's easy to describe and reproduce gets a clear ticket and a clean write-up. A bug that's confusing, intermittent, or embarrassing gets a vague ticket, or gets handled by support as a one-off workaround and never becomes a ticket at all. The tracker was systematically underweighting exactly the bugs that were hardest to write up cleanly, which correlated more than we'd have guessed with the ones actually costing the client the most support time.
What we changed
We added a support engineer to sprint planning, not as an observer but with the same standing to argue for priority as anyone else in the room. Their input wasn't a ticket count; it was a direct account of which issues were generating repeat contacts, which ones customers were phrasing as "this always happens", and which ones the support team had quietly built workarounds for rather than escalating.
What that surfaced
- A pattern of complaints that had never become a single ticket, because each individual instance looked minor and nobody had connected them until someone counted.
- A "known issue" the team had stopped mentioning to engineering because previous reports hadn't gone anywhere, which is its own quiet failure mode worth noticing.
- A genuinely low-severity bug that had been sitting at the top of the tracker for months, reprioritised downward once it was clear almost nobody was hitting it.
Why this needed a person in the room, not a report
A written summary of support trends gets read once and loses its context. A person answering direct questions — "how often does this actually come up", "what do customers say when it happens" — surfaces nuance that a report strips out, and can push back in real time when an engineer's read of severity doesn't match what they're seeing.
The tracker measures how well a bug was described. It does not measure how much it hurts.
What we'd recommend to any team running a backlog
Whoever is closest to the customer's actual pain should have a standing seat at planning, not a quarterly review slot. The cost is one recurring meeting invite. The benefit was a backlog that, for the first time in that project, matched what customers were actually experiencing.