Top Down Comms

---
name: top-down-comms
description: >-
  Structure any client-facing artifact the way MBB consultants do: governing
  thought first, action titles that carry the argument, scope exclusions as
  metadata rather than the opening move. Load this BEFORE writing a client
  proposal, one-pager, share page, update email, deck, or memo. This is about
  ARGUMENT STRUCTURE, not tone. Triggers: "proposal", "one-pager", "client update", "make this clean for them", "top-down",
  "McKinsey/BCG style", "restructure this", "fix the storyline".
---

# Top-down client communication

Tone skills tell you how it sounds. This one tells you what goes first, and why.
A perfectly-voiced document with an inverted argument still fails.

## The failure this exists to stop

A reviewer, on a proposal page that had already passed three visual rounds:
*"This is better now, but fix the storyline. Why should we start with this?
Think about this from the perspective of a McKinsey consultant, a BCG
consultant, and top-down communication."*

The page opened with **"No automated analysis of the source imagery"** — a scope
exclusion. It was there for a good reason: the recipient's own experts had
beaten a machine benchmark, and liability was their live objection. But a
reader's first impression was a disclaimer about something the document was
not, and they had to reach section three before learning what was actually
being proposed.

**Defensive openings feel responsible and read as weak.** The instinct to
front-load the caveat is exactly the instinct to override.

## Rule 1: the governing thought goes first

Minto's pyramid. The first substantive sentence is **the answer**, not the
background, not the topic, not the caveat. Everything below supports it.

| Opening | Verdict |
|---|---|
| "No automated analysis of the source imagery." | Exclusion. What it is not. |
| "Ranking incoming orders by contribution margin" | Topic label. Names a subject, asserts nothing. |
| "At full capacity the question is not how many orders you accept but which ones. The proposal: score every incoming request automatically by expected contribution margin." | The answer. Recommendation + reason, first thing on the page. |

Test: if the reader stops after sentence one, do they know what you want them to
do? If not, rewrite sentence one.

## Rule 2: action titles, not topic labels

Every section heading states its **conclusion**. A reader who reads only the
headings must get the whole argument. This is the single highest-leverage move
and the one most often skipped.

| Topic label (weak) | Action title (right) |
|---|---|
| Background | The bottleneck is capacity, not demand |
| Scoring logic | Five criteria decide what an order is actually worth |
| Example | Two requests the same morning, same effort, different margin |
| The test | Checkable in an hour, before anything is built |
| Effort | A few days to running |

**The headline-only test.** Strip the body. Read the titles in sequence. If they
do not form a coherent argument, the structure is wrong and no amount of body
copy will save it.

## Rule 3: SCR, and the complication is the whole job

Situation (what both sides agree is true) → Complication (why it cannot stay
that way) → Resolution (your recommendation). Most weak documents have a
situation and a resolution and no complication, so the recommendation arrives
unmotivated.

The complication should be arithmetic where possible: *"If you work orders in
arrival order rather than by margin, every thin-margin order you accept costs
you a fat-margin one."* That is a mechanism the reader can check, not an
assertion they must accept.

## Rule 4: exclusions and caveats are metadata

They belong in a scan strip near the top or a numbered section at the end. Never
in the opening position, never as a heading before the recommendation.

The **"at a glance" strip** solves this: a four-cell row directly under the
governing thought.

```
IN SCOPE            NOT IN SCOPE           DATA SOURCE            NEXT STEP
The order in        Automated analysis     Accounting exports,    20 to 30 invoices,
which requests      of the source          not project folders    about 1 hour
are worked          imagery
```

The exclusion is visible in the first screen, so nobody can claim it was buried,
but it is framed as scope rather than apology. Give it a full section at the end
if the objection is serious enough to deserve one.

## Rule 5: number the sections

01, 02, 03. Consultants do it because it makes a document referenceable in a
meeting ("go back to 02"). It also forces you to notice when you have eleven
sections, which means you have no argument, only a list.

## Rule 6: one falsifiable next step

End on something specific, small, and capable of failing. Not "let's discuss".
The strongest closer names the kill condition:

> If the ranking is wrong, the logic is wrong, and the idea is dead.

An offer that can fail is more credible than an offer that cannot, especially to
a room that has already been sold to.

## Rule 7: MECE, and cut to the load-bearing sections

Sections must not overlap and must not leave a hole in the argument. If two
sections make the same point, merge them. If a section supports nothing above
it, delete it.

Applied test from the same document: an unrelated reference case sat in the
middle of a proposal about order prioritisation. The reviewer's note: *"the text
is random ... either it goes in the email, or if it goes here, there has to be
clear context."* It supported a different governing thought, so it belonged in a
different artifact. It moved to the covering email and the page got shorter and
stronger.

## Checklist before shipping

1. First substantive sentence is the recommendation, not background or a caveat.
2. Headings read alone as a complete argument.
3. There is a stated complication, ideally arithmetic.
4. Exclusions live in a scan strip or a closing section, never the opening.
5. Sections are numbered and MECE.
6. The close is one specific, falsifiable next step.
7. Nothing on the page supports a different governing thought.

## Not covered here

Tone and register: this skill is about argument order, not voice. Length caps
for short client messages, and the build and publish mechanics of a share page,
are separate concerns.