Main idea

"Qualify an incident", "find context before acting", "compare several entities", "coordinate several people": phrased this way, a customer need names a work action and nothing else. It doesn't say through which screen, which feature or which mechanics the product should answer it.

That is precisely what makes it usable for a long time. A need recorded as "add a comparison button" has already settled the solution at the moment of collection, and the trace of what the customer was trying to do has disappeared — you can no longer reopen it to imagine something else. Phrased at the level of the action, the same feedback stays open to several product answers, and it stays comparable with other feedback that aimed at the same action through different requests.

That level is also the one that best withstands time: screens change, features are replaced, but qualifying an incident remains what a technician does.

Why it matters

This protects discovery from a decision taken too early and by the wrong person. A customer who asks for a button is proposing a solution; recording it as is puts their proposal into the repository as if it were the need.

It also creates a point of grouping. Three feature requests with no apparent connection, brought back to the same job, reveal one badly equipped action — a grouping that stays invisible as long as each request is filed under its solution.

Nuances and limits

Going back up to the job must not become a systematic climb into abstraction: a specific irritation rephrased as a generic business action loses the detail that made it fixable. The level of the action is one more level, not a level that absorbs the others.

And phrasing as a job guarantees nothing about frequency or value: it says what the customer is trying to do, not how many customers are trying to do it.

Open questions

• How do you check that a job phrased by the product team matches what the customer actually does, rather than what you understood from their account?