You send a plan to your manager and ask what they think. Three paragraphs come back — interesting observations, two caveats, one question. Nowhere in it is the word yes. You are annoyed, and the annoyance is misdirected. They answered the question you asked. You asked for thoughts. You wanted permission.
Naming what you want back changes the reply more than anything else you can do to a message. Three shapes are worth telling apart, and the difference between them is not tone. It is what changes hands.
A decision asks someone to own the outcome
A decision request hands over a closed set of options and asks the reader to pick one, with the understanding that the choice is then theirs. That last clause is the entire shape. If nothing about accountability moves when they answer, you did not ask for a decision — you asked for an opinion in a firmer voice.
A sufficient reply is short. "B." "A, and I will tell the vendor myself." "B, unless the migration slips past October." One line, occasionally with a condition attached. If your decision request needs a long answer, something in it was underspecified, usually the option list.
Asking for a decision is wrong in three situations, and they are worth separating because the repair differs.
They cannot own it. No authority over the outcome, no budget line, no consequence if it goes badly. Asking anyway costs you a round trip when they decline, or costs you more later when everyone discovers the answer bound nobody.
They should not own it. This is the one people do to themselves. The choice is genuinely yours, you hold the most context, and sending it upward is an attempt to distribute the blame in advance. It usually gets caught. What comes back is a question instead of an answer, which is your reader declining the transfer politely.
They cannot own it yet. You have not given them enough to be accountable for. No recommendation, no constraints, no sense of what you already ruled out. A decision request with no lean of your own is asking someone to redo your analysis before they start theirs.
An opinion asks for judgment and leaves you holding it
An opinion request asks for someone's read — their instinct, their experience with the thing you are about to attempt, the objection you have not thought of. Ownership does not move. You still decide, and you still explain it afterwards.
This is what most people actually want when they write "thoughts?", which is why the word is so common and so unsatisfying. The ask is accurate and delivered so vaguely that the reader has to guess how much weight their answer is supposed to carry.
A sufficient reply is a lean plus one reason. "I would go with B — the switching cost on A is worse than it looks." "No strong view, but I would want to know what the contract says about termination." "I do not have a useful read here" is also sufficient, and it is a healthy sign when people feel able to say it.
Asking for an opinion is wrong when you need someone committed. If the work cannot proceed until a named person is on the hook, an opinion buys you a quotable sentence and no obligation whatsoever. The tell arrives weeks later, when you find yourself writing "but you said B was fine". That is an opinion being cashed as a decision, and the person you are quoting will experience it exactly that way.
A review asks someone to find what is wrong
A review request points at something that already exists — a design, a draft, a plan, a finished piece of work — and asks the reader to attack it. The artifact is the ask. Without one there is nothing to review.
A sufficient reply is a list of specific problems, ideally ordered by how much they matter, or an honest "nothing blocking, two small things". This is the one shape where length is a virtue.
Two ways it goes wrong. Asking for a review of something not yet built returns design opinions, because opinions are all that is available, and then everyone is disappointed. And wanting approval while calling it review: if a list of defects would upset you, what you want is a sign-off, and the honest version of that ask is a decision. Technical design reviews have conventions that mostly exist to keep those two apart.
The common failure is a decision hiding inside an opinion request
The mismatch almost always runs one way. People soften a decision request into an opinion request out of politeness, or because asking a senior person to commit feels presumptuous. The reader answers the softened version, correctly. Then the sender is frustrated by a non-committal answer to a question they deliberately made non-committal.
Nobody misbehaved. The fix is one sentence, and it costs less social capital than the softening was protecting: "I need you to pick between A and B by Thursday — if you would rather just give me your read and leave the call with me, say so and I will decide."
That sentence does two jobs. It states the shape, and it offers the reader a graceful way to downgrade it. Someone who cannot own the outcome now has a script for saying so.
Two shapes that are not asks at all
Not every message wants something back. Alongside decision, opinion and review, RelayLink's response shape field takes two more values: info, for material someone needs or asked for, and fyi, for a note that expects no reply.
On RelayLink these are not decorative. A thread whose most recent package is an fyi drops to idle once the other side has seen it — seen meaning the link was opened or their assistant pulled the package. Every other shape leaves the thread listed as waiting on someone until a reply actually lands. There is no replied-and-closed state, which means the shape you choose determines whether the thread quietly resolves or sits on someone's list as an open obligation.
Picking, in one question
Ask what you will do the moment the reply lands. Act on it — decision. Keep thinking — opinion. Go and fix things — review. Then the second check: who is accountable if this goes badly? If the answer is still you, it was an opinion, and saying so in the message is what stops you resenting the answer.
The honest limit is that naming the shape does not make anyone answer. It removes one specific failure — the reply that misses because the reader guessed wrong about what you wanted — and leaves every other failure standing. A briefing makes the shape a required field rather than a good habit, and the value is validated against the five allowed words, so a send cannot go out without one. Nothing checks whether you chose correctly. No software has a view on whether the person you addressed can own the outcome. That judgment stays where it was.
For the wider version of the same idea — designing the whole message backward from the answer you need — read the reply is the point. To have the ask stated explicitly by default, connect your assistant.