There's a moment in most projects where the research is done and the brief still doesn't exist. The folder is full. The decisions are not made. Everyone knows roughly what they think, nobody has said it out loud, and the next step is a document that somehow has to contain all of it.

We used to get out of that moment by writing. Someone sits down, drafts a brief, sends it around, and the brief gets corrected into shape over a week. It works. It's slow, and the first draft always carries the writer's assumptions more than the team's decisions.

Lately I get out of it by being interviewed.

flip the direction

The habit with these tools is to ask them for things. Write this, summarize that, give me five options. The model answers, and the quality of the answer depends on how well I framed the question — which is the whole problem, because at this stage I can't frame it yet.

So I flip it. I hand the model everything we have — the research, the notes, the half-decisions sitting in the chat — and say: interview me about this until we both understand what we're making. Ask one question at a time. For each question, tell me what you'd answer and why. If you can find the answer in the material yourself, don't ask me, go look.

The move isn't mine. It's Matt Pocock's /grill-me skill, from his AI hero series on skills for engineers, and his one-line description is better than anything I'd write: it "takes a loose idea and interviews you until you can commit to it. You do not need a worked-out plan to start, because the session exists to produce one." We run a slightly different cut — his asks in rounds, ours asks one question at a time and attaches a recommended answer to each — but the idea is his, and it's worth reading his page before you try it.

Then I answer. Short answers, mostly. Yes. No, the other one. Four a month. Only her, for now.

Twenty minutes later there's a brief, and it's made of decisions we actually took rather than sentences someone wrote on our behalf.

loop diagram: hand over the research, notes and half-decisions; the model writes the next question after the last answer; if the answer is in the material it goes and looks instead of asking; otherwise it asks one question with the answer it would give; you answer in a few words, yes or no, and the no is information; that loops to the next question until you say move on with what you have, which gives a brief made of decisions plus a record of why; the saved questions become a reusable format. the check: a session with no pushback is one you did not need
fig. one question at a time, each with a default — the loop ends in decisions, not a draft

why one at a time

The "one at a time" part is the whole method. A list of fifteen questions is a form, and people fill forms badly. They skip the hard ones, answer the easy ones at length, and nothing in question nine knows what was said in question four.

An interview is different. Each question is written after the previous answer, so the branch you just closed stays closed and the next question lands on what's still open. Say the audience is local, and the next question isn't "who is the audience" — it's "then which local names do we lead with." The tree gets walked, not surveyed.

None of this is new. It's how a good discovery call works, how a good editor works, how any decent interviewer works. The reason it feels new is that we almost never get to be on the receiving end of it inside our own company. Everybody's busy producing. Nobody has time to sit across from you and ask the next obvious question.

The model has time.

the recommended answer does the heavy lifting

The second rule — tell me what you'd answer — matters more than it looks.

A bare question puts the work on you. A question with a recommendation puts a default on the table, and defaults are easy to react to. Most of the time you read it and say yes. Sometimes you read it and feel the no immediately — and that no is information you didn't have a second ago. You didn't know you cared about that until something proposed the wrong thing.

Taste works like this in general. It's far easier to recognize what you want when something is in front of you than to describe it to an empty page. The interview just keeps putting things in front of you, in order, until the picture is complete.

what comes out

A brief, yes. But also a record. Every answer is a line you can point to later when someone asks why the thing is the way it is. "Because we decided that in question six" is a better answer than "because it felt right at the time" — and it's the same decision.

The questions themselves turn out to be reusable, too. The ten questions that turn a pile of research into a content brief are more or less the same ten questions next month. Save them. The interview becomes a format.

the catch

  • It only works on real material. The interview is only as honest as what you hand over: actual research, actual numbers, actual constraints. Feed it a wish list and it will interview you about a wish list, very thoroughly.
  • Know when to stop. You'll reach a question you'd rather answer by doing the work. Stop there. Say "move on with what you have" and let the first draft absorb the rest. The interview is for the decisions that block the draft, not for every decision in the project.
  • The recommendation can lead you. A default is a nudge, and a confident wrong default is still a nudge. The fix is the same as always — the person answering has to actually have an opinion. This doesn't replace having one. It extracts it.
  • Passivity looks like progress. Pocock names this one directly: "the failure mode is passivity: answering 'agreed, agreed, agreed' for forty questions and coming out with a plan the agent wrote and you nodded at." His test for whether the session was worth it is the one I now use — "you disagree with something. A session with no pushback from you is a session you didn't need."