Stakeholders don’t want tickets, they want outcomes

Ticketing is a process, nothing more. A ticket describes a need; it is a way of moving an intention from one head into another without losing too much on the way. The real goal was never the ticket. It was always the outcome on the other side of it: a problem that used to exist and now doesn't.

Stakeholders make this obvious if you listen to them. No stakeholder has ever thanked me for a well-formatted user story. Six months later they remember one thing: is the problem solved? The quality of the artifact is invisible to them, and rightly so. It is internal plumbing. Judging product work by the beauty of its tickets is like judging a restaurant by the handwriting on the order pad.

This gets misread, so let me be precise. Tickets still have to be complete. They have to be understandable. They have to tell a developer clearly what to build and why, because a vague ticket is a tax everyone pays later: in questions, in rework, in the feature that technically matched the ticket and completely missed the point. What they do not have to be is perfect. The prettiest documentation in the world is worth nothing if it cost two hours the outcome did not need.

This is exactly the kind of work AI is good at. Give it the context and it will produce a solid first draft of a ticket, acceptance criteria included, in seconds. But this is the easiest place to fool yourself, so I want to be careful: the thinking still has to be mine. AI can do the writing; it cannot do the deciding about what should be written. The value was never in the words. It was in knowing which words. I let the tool absorb the typing precisely so I have more attention left for the part it can't do.

Documentation, for me, is always a means to an end. The moment it becomes the end, the moment writing it up starts to feel like the achievement, something has gone wrong. A wiki nobody reads is not knowledge. It is a museum.

The other reason not to over-invest in tickets is that the target moves. During discovery, the actual problem changes more often than not. The first thing a stakeholder asks for is usually not the thing they need; it is their best guess at a solution, dressed up as a requirement. “Can we add a filter here” is often really “I can't find my stuff.” “We need a dashboard” is often “I don't trust the numbers I already have.” The request is a symptom. The job is to find the cause.

This is what people mean when they talk about outcomes over output, or about jobs to be done: not the feature someone asked for, but the progress they are trying to make in their situation. A stakeholder rarely wants a filter. They want to stop feeling lost in their own data. Those are very different briefs, and only one of them is worth building.

So a good part of the job is getting from the stated request to the real need underneath it, ideally before a line of code is written. This is where product teams have really changed. We work more iteratively than we did even a few years ago, closer to continuous discovery than to a big upfront spec, because we finally accepted that the first version of a problem is a hypothesis, not a fact. AI helps here too. Not by having the insight, but by getting me there faster: clustering feedback, sifting interview notes, drafting three versions of a flow so I can react to something concrete instead of a blank page. It shortens the distance between a vague hunch and a testable one.

So I try not to optimize my tickets. I try to optimize the path to the outcome. Those are different goals, and they pull in different directions more often than people admit. The team with the most beautiful backlog is rarely the team shipping the best product. A ticket is not a product. It is a communication tool, and the best communication tool is the one that gets out of the way the moment the message has landed.