EverProduct
AI

Stage 02 · How to Talk to It

The Anatomy of a Request

A weak answer is usually a weak brief. Every decision you leave out, the model makes for you — and it makes it by rolling to the average.

"Write an article about remote work." The answer comes back readable, structured, and utterly forgettable — the sort of thing that already exists on four hundred blogs.

The reflex is to conclude the model is mediocre. But look at what it was given. Nothing about who reads it, what it should argue, how long, in what voice, or what would make it good. Every one of those decisions still had to be made by somebody — and since you didn't make them, the model did, the only way it can.

Every decision you don't make, the model makes for you — and it makes it by rolling to the average.

That's the whole idea. The landscape from the first article has a lowest point, and a vague request slides straight into it: the most-written-about version of the topic. Not because the model is lazy — because you handed it a ball and no slope.

The five slots

A good request isn't polite or long. It's a brief with the decisions filled in. Five slots, and it's worth learning them as a set, because the gap is usually obvious once you check:

1. The task. A verb and a result, not a topic. Not "about onboarding" but "write", "compare", "find the holes in", "rewrite into", "extract as a table". "About X" is the single most common cause of a mediocre answer.

2. The context. Who reads it, what for, what already exists, what's already been decided. Audience is the most under-used lever there is: the same request aimed at a beginner, at your team lead, and at a sceptical client produces three genuinely different texts. If you specify nothing, you get the imaginary average reader, whom nobody is.

3. The material. The actual text, data, code or examples the work is done on. This slot is so powerful it gets the next article to itself.

4. The format. Length, structure, what the output physically is: a table, five bullets, a letter, a diff, a JSON. Left blank, you'll usually get the model's default — a tidy multi-heading list with a summary — because that's what got rated well during training. That default is fine for a briefing and wrong for almost everything else.

5. The bar. What counts as good, and what's forbidden. "Every claim needs a number", "no adjectives in the headline", "must fit in one screen", "must survive a hostile reviewer". This slot is what separates "acceptable" from "usable", and it's the one people skip most.

Five questions, in plain words: what to do, for whom, on what, in what shape, what counts as good.

What doesn't work as well as advertised

The costume. "You are a world-class copywriter with twenty years of experience" is the most-repeated prompt advice in existence, and it's the weakest item on this page. A 2024 study by Mingqian Zheng and colleagues — titled, memorably, When "A Helpful Assistant" Is Not Really Helpful — tested large numbers of persona prompts on factual tasks and found no reliable improvement in accuracy from adding a role. Personas do shift style and vocabulary, which is a real use. They don't make the model smarter. If you catch yourself writing "you are an expert", ask what you actually wanted from that sentence — usually it was the audience or the bar, and those you can state directly.

Politeness. "Please" and "thank you" cost nothing and change nothing about quality. Write however feels natural; just don't confuse courtesy with specification.

Length for its own sake. A long prompt full of vague adjectives is worse than four precise lines. Every sentence should remove a decision from the model's hands. If it doesn't, it's dead weight on the desk.

Threats and bribes. "This is very important to my career", "I'll tip you $200". Enough of these circulated as folklore that people forget the underlying point: what actually helps is describing the real stakes ("this goes to a client tomorrow, so no unverifiable claims"), which is just the bar slot again, written honestly.

Say what you want, not what you don't

Negative constraints work, but weakly, and they carry a specific failure: to satisfy "don't mention pricing", the model has to hold pricing in mind. A list of ten prohibitions is also a list of ten things now sitting on the desk.

Positive framing is more reliable. Instead of "don't be too formal" — "write it the way you'd explain it to a colleague at lunch." Instead of "don't make it long" — "150 words." Instead of "avoid clichés" — one example of the register you want. Keep prohibitions for genuine hard limits ("never invent numbers"), and carry the rest of the meaning in positive instructions.

Let it ask

The fastest fix for an under-specified request is to stop guessing what's missing and hand the problem back:

"Before you start, ask me the five questions whose answers would most change the result."

The questions that come back are a map of the slots you left empty — often including ones you hadn't thought of. Two minutes of answering them beats twenty minutes of iterating on a brief that was never complete. Use it whenever the task is big enough that a wasted round is annoying.

A companion move, worth stealing from How to Learn: ask it to restate the brief in its own words before working. The same trick that reveals whether you actually understand something reveals whether the request actually said what you meant. If the restatement is subtly off, you found the problem before spending an answer on it.

In practice

Write a brief, not a question. Run the five slots in your head: what to do, for whom, on what, in what shape, what counts as good. The one you skipped is usually the one that ruined the answer.

Name the reader first. It's the cheapest word-for-word improvement available.

State the bar explicitly. "Good means…" — one sentence, and the answer changes shape.

Prefer "do this" to "don't do that". Save prohibitions for hard limits.

When the task is big, make it ask you questions first. Then answer them and hand back the filled-in brief.

Check yourself

Close the article and answer in your own words:

  1. Why does a vague request produce a specifically average answer rather than a random one?
  2. Name the five slots of a brief and what each one decides.
  3. Which slot do people skip most often, and what does its absence cost?
  4. What did the 2024 persona study find, and what should you write instead of "you are an expert"?
  5. Why are negative constraints weaker than positive ones?
  6. What are the two moves that catch an under-specified brief before you waste an answer on it?

In short

  • A weak answer is usually a weak brief. Unmade decisions get made by the model, and it makes them by sliding to the most-written-about version.
  • Five slots: task (a verb and a result), context (who and what for), material (what it works on), format (what the output physically is), bar (what counts as good, what's forbidden).
  • Audience is the most under-used lever; the bar is the most-skipped slot.
  • Personas mostly change style, not accuracy (Zheng et al., 2024). Politeness, threats and length change nothing on their own.
  • Positive instructions beat prohibitions — a prohibition puts the forbidden thing on the desk anyway.
  • Make it ask you five questions before a big task, and make it restate the brief before working. Both catch a broken request cheaply.
  • Every decision you don't make, the model makes for you — and it makes it by rolling to the average.