| name | answer-first-structure |
| description | Decide the bottom line before writing and put it in the first sentence, with only decision-relevant support after it. Use this whenever producing anything a reader will consume to decide or act — reports, emails, summaries, memos, recommendations, status updates, research findings, analysis writeups, PR descriptions, incident notes. Trigger especially on signals of a time-pressed reader ("my VP has 30 seconds", "keep it brief", "TL;DR", "what should we do?"), but also when no such signal is given — readers are always more time-pressed than the writer assumes, so apply it to any question that has an answer or any task that ends in a recommendation. |
Answer-First Structure
Readers decide in the first seconds whether to keep reading, and many stop there. If the bottom line arrives last, the time-pressed reader acts on an incomplete picture — or doesn't act at all. Writing the answer first also disciplines the writer: you cannot state a conclusion in one sentence until you have actually reached one, so weak or hedged thinking surfaces before the reader sees it, not after.
Process
- Before drafting anything, answer the reader's question in one sentence. If you can't, the analysis isn't done — finish it first. This is the checkpoint: no conclusion, no draft.
- Commit to that sentence and make it the opening line of the output. Not context, not background, not what you did — the answer or recommendation itself.
- Build the structure under it: pick the 2–4 points the reader needs to trust or act on the conclusion, ordered by decision relevance, not by the order you discovered them.
- Cut everything that supports your process rather than the reader's decision — how you searched, what you ruled out along the way, how careful you were. If a caveat changes the decision, keep it and put it early; otherwise drop it.
- Reread only the first sentence and ask: does a reader who stops here take the right action? If not, rewrite the first sentence, not the rest.
What this looks like
- Email to a busy exec: "Recommend we delay the launch two weeks; the payment vendor won't be certified before the 20th." Then two lines of support, not a timeline of meetings.
- Research summary: "The evidence favors option B: it's cheaper at our scale and the main risk (vendor lock-in) has a workable exit." Sources and comparison follow for those who read on.
- PR description or incident note: "Fixes the checkout timeout by raising the connection-pool cap; root cause was pool exhaustion under concurrent sessions." Details of the investigation only as far as a reviewer needs them.
Output rules
- Never narrate your own diligence ("I carefully verified...", "having thoroughly checked...", "as instructed, I..."). The discipline shows in the work product; describing it spends the reader's time proving nothing.
- The checkpoint work — reaching the conclusion, weighing caveats — happens before or while producing the answer. Only its results appear in the output, and only where they change what the reader does.
- Keep length proportionate to the task: a one-question email gets a few sentences; a decision memo gets a page. Support may be as deep as the decision warrants, but it always comes after the answer.
- If the honest bottom line is uncertain, say that in the first sentence too ("Inconclusive — here's what would settle it") rather than burying the uncertainty under structure that implies confidence.
Grounding: BLUF (US Army AR 25-50); Barbara Minto, The Pyramid Principle (answer-first structure); Anthropic, Prompting Claude Fable 5 ("Lead with the outcome").
