Bug or product decision? Telling them apart before it reaches a sprint

Some proportion of every bug queue is not bugs. It is people telling you, in the only vocabulary available to them, that the software does something they did not want.

Those tickets are not defects. They are product decisions wearing a defect's clothing, and they are cheap to identify in the first five minutes and expensive to identify in week three, after an engineer has read the code, confirmed it behaves as designed, and escalated.

Why reporters cannot label these correctly

Because the label depends on intent, and intent lives in somebody else's head.

A user who finds that deleting a project also deletes its archived exports has no way to know whether that is a mistake or a decision somebody argued about for an hour in 2023. From outside, a deliberate cascade and an accidental one look identical. They report what they can see: they lost data they wanted.

Telling people to "file feature requests separately" does not fix this, because they are not requesting a feature. They believe they are reporting a fault. The taxonomy you are asking them to use requires the information they came to you to get.

The question that separates them

One question does most of the work, and it is not "is this a bug or a feature request":

What did you expect to happen instead?

If the answer describes behaviour the software once had, or claims to have, or obviously intends to have, it is a defect. If it describes behaviour that is simply different and arguably better, somebody has to decide, and that somebody is not an engineer picking up a ticket.

The reason this question works where a dropdown does not is that reporters can always answer it. They know what they wanted. They just do not know whether wanting it was reasonable.

Three tells, in order of reliability

The expectation predates the software. "I expected it to work like the old system" or "I expected it to work like every other tool does" is nearly always a product conversation. The reporter is describing a mental model formed elsewhere.

It has never worked that way. Regression is the strongest single signal of a genuine defect. If the answer to "when did this start" is "it has always done this", you are probably looking at a design somebody chose.

Two reporters want opposite things. The clearest tell of all, and it only shows up if you look across tickets rather than at one. If somebody has previously asked for the behaviour that is now being reported as broken, the ticket is a prioritisation question and no amount of engineering will resolve it.

What it costs to get this wrong

The failure mode is not that the wrong person fixes it. It is that nobody fixes it and nobody says so.

A misfiled product decision sits in the engineering queue, gets picked up, gets investigated, gets marked "working as intended", and is closed. The reporter, who described a real problem with the product, learns that reporting problems achieves nothing. Meanwhile the actual decision, which might have been worth making, never reaches anyone empowered to make it.

That is a double loss: the engineering time and the lost signal. The second is larger and completely invisible.

Where the sorting should happen

At the moment the issue is filed, not at the moment it is picked up.

The difference matters because the reporter is present at the first moment and absent at the second. Asking "what did you expect instead" three days later means waiting for an answer, so most people skip it and guess. Asking it while the person is still in the thread costs nothing and gets an answer in minutes.

Sorted early, a product decision goes to the person who owns the product with the reporter's own words attached, which is the best possible form for it. Sorted late, it goes to a "wontfix" and a quietly disappointed customer.