| name | messaging-architecture |
| description | Build a messaging architecture including hero message, pillars, proof points, and audience variants. Use whenever the user mentions messaging architecture, messaging hierarchy, messaging framework, or needs to organize what to say across pages, audiences, and channels. |
messaging-architecture
messaging architecture is the structure that makes the copy consistent across pages, decks, ads, and conversations. one message, told from different angles, at different depths, for different audiences.
the hierarchy
hero message
the one line at the top of the home page, the one line you'd use at a conference.
three pillars
the three claims that hold the hero up. each is a substantive promise.
proof points (under each pillar)
specific evidence, capabilities, or outcomes that back the pillar.
variants
how the hero and pillars shift for different audiences or channels.
designing each layer
hero message
- 5-15 words
- captures the most important promise
- audience-agnostic if possible (but if your audience is segmented, pick the primary one)
- should make a stranger ask "tell me more"
pillars
- 3 is the sweet spot. 4 is the maximum. 2 risks feeling thin.
- each pillar is a claim, not a feature.
- pillars should not overlap. if two pillars cover the same ground, combine them.
- each pillar should be defensible — there should be real proof points under it.
example structure:
hero: "the spreadsheet built for product teams"
pillar 1: built to think in product objects, not rows and columns
pillar 2: shareable without the chaos of access management
pillar 3: extends with code when spreadsheets stop being enough
(each pillar then has 3-5 proof points)
proof points
- specific. a feature, an integration, a customer outcome, a technical fact.
- not adjectives.
- ideally: 3-5 per pillar. if you have 10, the pillar is too broad. if you have 1, the pillar is too narrow.
audience variants
if you serve multiple audiences, the hero and pillars may need different framings:
default hero: "the spreadsheet built for product teams"
for engineering audience: "the spreadsheet that doesn't fight your stack"
for product manager audience: "stop maintaining spreadsheets, start shipping decisions"
don't multiply variants beyond what you can keep consistent. two or three audience framings is usually enough.
output
hero
primary: [line]
alternative angles tested: [list with rationale]
pillar 1: [claim]
proof point: [specific]
proof point: [specific]
proof point: [specific]
pillar 2: [claim]
[same shape]
pillar 3: [claim]
[same shape]
audience variants
audience A: hero + pillar emphasis
audience B: hero + pillar emphasis
channel variants
homepage: [how to expand into sections]
ad: [the shortest version]
pitch deck: [the slide-by-slide version]
sales conversation: [the question-and-answer version]
what we say no to
things people might expect us to say but we don't, with the reason
what to avoid
- pillars that are really features
- pillars without proof points
- different teams using different language for the same things (sales says X, marketing says Y, product says Z)
- variants that say different things, not the same thing in different shapes
- updating the messaging once a year (it should evolve quarterly as you learn)
