What makes a request shapeable
· 7 min read · by Tan Gravam
The short answer
A request can be shaped into a demand when it contains a need - something that should be different - plus either an impact (who it affects) or a trigger (what happens if nothing changes). A topic word is not a request: "reporting" or "the mobile app" cannot be routed, sized or decided on, and accepting it into a lifecycle just moves the work of understanding it to someone with less context. Ask the one or two questions that clear the floor at intake, when the requester is still present, rather than three weeks later.
"Can we do something about reporting?"
That is a real message, sent by a real director, and it is not a request. It is a topic. Accepted into a delivery process it becomes a ticket titled "Reporting", assigned to someone who was not in the conversation, and three weeks later somebody is reverse-engineering what was meant from a Slack thread that has scrolled away.
The floor, and why it is low
A request is shapeable when it contains a need — something that should be different — plus at least one of:
- an impact: who is affected, or what it is costing;
- a trigger: what happens if nothing changes, or why now.
That is deliberately not a specification. No acceptance criteria, no estimate, no solution. "Finance can't close the quarter without manually rebuilding three reports, and audit season starts in November" clears it in one sentence, and that sentence is enough to route the work, find the right people, and decide whether it is worth shaping further.
The floor is low because the alternative is worse in both directions. Set it higher and people route around intake entirely — the request arrives as a hallway conversation instead, and you have lost the record as well as the structure. Set it lower, accept the topic word, and you have moved the work of understanding the request from the person who has the context to the person who does not.
Why "we'll figure it out later" is expensive
The cost is not the ambiguity. It is when the ambiguity is resolved.
At intake, the requester is present, the context is fresh, and clearing the floor costs one reply. Three weeks later the requester has moved on, the person doing the work has to reconstruct intent from a title, and the reconstruction is a guess that will be treated as a specification by everyone downstream.
This is the same asymmetry as writing assumptions down as assumptions : the information exists at the start and evaporates almost immediately, and no amount of diligence later recovers it.
Ask, don't reject
The failure mode of any intake bar is that it becomes a rejection. "This doesn't meet our intake standard" teaches people that intake is an obstacle, and they stop using it.
What works is asking the specific missing thing, immediately, in one line. Not a form — a question:
- Missing the need: what should be different?
- Missing impact and trigger: who is affected, or what happens if nothing changes?
Two questions, and almost nobody minds answering them, because they are the questions the requester can answer instantly and nobody else can answer at all.
It is also worth being clear that a request can clear the floor and still be nothing but a subject area — a topic in the grammar of a request passes most checks that count words rather than read them.
The urgency trap
The requests that most need the floor are the ones that arrive with the most urgency, and urgency is exactly what argues for skipping it. "There's no time to write it up, it's blocking the board review."
Worth being blunt: a request too urgent to describe in one sentence is a request nobody can act on quickly either. The sentence is not overhead on the work; it is the smallest possible version of the work of knowing what to do. Skipping it does not save the time, it moves the time to the most expensive place — the middle of delivery.
What this is not
Not a solution. Not an estimate. Not a business case, a priority, or an owner. All of those come later and several of them are somebody else's job. The floor exists to establish that there is something here to shape, and nothing more.
Everything after it — separating fact from assumption, naming the outcome, finding the owner — is the shaping work proper, and it is much easier when the starting point is a sentence rather than a noun.
How DeliverySheet enforces it
Capture takes raw pasted text — a Slack message, an email, a note — and scores it for three signals: need, impact, trigger. Entering the lifecycle requires need plus either impact or trigger. There is no override: a topic word does not become a demand because someone insisted.
Two details matter more than the rule. First, the floor is deterministic — if the AI is unavailable, the same bar applies as two plain questions ("what needs to change?", "who is affected, or what happens if nothing changes?"), and the answer is marked as user-attested rather than AI-verified. A governance rule that quietly relaxes when a model is down is not a rule.
Second, what the AI reads can be rejected. If it decides your paste contains an impact and it is wrong, you say "not quite" and correct it in a sentence — the correction wins. That is the same principle as AI suggesting rather than deciding : it can read, it cannot rule.
And the original paste is stored immutably. Answers given at capture live alongside it rather than being folded into it, so a year later you can still see what was actually asked for, separately from what was interpreted.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$10/month per workspace during the launch period (normally $189), unlimited members, 7-day free trial. I answer the support email myself.
More on turning a request into a decision
Read the overview: Turning a request into something you can decide on →
- Not every request should enter the process
A bar at intake is usually described as bureaucracy. One sentence wide, applied at the door, it is the cheapest quality control a delivery process has.
- "SSO" is a topic, not a request
Half of what arrives in an intake queue is a subject area wearing the grammar of a request. The test that separates them takes five seconds.
- Waiting on information is a state, not silence
Most requests that die never got refused. They got asked a question and then quietly stopped existing. Waiting has to be a state with an owner and a date.