Feedback from production: tickets and incidents as a source of new tasks
A month after release, support gets the tenth ticket about the same thing. None of them reaches the analyst: each is closed with “working as designed” — and formally that is true.
The task is closed, the team has moved on. But a spec is finally tested not at acceptance and not in the first day, but over the following months — by how the system is used. That test runs on its own, without the team: people write to support, make mistakes, find workarounds. The only question is whether any of it reaches whoever writes the next spec.
Where feedback comes from
| Source | What it shows | How it usually gets lost |
|---|---|---|
| Support tickets | Where users don’t understand the system, or it behaves differently from what they expect | Closed with “working as designed” and never reach the analyst |
| Incidents | Where the system failed: often non-functional requirements that never existed | The review ends with a code fix; the spec stays unchanged |
| Usage data | What nobody uses at all, and where people abandon a scenario | Nobody looks at it after release |
| Sales and account managers | What is missing for someone to buy or renew | Arrives as a ready-made solution: “do it like the competitor” |
| Manual work around the system | Spreadsheets kept alongside because the system can’t do it | Invisible until you ask |
“Working as designed” is the most expensive answer
Support tells the user the system is working correctly and closes the ticket. Formally true: the behaviour matches the spec. But if there are dozens of such tickets, the spec is wrong — it described something other than what people expect. It is the same analysis as in the piece on disputed defects, seen from the user’s side: “works as written” does not mean “works as needed”.
Hence a rule for support: tickets closed with “working as designed” do not vanish, they are collected by theme and reach the analyst every few weeks. Nobody needs to read each one — what is needed is a summary: theme, number of tickets, sample wording.
How to build a channel to the analyst
- A feature tag on the ticket. If tickets are tagged with a feature or a requirement number, they can be counted per release. It is the same “defect → requirement” link as in the piece on traceability, applied to tickets.
- A regular review, not an occasional one. Every two to four weeks — half an hour with the support lead over the summary. Without a schedule the review happens only after a loud complaint.
- A set time after release. A month after a noticeable feature ships — a separate look at the tickets about it. That is also when the success metric is checked, if one was written down.
An incident review through the analyst’s eyes
An incident review usually answers “what broke and how do we prevent it”. The analyst brings three questions of their own:
- Was there a requirement that was violated? If so, why did the check not catch it.
- If there was no requirement — should there have been? Most often it is a non-functional one: volume, load, behaviour when a neighbour fails.
- What changes in the spec now — so that the next task in this area starts with this knowledge.
A blameless review is not a courtesy here but a precondition: if incidents are punished, people stop mentioning gaps in the spec out loud.
A user’s ticket is a request too. “Add a cancel button” from support is just as much a ready-made solution as a customer’s request. Before filing a task, the same questions from the piece on eliciting the need apply: what was the person trying to do, and what got in the way.
What becomes a task
Not every complaint is a task. Pointers for deciding:
- Frequency and cost. Ten tickets a week about the same thing cost support time — that is already a number to compare with the cost of fixing it.
- A workaround. If people found a workaround and use it, there is a problem but it isn’t burning. If they abandon the scenario, it is.
- Written as a problem. What goes into the backlog is not “a cancel button” but “customers cannot cancel an order after payment, 40 tickets in a month”. The solution is chosen when the spec is written, not when the complaint comes in.
The sign there is no feedback: the analyst learns how a feature is used from a management presentation six months later.
A fifteen-minute check
Take a feature released a month ago. Answer two questions: how many support tickets were there about it, and did the metric it was built for move? If both answers are “don’t know”, there is no channel from production to the spec.
What next
Feedback from production is the input to the next task. The problem found travels the requirement’s path again: the need is uncovered, the spec’s readiness checked, the boundaries drawn. The chain closes — and starts again with the Definition of Ready.