When the request arrives already solved

"We need a dashboard." "Can we add a CSV export?" "Could this be a dropdown instead?"

These are not requirements. They are conclusions, and somebody reached them before they opened the issue. The reasoning that got them there is the part you actually need, and it is the part that did not get written down.

Why people file the answer instead of the question

Not out of arrogance. Filing a solution is the polite thing to do, and everyone knows it. Turning up with a vague complaint feels like handing someone else your homework; turning up with a specific proposal feels like you have done your share of the thinking.

So the reporter does the translation themselves. They had a problem, they imagined something that would fix it, and they filed the something. The translation is invisible, and it is where the information went.

You could build that. Somebody could spend three weeks building that. And it might well not touch the thing that prompted it, because nothing in that sentence tells you what the thing was.

The question that unwinds it

One question does most of the work: what decision will this help you make?

It works because it is not a challenge. It does not ask the reporter to justify themselves or admit the idea was half-formed. It just asks what happens next, after the thing exists, and almost everyone can answer that.

That is a different piece of work. It might still be a dashboard. It might be a weekly digest, or an alert at a threshold, or a single number on a page that already exists. All three are cheaper than a dashboard and two of them are better answers to the actual problem, which was late warning rather than absent data.

The solution is still evidence

There is a way to do this badly, which is to treat the proposed solution as noise to be cleared away before the real conversation starts. It is not noise. Somebody who works with the system every day imagined a specific fix, and the shape of what they imagined tells you what they think is wrong.

Somebody who asks for a CSV export is telling you they need the data somewhere else. Somebody who asks for a dropdown is telling you they cannot remember the valid values. Keep the proposal. Ask what it was for. You end up with both.

Where it gets expensive

Solution-shaped requests are the ones most likely to survive all the way to a shipped feature without anyone noticing the question was never asked, precisely because they sound so complete. A vague issue gets challenged. "We need a dashboard showing team performance" gets estimated.

Nobody in the chain does anything wrong. The reporter files a clear request. The manager prioritises a clear request. The developer builds a clear request. It ships, and it does not get used, and the retrospective concludes that the requirements were clear but the users were confusing.

Asking without sounding like you are refusing

The awkwardness is real. "Why do you want that?" reads as an obstacle, especially in writing, especially across a company boundary. Three phrasings that do not:

• "What will you do with it once it is there?" Asks about the future rather than the reasoning, so nothing is being second-guessed.
• "What are you doing at the moment instead?" The current workaround usually names the problem exactly, and people describe workarounds happily.
• "Who else needs this, and what would they use it for?" Turns one person's request into a picture of the need, and often reveals the request was narrower than the problem.

None of them say no. All of them get you the paragraph that was missing.

The habit

When a request arrives fully formed, that is the moment to ask what it is for, not the moment to start estimating. The confidence in the phrasing is not evidence that the thinking has been done. It is usually evidence that the thinking was done privately, by one person, once, and that nobody has seen it since.