Main idea

Nobody, sitting in front of a screen, wonders whether he is suffering from a defect, a missing capability, a badly built capability or a capability that doesn't match his need. He observes that he can't do what he came to do.

The ticket's category is manufacturing information. It describes the origin of the problem, not its effect. Software with no technical defect at all can be painful from end to end, and the pain is as real as that of a regression.

What remains to be analyzed is therefore elsewhere: which pain, for whom, at what frequency, with what impact, is it blocking, is it regulatory, does it generate support, does it destroy trust.

The consequence for prioritization vocabulary is direct: the distinction between defect and feature is too thin to carry a trade-off. The useful question isn't which nature the subject falls under, but which pain is a priority in the light of strategy, customers and real capacity.

Layer added by "The Backlog Is Not a Dumping Ground: It's a Tool for Action" (2026-06-03).

Why it matters

This takes away from the category the role it spontaneously assumes. It can help measure the state of the production system; it can't decide in the team's place, since it carries no information about impact.

Nuances and limits

The category keeps a diagnostic value on the manufacturing side: a regression signals a production system that lets things through, which a capability request does not.

And pain is declarative: it is collected from people who don't always articulate it, or who articulate it in the tool's vocabulary.

Open questions

• How do you collect pain without routing it through ticket vocabulary, which reformats it into categories?