Clear Recommendations Start With the Answer

Most of us have read a recommendation that saves its point for the last page, which raises the question this post answers: how should advice be written so a busy reader can act on it? State the answer first, then give the few reasons that support it, each summed up in one sentence that the details beneath it prove. The method comes from Barbara Minto's book The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving, and it is how we now start every new proposal and draft our client reports.

Readers look for the point before they weigh the reasons

A reader takes in a document one sentence at a time and keeps asking how each sentence connects to the one before it. When the main point comes first, every sentence after it has somewhere to go: it is a reason for the point, or evidence for a reason. When the point comes last, the reader has to hold every detail in mind while guessing what it will turn out to support, and plenty of readers stop before they find out.

That cost falls hardest on the people who make decisions. A board member, a program director or a business owner usually has minutes, not an afternoon. If the first paragraph says what we recommend and why, they can decide whether to read on, hand the details to someone else, or simply say yes.

One idea sits at the top, and each group beneath it makes a single point

Picture the document as a hierarchy. At the top sits one governing thought: the sentence you most want the reader to remember or act on. Directly under it sit the key points, usually two to five, and each one answers the question the governing thought raises in the reader's mind, whether that question is why, how or what next. Under each key point sit the facts or smaller steps that support it, and so on down the page.

Three habits keep the structure honest:

• Every point should say what the points beneath it add up to. If you cannot write one sentence that a group sums to, the group is not finished.
• A group holds one kind of idea: all reasons, all steps or all problems. A list that mixes a cost, a deadline and an opinion is three lists pretending to be one.
• A group follows an order you chose on purpose: the sequence of the steps, the parts of a whole taken in turn, or the most important item first.

Writing this way also tests the thinking behind it. A heading such as "Budget" or "Findings" only names a topic. A point such as "The pilot covered its own costs in the first season" makes a claim the reader can accept or challenge. That is why every point in a pyramid is written as a full statement.

The opening reminds the reader of what they already know

Before the answer comes a short introduction. Its job is to recall what the reader already knows, not to tell them anything new, and Minto frames it as a brief story in three parts:

• Situation: where things stand, described in terms the reader already accepts.
• Complication: what changed, or what now stands in the way.
• Question: what the reader needs to know as a result. The final draft often leaves it unspoken, but the writer should always be able to name it.

The answer to that question is the governing thought. A good opening runs a few sentences. If it fills a page, it is probably delivering news that belongs further down, or answering a question nobody asked.

It pays to draft in a different order from the one the reader sees. Write the question first, then the answer, then the Situation and Complication that lead to that question, and revise all four until they fit, so the story leads straight to a question you have already answered. Only then write the key points.

A fictional food pantry shows the whole structure on one page

Here is an example we made up for this post. Riverbend Community Pantry is a fictional neighborhood food pantry, and its volunteer coordinator is writing to the board. The situation: volunteers sign up for shifts on a paper sheet at the front desk. The complication: since the pantry added a Saturday distribution, several shifts each week go unfilled, and the coordinator spends evenings phoning people to cover them. So the board's question is how the pantry can fill its shifts reliably.

The coordinator's answer, the governing thought, is to move shift sign-ups to an online scheduler before the spring season, so volunteers can claim shifts from their phones and gaps show up a week ahead. Beneath that answer, the support reads from the top down:

1. Volunteers can sign up whenever it suits them, not only when they are at the pantry.
   1. Today the sheet can only be seen during a shift, so people who cannot come in cannot sign up.
   2. A link in the weekly volunteer email reaches everyone at once.
2. The coordinator sees open shifts early enough to fill them.
   1. Every open shift for the coming week appears on one screen.
   2. Each volunteer gets a reminder the day before a shift.
3. The change is small enough to make before spring.
   1. The scheduler's free plan covers a pantry of this size.
   2. The paper sheet stays at the desk for the first month, for volunteers who prefer it.

The message ends with the next step: the board approves the change at its March meeting, and the coordinator sets up the first month of shifts the following week.

Notice what the example leaves out. There is no section called Background, and no heading that only names a topic. Read just the first line of each group and the argument still holds: the scheduler reaches everyone, it shows the gaps early, and it can be running by spring. That is the test to apply to any document. If the top two levels make sense without the details, the details are in the right place.

We draft new proposals and reports with the same structure

Every new proposal starts from a written storyline: where the client stands, what has changed, the one question the work has to answer, and our answer to it. An automated check in our codebase fails when a new proposal is missing that storyline or any of those four parts.

A new proposal's one-page summary opens with our recommendation, so a client can weigh what we suggest before reading the detail.

We draft client reports with the same outline: the bottom line first and the next step last.

None of this guarantees that a recommendation is right. What the structure does is put the reasoning where a reader can see it and push back on it, which is the reason to write it down in the first place.

Four questions can test a recommendation before it goes out

You can apply the method without any special software. Before you send your next recommendation, ask:

1. Does the first paragraph state the answer, or only the topic?
2. Does every key point answer the same question about that answer, such as why, how or what next?
3. Does each group hold one kind of idea, in an order you chose on purpose?
4. Does each heading make a point, rather than name a section?

If any answer is no, fix the structure before you polish the sentences. If you are working through a decision of your own and want a second reader, tell us about it, or see how we run consulting engagements.