# Messaging Architecture

> 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.

- Skill: `dragoon0x/messaging-architecture` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dragoon0x/messaging-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/messaging-architecture/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/messaging-architecture

---


# 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)