Build longer messages as a pyramid: point, reasons, detail

You will be able to organise a longer email or document so the main point sits on top and each reason supports it.

Priya is an analyst at a bank in Raffles Place. Her manager asks her to find out whether the team should move its monthly reconciliation from spreadsheets to a new reporting tool. She spends a week on it and writes a two-page email. It opens with how the current process works, moves on to her meetings with IT, lists eleven things she found, and ends near the bottom with "so on balance I think we should switch, but only after the March close."

Her manager reads the first paragraph on the MRT, gathers that Priya has been busy, and replies "Thanks, let's discuss." The discussion takes forty minutes, most of it spent rebuilding an argument that was already in the email.

Lesson 1.1 put the point in the first two sentences, and for a short message that is enough. A longer piece such as a report, a proposal or a page of findings also needs an order for everything that comes after the point, and that order is what you'll learn here.

One idea on top, reasons underneath

The Pyramid Principle comes from Barbara Minto, who developed it while working at McKinsey and later set it out in a book of the same name. A piece of writing should have one governing idea at the top. Beneath it sit a few reasons that support it. Beneath each reason sits the detail that supports that reason.

Drawn on paper, it looks like an organisation chart, with one box at the top and a few boxes under it, each with more boxes of its own, so a reader can stop at whatever level gives them enough. Your manager might read only the top box. A colleague checking your numbers might follow one branch all the way down and ignore the others.

For Priya, the top box says: switch to the new reporting tool once the March close is done. Her email should have opened with that sentence.

Each reason answers the question the point raises

Once you state a point, the reader asks a question about it, usually why or how. "We should switch after March" raises "why?" "We can finish the close two days sooner" raises "how?" The boxes on the next level answer that question and nothing else.

That gives you a check on your reasons. Priya's eleven findings included the dates of her IT meetings, a note that the tool has a dark mode, and the fact that the vendor has an office in Singapore. None of those answers why the team should switch. They belong in an appendix, or nowhere.

When she asked herself the question, her real reasons came down to three. These figures are made up for the example:

The tool does the manual matching step, which takes the team about two days a month. It ends the copying of figures between files, which caused two of last quarter's errors. Waiting until March is over means nobody learns a new process during a quarter-end close.

All three answer the same question. When one of your reasons answers a different question from the others, it sits in the wrong place.

Group the detail instead of listing it

Most long work emails follow the order of discovery. The writer found fact one, then fact two, then fact eleven, and the email walks the same path. That feels natural, because it is how the work happened, but it leaves the reader to sort the facts into groups, and most readers won't do that for you.

Grouping is the writer's job. Take each loose fact and put it under the reason it supports. Aim for about three groups. Two is fine. Seven usually means some of them belong together, or some aren't reasons at all. Under each reason the detail can run as long as it needs to, because anyone who reads that far has chosen to go deeper.

In Priya's rewrite, the time estimate and the IT confirmation sit under the first reason. The error log sits under the second. The close calendar sits under the third. The dark mode note is gone.

Open with situation, complication, question

Some readers need a little context before the answer makes sense. Minto's opening for this has three short moves. The situation is something the reader already knows and agrees with. The complication is what changed or went wrong. The question is the one the complication raises, and your governing idea answers it.

For Priya: "Our monthly reconciliation runs on spreadsheets. Last quarter it took four days and two errors reached finance. So should we move to the new tool, and when? I recommend we switch after the March close." In a real email the question often goes unwritten, because the reader is already asking it.

Keep the whole opening to two or three sentences. If your situation runs to a paragraph, you're retelling history the reader already has. Her finished email has that short opening, then one paragraph per reason, each starting with the reason in a single sentence and the detail after it. Her manager can read four lines and approve, or read on to check the error log. Either way, the forty-minute meeting doesn't happen.

You need no software for this. A pen and the back of a printout will do. Write the top box first, as a full sentence. If you can't, you aren't ready to write the email yet. For the activity below, pick a report or long email of your own, ideally one that got "let's discuss" when you were hoping for a decision.

Turn one recent report or long email into a pyramid on paper: one governing point, up to three reasons, and the detail that belongs under each.

Course

Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).