The Pyramid Principle

Start with the answer, then give the few reasons that support it, then the evidence for each.

Readers get the conclusion first and can stop at any level; each layer only supports the one above it.

To an executive

Busy readers stop early. Lead with the answer, then give a few clear reasons, so a decision can be made from the first paragraph.

To an engineer

Open decision papers with the recommendation, then the key reasons that do not overlap, then evidence. If you cannot state the answer in one sentence, the thinking is unfinished.

The idea

Barbara Minto developed the Pyramid Principle while teaching writing at McKinsey. Ideas are easier to follow when they hang beneath a single point:

The answer — the one thing you want the reader to know or decide.
Key reasons — a small number of arguments that together support it, without overlapping.
Evidence — the data and analysis behind each reason.

Most technical writing runs the other way: background, analysis, options, and the recommendation on the last page. Minto's advice is to flip it. Her situation, complication, question opening gives just enough context to make the answer land.

Why it works

Busy readers stop early. Executives often read the first paragraph and skim the rest. Put what matters there.

It exposes weak thinking. If you cannot state the answer in a sentence, or the reasons do not add up to it, the problem is the analysis, not the writing.

Readers choose their depth. Someone who trusts you stops at the answer; a sceptic drills into the evidence.

Where it applies

Decision papers and architecture proposals, where a recommendation needs approval.
Status updates and incident summaries, where the reader needs the bottom line first.
Presentations, where the first slide should carry the message.

How to apply

Write the answer first, as a full sentence that a reader could act on.
Group the support into three or so reasons that do not overlap and leave no gap.
Order each group by importance, time or structure, and say which.
Open with situation and complication in a few lines, only enough to make the question obvious.

Example scenario

An architect's eight-page proposal to replace the message broker stalled for a month: the recommendation sat on page seven.

The rewrite opened with one line: "Move to a managed broker this quarter; it removes our top outage cause and costs less." Three short sections followed — reliability, cost, effort — each with its data. The steering group approved it in the first ten minutes of the meeting.

Questions to ask

Can I state my recommendation in one sentence?
What are the three or so reasons that support it, and do they overlap?
If they stop reading after the first paragraph, do they have what they need?

When not to use it

Exploratory documents, where you are thinking out loud and inviting ideas rather than recommending one.
Audiences that need to be brought along slowly, such as a team whose own design you are critiquing; leading with the verdict can close the conversation.

How it misleads you

A confident answer at the top can hide a weak analysis underneath. The structure makes an argument clear, not correct: check that each reason really supports the answer before you polish the pyramid.