Turning a request into something you can decide on

Every delivery process has a door, and almost nobody designs it. Requests arrive through whatever channel is nearest — a form, a chat message, a forwarded email thread, a sentence at the end of a meeting — and the first real thought anyone gives them happens weeks later, at prioritisation, when the context that would have explained them is gone.

This is the cheapest place in the whole process to intervene and the least attended. Everything downstream — shaping, deciding, estimating, refusing — operates on what came through the door, and none of it can recover information that was never asked for while the requester still had it in their head.

The bar is one sentence, and it does not have an override

A request is routable when it states what needs to change, plus at least one of who is affected or why it matters now. Not any two of three: impact and urgency without a stated need is the shape of every doomed project — enormous pressure attached to a void. Keep the bar that small and there is no legitimate case for skipping it, which matters, because an escape hatch is offered precisely to the one person certain their request is the exception, and a bar that can be skipped has taught everyone it is decoration.

A subject is not a request

Half of what fills an intake queue is a topic wearing the grammar of a request: SSO, reporting, onboarding, performance, tech debt. They survive prioritisation at a higher rate than clear requests do, because there is nothing in them to disagree with — the ambiguity finally becomes concrete when an engineer makes a decision they were never meant to make. One question separates them: after this is done, what is true that is not true today? And when a topic fails it, hand the question back rather than answering it helpfully on the requester's behalf — a guess written in full sentences stops looking like a guess.

Waiting is a state; silence is not

Most requests that die are never refused. Someone asks a reasonable clarifying question and that is the last event in the record. A waiting request and a forgotten one render identically — both are just old — so the items that need an answer from a busy senior person, a vendor or a legal team are the ones that systematically expire, and those are usually the consequential ones. Waiting earns the name of a state when it carries the question as actually asked, who was asked, who owns the chase, and a follow-up date or an explicit decision to go without one.

The three hold together: the bar makes a request readable, the topic test makes it about something, and a named waiting state stops the ones that need one more fact from disappearing between the two.