messaging-framework

---
name: messaging-framework
description: Builds a messaging house from agreed positioning - umbrella message, three supporting pillars tied to customer value, rated proof points per pillar, audience variants, and usage rules. Use when aligning marketing, sales, and product on what to say, before writing launch copy, or when teams describe the product inconsistently.
---

# Messaging Framework

A procedure for translating positioning into a reusable messaging house: the single source teams draw from when writing web pages, sales decks, emails, and announcements. The framework separates what is claimed from how strongly it can be proven.

## When to use

- Positioning is agreed and teams need consistent language to execute it.
- A launch requires copy across many channels and audiences.
- Sales, marketing, and product describe the product differently.
- A voice or copy review keeps finding off-message claims.

Do not use it to decide positioning (competitive alternatives, target customer, category); if positioning is unclear, resolve that first, because messaging built on contested positioning will be contested too.

## Inputs

- **Positioning** — target customer, competitive alternatives, unique attributes, value themes, market category. Required.
- **Proof inventory** — customer results, case studies, testimonials with permission, benchmarks, certifications, third-party reviews, product facts. Required.
- **Audiences** — buyer roles or segments (for example, economic buyer, user, technical evaluator). Recommended.
- **Voice guide** — for wording style. Optional.

## Procedure

1. **Write the umbrella message.** One sentence that captures the core value for the target customer in the chosen category frame. It should be true, specific, and defensible against the main alternative. Draft three options and pick one by testing which makes the value most obvious to someone who knows nothing about the product.
2. **Define three pillars.** Each pillar supports the umbrella message and maps to one value theme from positioning. Name each pillar with a short customer-outcome phrase rather than a feature name. Three is a convention for memorability; use two or four only if the positioning genuinely requires it.
3. **Describe each pillar.** Write a two- or three-sentence explanation: the customer problem, how the product addresses it, and why that is better than the alternative.
4. **Attach proof points.** For each pillar list proof points and rate each: **strong** (quantified customer result or independent validation that can be cited), **moderate** (named testimonial, demonstrable product fact), **weak** (anecdote, internal opinion), **missing**. A pillar without at least one strong or moderate proof point is a risk to flag, not to hide. Record the source and any usage restrictions (customer approval, expiry date).
5. **Map features to pillars.** List the capabilities that deliver each pillar, so product teams can see where launches fit and marketers know which features support which claims.
6. **Create audience variants.** For each audience, write which pillar leads, the umbrella message adapted to their priority (an economic buyer hears cost and risk; a practitioner hears time and ease), the top objection, and its response.
7. **Write supporting assets.** A 25-word and a 50-word description, an elevator pitch (about 30 seconds spoken), and a short boilerplate paragraph, all derived from the house.
8. **Set usage rules.** Approved terms and terms to avoid, claims that need legal review, proof points that require permission or have expiry dates, and who owns updates.
9. **Test comprehension.** Recommend a quick test: show the umbrella message and pillars to five people in the target audience and ask them to explain back what the product does and why it is different. Revise wording that is misunderstood.

## Expected output

```markdown
# Messaging House: <product> — <version/date>

**Umbrella message:** ...

| | Pillar 1: <outcome> | Pillar 2: <outcome> | Pillar 3: <outcome> |
|---|---|---|---|
| Description | | | |
| Key features | | | |
| Proof points (rating, source) | | | |

## Audience variants
| Audience | Lead pillar | Adapted message | Top objection | Response |

## Short descriptions
25 words · 50 words · elevator pitch · boilerplate

## Usage rules
Approved / avoid terms; claims needing review; proof restrictions; owner.

## Gaps and risks
```

## Constraints and limitations

- Every proof point must trace to evidence the user supplies; never invent results, quotes, or customer names.
- The framework is internal guidance, not customer-facing copy; external copy still needs writing and review.
- Comparative and superlative claims need substantiation and often legal review.
- Messaging needs revisiting when positioning, product, or proof changes.

## Examples

Product: a contract review tool for in-house legal teams. Umbrella: "Review routine contracts in minutes with your own playbook, so lawyers spend time on judgement, not redlines." Pillars: "Faster turnaround" (proof: customer-reported reduction in NDA review time, strong if the customer approves citing it), "Your standards, applied consistently" (proof: playbook feature demo, moderate), "Safe for confidential data" (proof: security certification report, strong; requires current certificate date). Economic buyer variant leads with turnaround and outside-counsel spend; practitioner variant leads with consistency.

• SKILL.md 5 KB
• manifest.yaml 2 KB