Pyramid Email

Pyramid Email

Turn any message into something a busy operator reads in 15 seconds and acts on.

The default failure mode is writing in story shape — setup, middle, payoff — which forces the reader to dig for the point. Pyramid shape inverts it: answer first, then reasons, then proof. Nobody has ever complained that a message was too clear.

The one rule: think bottom up, communicate top down.

Step 0: Establish the job of the message

Before writing a word, lock these four.

The Decision field is the load-bearing one. A message with no decision attached is a status update, and status updates get skimmed. If there is genuinely no ask, say so and shorten the message to three lines.

When the answer is genuinely missing from what the user gave you, what you do depends on stakes. For T1 and T2, infer the most likely governing thought, state your inference in one line, and proceed — a CEO should not have to answer a questionnaire to get a scheduling email. For T3, stop and ask exactly one question that surfaces the answer. Inventing a governing thought on a board memo, a personnel decision, or a partner negotiation means you made the call, not him, and he may not notice you did it. One question costs ten seconds. Getting it wrong costs a relationship.

Ask one question. Never two. If two feel necessary, the second one is usually answerable from context.

Stakes determine which tier you run.

Tier selection

Match effort to stakes. Most messages are Tier 1. Running Tier 3 on a scheduling email wastes everyone's time.

Announce the tier in one short line before the draft so the user can override it.

Run every pass for the tier inside a single turn. The method these passes come from was originally four separate prompts, run in sequence, with the human copy-pasting output between them. That handoff is the weakest part of the original system — a ten-minute workflow that requires four context switches gets abandoned by minute three. Do not reproduce it. Never deliver a pyramid and then ask whether the user wants the MECE audit run, and never hand back intermediate output for approval. Run the passes, apply what they find, deliver the finished draft plus the scorecard. The audit is visible in the scorecard, not in the conversation.

Construction order: derive bottom-up, emit top-down

This section exists because of a specific failure mode you are prone to, and it is worth understanding rather than just obeying.

You generate text left to right, each token conditioned on what came before. That makes context-then-conclusion the path of least resistance — you discover your own conclusion by writing toward it, the same way humans do. Left unchecked, this produces a draft that opens with background and lands the answer in the last line, which is precisely the shape this skill exists to destroy. A pyramid-shaped output is not the natural output of a pyramid-shaped instruction.

So separate derivation from emission:

1. Derive bottom-up, in scratch. Start from the proof the user gave you. Group it. Ask what each group establishes. Those groups become candidate supports. Ask what the supports collectively force as a conclusion. That conclusion is the answer.
2. Only then emit top-down. Answer, supports, proof, close.

If you find yourself writing the first sentence of the body before you can state the answer in one sentence, stop — you are drafting toward a conclusion you have not found yet, and the reader will have to travel the same distance you did.

Minto's phrase for the top of the pyramid is the governing thought. It governs in a strict sense: every element below it must answer the question that it raises. If a sentence does not answer a question the reader now has, it does not belong at that level.

Pass 1: The Pyramid (every tier)

Three levels. Not five. Not seven.

Top — the answer. One sentence. The recommendation, decision, or ask, stated flat. It must survive being read alone with zero context.

Middle — 2 to 4 supports. Each one is a reason the top is true. They must be MECE: Mutually Exclusive (no two supports say the same thing in different words) and Collectively Exhaustive (no obvious angle left uncovered). Three is the usual right number. Two works when both are genuinely load-bearing; more than four means you have not finished grouping.

Bottom — the proof. Numbers, names, dates, dollar figures, quotes, attachments. One line per support, maximum. If the proof needs a paragraph, it needs an attachment instead.

Verify proof against the shipped artifact, not against internal material. This is the failure mode that matters most, because a pyramid makes false claims more dangerous rather than less — the structure lends them authority and puts them in the reader's first fifteen seconds. Internal decks, strategy memos, pitch scripts, and past conversations describe what a product is meant to do; landing pages, pricing pages, and product UI describe what it does today. The gap between them is roadmap, and roadmap stated as fact to a customer is a promise someone on the team will have to break.

Before any support goes into an external message, check it against the live source — fetch the page, read the pricing, look at the actual UI. Where a claim cannot be verified, either cut it or mark it explicitly as needing confirmation. Never smooth over the gap. Two specific traps: capability claims lifted from vision documents ("one click publishes everywhere" when the product exports a file), and customer names lifted from pitch scripts rather than published references.

Then the close: one ask, one owner, one date. This is where most drafts leak.

Subject line = the top of the pyramid

Neither Minto nor the write-up this skill was adapted from mentions subject lines — Minto was writing for bound consulting reports. For email the subject is the single highest-leverage line, because it decides whether the pyramid gets read at all.

Rules:

• Compress the answer, not the topic. Vendor B — need your yes by Fri beats CRM vendor evaluation.
• 6 words or fewer, and 45 characters or fewer. Where the two conflict, characters win: mobile truncates around 35, so the answer has to land inside the first 35 characters and anything after that is a bonus the reader may never see.
• If a decision is needed, put the deadline in the subject.
• Never open with a label like Update:, Quick question, or Touching base.

Always deliver a subject line, even for Slack. In Slack it becomes the first line of the message, bolded, with the supports as separate lines beneath it — same pyramid, no subject field.

Word budgets

Structure earns brevity; it does not require it. But if a draft blows the budget, the pyramid is wrong, not the budget.

Pass 2: SCQ opener (T2 and T3)

Popular write-ups call this SCQA. Minto's actual framework is SCQ — Situation, Complication, Question — and the distinction matters mechanically. The Answer is not the fourth element of the introduction. The Answer is the governing thought at the top of the pyramid. SCQ's only job is to install a question in the reader's mind that your pyramid then answers.

Get this backwards and you write a four-sentence preamble that restates your recommendation twice.

1. Situation — one sentence the reader already agrees with. Non-controversial by design; it exists to establish shared ground, not to inform.
2. Complication — one sentence on what changed, broke, or is now at risk. This is what makes the Situation unstable.
3. Question — the question the Complication forces. Usually implied rather than written.

Then the pyramid answers it.

Three sentences plus the answer. Hard ceiling. If the opener runs longer than the pyramid it supports, cut it and lead with the answer cold.

The diagnostic: if you cannot state the Question in one sentence, you do not yet know what the message is about, and no amount of drafting will fix that. Go back to derivation.

Skip SCQ entirely when the recipient already knows the problem — most internal messages, and anything replying to someone who raised the issue themselves. Re-explaining a problem to the person who raised it reads as condescension.

Pass 3: MECE audit (T2 and T3)

Run this against the supports before delivering:

• Overlap check — do any two supports make the same argument in different clothes? Merge them.
• Gap check — what is the first objection a hostile reader raises? If the supports do not cover it, add it or pre-empt it in the close.
• Load check — could any support be deleted without weakening the top? Delete it.
• Ladder check (vertical logic) — does each support answer the question its parent raises? Minto's rule is that the pyramid works vertically: the governing thought provokes a question, the supports answer it, each support provokes a further question, the proof answers that. A support that is merely a related fact rather than an answer breaks the chain. Related facts belong in the attachment.
• Mixing check (horizontal logic) — a group of supports is either deductive (A, therefore B, therefore C — order matters, each depends on the prior) or inductive (three independent reasons of the same kind — order is flexible). Never mix the two inside one grouping. Mixed groupings are the most common reason an argument feels subtly wrong to a smart reader who cannot say why. Deductive chains are also fragile in email: break one link and the whole ask collapses, so prefer inductive groupings unless the logic genuinely is sequential.

A reader who spots a redundant support stops trusting the whole document in about four seconds. Cheaper to find it here.

Pass 4: Executive Test (T3 only)

Read the finished draft as the actual named recipient — not as a generic busy CEO. A board member, a ministry executive, and a partner CTO have different fears and different reasons to say no. If a contact or CRM record for the recipient is available, pull the relationship history before running this pass.

Answer these honestly and report the verdict:

1. After only the first two sentences, do I know what I am being asked to do? Yes / No.
2. What is the weakest, most redundant, or missing argument?
3. Would I act, ask for more info, or ignore?
4. What is my most likely reason to say no, and does the draft handle it?

If the verdict is ASK or IGNORE, rewrite the first two sentences and re-run. Do not deliver a draft that failed its own test — deliver the fixed version and note what you changed.

This pass also runs in reverse, at any tier. The T3-only rule above governs outbound drafting; a diagnosis of something inbound is cheap, so run it whenever asked. The user is themselves the busy executive the test simulates. When they forward something they received — a memo from the team, a partner proposal, a pitch — run the same four questions on it and report the verdict plainly. Two uses: it tells them in fifteen seconds whether the thing deserves his attention, and where the sender is on his team, the diagnosis is coachable feedback they can forward as-is. Give the verdict and the one structural fix, not a rewrite, unless they ask for the rewrite.

Where this method does not apply

The pyramid is built for a reader who can skim, triage, and abandon. Every mechanic behind it — primacy, decoding cost, decision fatigue — assumes someone scanning an inbox with the power to stop reading at any word.

A live talk is the opposite situation. The audience is captive, delivery is sequential, nobody can skip ahead, and persuasion is built through tension and release. Story shape is correct there: hook, problem, reframe, story, framework, proof, objection, offer, close. Opening a keynote with your conclusion throws away the tension every subsequent beat depends on. If the user hands you a speech, keynote, sermon, VSL, talk track, or demo script and asks for it to be tightened, do not impose answer-first — route to gatena-speech-writer for structure and hormozi-brain for offer sequencing.

Also outside scope: creative writing, and devotionals and newsletters — those run on reflection and cadence, not on an ask, so route them to a devotional or newsletter skill. LinkedIn posts go to a dedicated LinkedIn skill; the usual hook standard there is thesis-first, which is adjacent to answer-first but not the same thing.

The edge case worth getting right: written artifacts derived from a talk are in scope. The follow-up email after a keynote, the memo summarizing a pitch, the one-pager a prospect takes home — those get read, skimmed, and abandoned like any other document, so they get pyramided even though their source was spoken.

Spoken material is still useful here as a proof reservoir. A talk track that has survived live delivery contains battle-tested numbers, anchors, and objection handling. Mine it for supports, then verify each one against the shipped product before it goes into writing — a placeholder quote in a deck is not a testimonial.

Output format

Always deliver in this order:

Tier: [T1/T2/T3] · [one-line reason]

Subject: [≤6 words]

[Body]

---
Scorecard
Answer in sentence 1: [Y/N]
Supports MECE (2–4): [Y/N — note any merge or gap fixed]
One ask · one owner · one date: [Y/N]
Proof verified against live source: [Y/N — flag anything unconfirmed]
Levers used: [named, external messages only — or "none, internal"]
Words: [n] / [budget]
Recipient verdict: [ACT / ASK / IGNORE]  ← T3 only

Then, if useful, one line on what got cut and why. The user will sometimes want a cut fact back.

Never deliver a draft with a failing scorecard. Fix it first, then report the fix. The scorecard is there to catch you, not to disclose your misses.

If the user asks for options rather than a draft, give two variants with different strategic postures (e.g. "hold firm" vs "offer an off-ramp"), not two tones of the same message. Label what each one trades away.

Anti-patterns

Delete these on sight. Every one of them is throat-clearing that pushes the answer further down the screen.

Openers: Hope you're well / Hope you had a great weekend / I wanted to reach out / Just circling back / Just following up / Quick question / As we discussed / I've been thinking about / Per my last email

Hedges: I think we should probably / It seems like maybe / I could be wrong but / Just my two cents / If that makes sense / Does that work for you?

Closes: Let me know your thoughts / Happy to discuss further / Looking forward to hearing from you / Let me know if you have any questions

Replace every soft close with a hard one: a named owner, a specific action, and a date. Need your yes by Friday to hold the launch date does work that let me know your thoughts cannot.

One exception: when the message carries bad news, delivers a decline, or lands in a relationship that is currently strained, one line of genuine human warmth before the answer is correct — not throat-clearing. Warmth is not the same as vagueness. Keep the answer in sentence two, and keep the warmth specific enough that it could not have been copy-pasted to anyone else.

Register calibration

Assume the writer is a founder or senior operator. The pyramid stays constant; the surrounding tissue changes with direction of travel.

Writing down (team). Shortest form. Decision stated, not negotiated. Name the owner explicitly — an unowned ask in a CEO email creates diffusion, not action. No justification unless the decision reverses a prior one, in which case give the one reason it changed.

Writing across (peers, partners, portfolio). Full pyramid with an SCQ opener. The reader owes you nothing, so the supports carry the weight. Lead with what they get.

Writing up (board, investors, LPs). Pyramid plus explicit risk. Board readers distrust updates with no bad news in them, so surface the one thing that is going wrong and what you are doing about it. Numbers in the supports, always — a board support without a number is an opinion.

Cold outreach. Answer first still applies, but the answer is their outcome, not your ask. Compose with hormozi-brain for the offer construction and gatena-cookbook for the behavioural pass. Under 90 words or it does not get read.

Behavioural levers (external persuasion only)

The strict pyramid rule is: cut every word that is not the answer, a reason, or proof. That rule is right for internal messages and wrong for external persuasion, and the conflict is worth resolving deliberately rather than by instinct.

Take a price anchor — a videographer runs $500–$2,000 per video; this is $19. The anchor is not the answer, not a reason the recommendation is true, and not proof of anything. Strict Minto cuts it. It is also reliably the highest-leverage line in the message, because it supplies the reference point the reader would otherwise supply themselves, badly.

So allow a third class of content. Reception elements add no information; they change how the information already present lands. Permitted in external messages under three constraints:

1. Attached, never free-floating. Each one rides inside a support. The anchor sits in the cost support; the risk reversal sits in the ask. Neither gets its own paragraph, because a paragraph turns a lever into a pitch.
2. Capped at one each. One anchor, one risk reversal, one specificity multiplier. Past that they stop compounding and start reading as salesmanship, which triggers reactance — precisely the opposite of the intent.
3. Verified. See the proof-provenance rule above. A behavioural lever attached to a false claim is not persuasion, it is a liability, and the more effective the lever the worse the exposure.

Name the lever you used. Add it to the scorecard in three or four words. This costs nothing and makes the edit teachable — "moved the price after the anchor (Contrast Effect)" can be forwarded to whoever owns the message next and reused; "it reads better this way" cannot.

Which levers earn their place

That last row is the one to hold. Do not run behavioural optimization on your own team. Anchoring a decision for the people who report to you is manipulation of people who cannot opt out, and it is legible — someone always notices, and what they notice is that the CEO is running plays on them. Internally: plain answer, named owner, date.

Composition: for T2 and T3 external persuasive messages, run a gatena-cookbook pass, matching the practice used in the sales-pitch skills. Skip it for internal messages regardless of tier.

Reference files

• references/examples.md — before/after pairs across nine message types: team directive, reversal of a prior decision, bad news, board memo, investor update, cold outreach, follow-up on silence, decline, negotiation. Read this when the message type is unfamiliar or when a draft is structurally stuck.
• references/standalone-prompts.md — portable, corrected versions of the four source prompts plus a consolidated one-shot, for handing the method to the team, a Claude Project, or a different model. Read when the user wants to distribute the method rather than use it, or asks for "the prompt."
• references/why-it-works.md — the cognitive mechanics (cognitive load, primacy, decision fatigue, autoregressive drift), Minto's history with corrected citations, and the seven non-email artifacts worth rewriting with this method. Read when the user asks why the structure works, or wants to teach it.
• assets/ — six teaching slides, all safe to present. Slides 01–04 are adapted from the secondary write-up this skill was built from; 05–06 are rebuilt clean and replace two defective originals. assets/README.md captions each one and logs what was wrong with the originals. Read when the user is building a deck, running a team session, or wants a visual for a memo about the method.