Find the problem behind the request

Here is a ticket, exactly as filed.

Add “Resend invoice” button to customer page Need a button that resends the original invoice PDF to the billing contact. Should NOT regenerate it.

You could build that on Thursday. It is small, it is clear, and the acceptance criteria write themselves.

Do not build it yet. Read it again, because a ticket is not a specification. It is a fossil: the compressed record of something that happened to somebody, already collapsed into a shape. The situation that produced it still exists, upstream in time, and most of it is recoverable from the text in front of you.

What a request cannot help revealing

The verb. It says resend, not send. Something was already sent, and it did not work. That is a failure you have not heard about.

Who filed it. Tomas is in billing ops. Not a manager relaying, not a PM consolidating: the person who does the job. Whatever this is, he hit it himself.

Over-specificity. The original PDF. The billing contact. Nobody writes that much detail speculatively. Each of those phrases is a scar from a specific occasion when the wrong thing happened.

Emphasis. Should NOT regenerate it. Somebody typed that in capitals at 8:52 on a Tuesday morning. There is exactly one way a person arrives at that sentence, which is that an invoice was regenerated once and the numbers came out different, and Tomas had to explain it to a customer.

That last line is not a constraint on your implementation. It is the actual problem, wearing a constraint’s clothing.

THE TICKET AS FILED               WHAT EACH PART IS EVIDENCE OF

 "Resend invoice" button           the verb is resend, not send.
                                     something already failed

 filed by Tomas, billing ops       not a manager relaying. he does
                                     this job himself

 filed Tue 08:52                   first thing, after a Monday.
                                     ask what happened on Monday

 "the original invoice PDF"        oddly specific. he has been asked
                                     for an original and could not
                                     produce one

 "Should NOT regenerate it"        capitals. an invoice was once
                                     regenerated and came out
                                     different. this is the bug

 priority: medium                  he set it himself. nobody triaged.
                                     nobody upstream knows about this

Build the button and Tomas gets a nicer way to do the thing he does after the real failure. The regeneration bug stays. In six weeks he files another ticket.

The move

Read the request as evidence of an event, and go and find the event.

I want to be careful about how hard I push this, because the usual version of this advice claims too much. Every feature request is a solution in disguise is a good working assumption and it is not a measured finding. I have not found evidence for it and I am not going to dress up an argument as data. Plenty of requests are exactly what they appear to be.

What the evidence does support is the stake. Gergely Orosz, writing in January 2026, lists implementing well-defined tickets among the developer skills that have lost most of their value. NACE’s 2026 employer survey finds that graduates entering the field now face expectations built around higher-order thinking rather than primarily coding.

Taking the ticket at face value used to be efficient. It is now the part of the job that has been automated most thoroughly, which makes the reading the valuable half.

The reply that gets you the event

You do not need a meeting. You need one message that asks about the past rather than the future:

Before I build this, what happened the last time? I want to make sure the button fixes the actual thing rather than just making it faster to recover from it.

What happened the last time is doing all the work. It is specific, it is about an event rather than an opinion, and it is impossible to answer with a feature.

What it costs

Sometimes the ticket is just the ticket, and you will have spent twenty minutes and one message confirming that. That is a good outcome at that price, but expect it regularly and do not treat every request as a mystery.

Archaeology can look like obstruction, especially in writing, especially to someone who has already thought about this and would like it built. The framing matters more than the question: before I build this signals that you are building it.

And you can be wrong about the story. The capitals might be a personal habit rather than a scar. Read the ticket for hypotheses, then check them with the person, rather than arriving with a theory about their job.

Try this week

Take the oldest ticket on your board that you have not started, and spend five minutes annotating it instead of estimating it.

Mark three things: the verb, anything more specific than it needed to be, and any emphasis. Then write one sentence about what must have happened for someone to write it that way.

Send that sentence to whoever filed it, as a question:

Reading this back, it sounds like something went wrong with a regenerated invoice at some point. Is that right?

If you are right, you have found a problem nobody had reported. If you are wrong, you have spent a sentence, and the correction will tell you more about the job than the ticket did.