How to Build a Messaging Hierarchy

Your website promises teamwork; your sales deck promises speed. A messaging hierarchy decides which idea leads and how the other supports it. Stewart Butterfield's memo to the team building Slack offers a way to think about that priority.

His July 31, 2013 memo to Tiny Speck, about two weeks before Slack's preview release, was called "We Don't Sell Saddles Here." A saddle maker, he wrote, could sell saddles or could sell horseback riding.

Butterfield argued that his team was selling organizational transformation, and that the set of software features was the saddle.

He applied the idea to what people would meet first, from signing up to first use. You can use his memo as a prompt when planning your own page: what should people understand about the change you offer before they inspect individual features?

What is a messaging hierarchy, and what comes before it?

Annika sits in her car outside a veterinary clinic, the demo laptop still on her knees. Her salesperson promised speed while her website promised teamwork. The practice manager asked, "Which scheduling tasks would leave our front desk, and how would the team handle what's left?"

Annika and her company, Tidewell, are invented for this lesson. Tidewell makes scheduling software for independent vet clinics, and every line of its copy below is hypothetical.

Everyone at Tidewell was describing a real part of the product. The practice manager needed to see how faster scheduling and teamwork connected in a clinic's day; the pitch and page had left that connection unexplained.

Annika's hierarchy will have three levels, plus the audience it's written for. The core message sits at the top. For this exercise, put two to four supporting claims beneath it, called pillars, with evidence under each claim.

Before she ranks anything, she needs the decisions covered in positioning. The positioning quickstart guide in this lesson's sources breaks those into five connected parts: competitive alternatives, differentiated features, the value they enable, target segments and market category.

Where it sits

1. Published copy: pages, emails, ads, scripts
2. Messaging hierarchy: what to say, in what order
3. Positioning: what we are, for whom, against what
4. Customer research: what people actually said

Each layer rests on the one under it, so weak research can't be rescued higher up.

Those decisions give Annika a basis for ranking speed and teamwork. She needs to know which clinic she's addressing and which scheduling tasks it wants to change before deciding what comes first.

Your value proposition is a close relative. It's a sentence you might publish, and the hierarchy is the internal page that keeps the evidence and the ranking behind that sentence.

Treat the hierarchy as an editorial planning tool; the sources here don't establish that the document itself lifts sales. Annika uses it to settle which claim her salesperson and website will explain first.

Why order matters more than the list

Annika puts the possible opening claims side by side: faster scheduling and better teamwork. She asks which one the clinic's complaint supports, then checks what the product can demonstrate before giving either the top line.

Nielsen Norman Group's inverted-pyramid guidance says to put the most important information first and let the detail follow. Apply that by asking what a reader should understand if they read only the opening section.

An older NN/g study of web reading found that 79% of test users always scanned, and only 16% read word by word. Keep the study's age in mind, and plan for many readers taking away your first idea and maybe your second.

Butterfield gave his team organizational transformation as the priority, then connected it to the experience of using Slack. Annika needs to choose a customer outcome that her website and her salesperson can both explain.

Worked example: a whole hierarchy

Annika's interviews keep turning up one complaint. Front-desk staff spend their mornings on the phone moving appointments and chasing no-shows while pets wait in the lobby, and their alternative is a paper book or the clumsy calendar inside an old practice-management system.

Annika first tries "The all-in-one platform for modern veterinary practices." She returns to Butterfield's saddle analogy and asks what clients and staff can do with these features. Her next draft names the scheduling work and keeps compatibility in view.

Tidewell's working hierarchy

Tidewell moves booking and waitlist work online alongside your clinic's existing records system.

Clients can manage appointment changes themselves

Canceled slots go to the waitlist

Keep your existing records system

Clients can manage appointment changes themselves

• Clients book and rebook online, day or night
• Text reminders let clients confirm or reschedule with one tap
• Evidence to record: a client completing the booking flow

Canceled slots go to the waitlist

• Canceled slots are offered to the waitlist automatically
• Evidence to inspect: a cancellation followed by its waitlist notification
• Pilot clinic's filled-slot figure: needs proof before publication

Keep your existing records system

• Imports your existing client list
• Runs alongside your current records system
• Evidence to prepare: an import demonstration with representative records

The draft separates demonstrable functions from a clinic result that still needs verification.

When someone proposes a section about the analytics dashboard, Annika asks which pillar it serves. If it serves none, it moves down the page or out.

The third pillar answers the migration worry in Annika's interviews. She puts the import demonstration beneath it so the next writer can inspect how existing records are handled before describing the switch.

The waitlist pillar promises an action the software performs. A claim about filling more slots would need outcome evidence from clinics. Annika keeps that gap visible in the internal draft and leaves the unverified result out of the page copy.

How to build yours, in order

Start with customer records and a list of what you can actually prove. If you've done the work in turning research into copy, you already have it. Annika needs those records to check whether phone interruptions deserve the emphasis she's proposing.

Next, write the core message badly, ten times. Complete "For [audience], we [do what] so that [result], unlike [alternative]." Then rewrite it in plain words until a customer could repeat it to a colleague.

Pile up every claim you might make and sort them into groups. Choose two to four groups that support the core message, combining claims that answer the same customer question. Put other features in a separate list for later sections rather than forcing each into a pillar.

Attach proof to each claim, and be strict about it. For Tidewell's import claim, attach a demonstration using representative records. Mark "a new hire can book their first appointment without training" as unverified until you've observed a suitable check.

Then rank again using the audience's recorded questions. If keeping the records system is the manager's first concern, Annika can lead with that pillar in the demo and open its import demonstration before discussing the dashboard.

Writing pillars

Do

• Write each pillar as a claim a reader could disagree with
• Use customers' words wherever you can
• Keep the same terms across the whole page
• Mark any claim you can't yet prove

Avoid

• Use department names as pillars, like 'Support' or 'Security'
• Write adjectives with nothing underneath, like 'powerful'
• Add a pillar to keep an internal team happy
• Treat the document as finished copy to paste into a page

How do you adapt a messaging hierarchy for different audiences?

You don't need a new hierarchy for every reader. Keep the core message stable, then change the order of the pillars and the proof you show first.

A clinic owner asking about cancellations can see the waitlist workflow first. A practice manager asking about the switch can start with the import demonstration. Each gets evidence for the question they brought to the conversation.

Keep the same core sentence on both versions of the sales deck, with the relevant pillar immediately below it. If two audiences need incompatible promises, go back to positioning before you rearrange the page.

Questions to take into clinic interviews

Clinic owner

What happened to the last appointment slot canceled on the day?

Practice manager

Walk me through the last time someone called to move an appointment.

Observe the workaround

Which system did you open, and what did you enter there?

Proposed interview prompts; record actual answers before ranking the claims.

These interview prompts check whether Tidewell's proposed priorities match what customers say.

Awareness changes the order as well. Someone still using a paper book may need to see how online booking works. A vendor comparison may start with compatibility; the five levels of awareness lesson helps you choose which explanation belongs first.

From document to page

Butterfield carried his argument into signup and first use. Apply that check to your hierarchy: does the next screen help someone make the change you've promised? For Tidewell, Annika starts with the hero below and checks the booking flow that follows.

From hierarchy to hero

Hierarchy language

Tidewell moves booking and waitlist work online alongside your clinic's existing records system.

Published copy

Headline: Let clients book without calling. Subhead: Clients book and rebook online, and confirm appointments through text reminders. Offer canceled slots to your waitlist while keeping your existing records system.

The hero leads with the booking pillar and carries the waitlist and records promises into the subhead.

The pillars usually map onto page sections, as described in landing page anatomy, with proof placed beside each claim. The same outline can steer a sales deck and a welcome email, so the salesperson and the website start from the same first idea.

Keeping it alive

Keep your hierarchy to one page with a date and an owner at the top, and link it from the brief template. Annika names herself as the owner so questions about the pilot figure return to the person gathering its evidence.

Revisit it when a new competitor appears or an objection keeps coming up on sales calls. When research changes a priority, write down why, so the next writer can follow the decision.

Read a recent email or landing page against the document and check that its opening serves the same core message. If Tidewell's email leads with teamwork again, ask what customer evidence prompted the change before adding that claim to the hierarchy.

Is this hierarchy ready?

• It names one specific audience
• The core message fits in a sentence a customer could repeat
• It explains what changes from the audience's current alternative
• There are no more than four pillars
• Every published claim has proof; gaps in the internal draft are marked
• Sales and support read it and recognize their customers
• It has an owner and a date

If the team is mixing category, benefit and uniqueness into one sentence, separate positioning, value proposition, and USP before you arrange the hierarchy.

Ask for the missing proof

Choose one product and one audience. Write the core message at the top of a sheet, with two to four pillars below it. Attach evidence to each pillar, marking anything you can't show today as "needs proof."

Show it to the person closest to customers and ask, "What's wrong with this?" The positioning topic covers the earlier decisions if their answer sends you back a step.

Annika puts the core sentence at the top of the sales deck and above the website hero. Her salesperson now opens with booking without calling, and so does the page.

At the next demo, the practice manager asks, "What happens to our existing records?" Annika opens the import demonstration and shows how Tidewell runs alongside the clinic's current system.