# Messaging Framework: [Product or brand name]

> A messaging house that gives every team the same words for the same
> value: positioning statement, umbrella message, value pillars with proof
> points, audience-specific messages, elevator pitches, objection handling
> and vocabulary. Based on common product-marketing practice. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Build from the top down: positioning, then the umbrella message, then
  pillars, then proof. Each level must support the one above it.
- Every claim needs a proof point you can show a sceptical buyer. Remove
  claims you cannot prove.
- Test the messages with five to ten real customers before rolling out.
- This is an internal source document. Copywriters adapt the words; they do
  not change the meaning without agreement.
-->

| Field | Value |
|---|---|
| Framework ID | [MSG-2026-02] |
| Product / brand | [Name] |
| Owner | @product-marketing |
| Version | [0.1] |
| Status | [Draft / Tested / Approved] |
| Applies to | [Markets, languages, segments] |
| Last updated | YYYY-MM-DD |
| Related | [Brand guidelines], [GTM plan], [persona documents] |

## 1. Positioning statement

<!-- Guidance: The internal statement the whole framework rests on. It is not customer copy. Fill each part with something specific enough that a competitor could not claim it. -->

**For** [target customer] **who** [need or problem], **[product]** is a
[market category] **that** [key benefit]. **Unlike** [primary alternative],
**we** [primary differentiator].

*Example:* For engineering teams who keep documentation in scattered
files, [Product] is a Markdown workspace that keeps one live, private copy
of every document. Unlike wiki platforms, we store plain files the team
owns and can open in any editor.

## 2. Umbrella message

<!-- Guidance: One or two sentences that sit on the roof of the messaging house. Customer-facing, plain language, benefit first. -->

[*Example:* Write together in plain Markdown, keep every file, and never
wonder which version is current.]

Short form (under 10 words): [*Example:* One live document. Your files. No lock-in.]

## 3. Value pillars and proof points

<!-- Guidance: Three pillars is usual; four is the maximum people remember. Each pillar has a headline, a supporting sentence and proof points with sources. -->

| Pillar | Headline | Supporting message | Proof points | Source |
|---|---|---|---|---|
| *Example:* Ownership | Your files, your device | Documents are plain Markdown stored where you choose | Export any time; no account needed; open-source format | Product docs |
| *Example:* Collaboration | Everyone on the same page | Live co-editing and review comments in one place | Beta teams cut review cycles from 4 days to 1.5 | Beta study, n = 41 |
| *Example:* Speed | Opens instantly, works offline | Installable app with local storage | Opens in under 1 s on mid-range laptops | Internal benchmark YYYY-MM |
| [Pillar] | [Headline] | [Message] | [Proof] | [Source] |

### 3.1 Customer evidence

- [*Example:* "We moved 600 docs in an afternoon." Name, Role, Company (consent on file)]
- [*Example:* Case study: [Company] reduced documentation bugs by 30%]
- [Analyst note, award or certification, if any]

## 4. Audience-specific messages

<!-- Guidance: Same pillars, different emphasis per audience. Lead with what each persona cares about most. Keep meaning consistent across rows. -->

| Audience | Primary concern | Lead pillar | Key message | Call to action |
|---|---|---|---|---|
| *Example:* Engineering manager | Docs out of date with releases | Collaboration | "Ship docs with the code, reviewed in one place." | Start a team trial |
| *Example:* Technical writer | Tool friction | Speed | "Write in Markdown, see the preview, publish." | Try the editor |
| *Example:* Security lead | Data exposure | Ownership | "Nothing leaves the device unless you share it." | Read the security overview |
| *Example:* Finance approver | Cost and lock-in | Ownership | "Per-seat pricing, no migration cost if you leave." | See pricing |
| [Audience] | [Concern] | [Pillar] | [Message] | [CTA] |

## 5. Elevator pitches

<!-- Guidance: Three lengths for different moments. Read each aloud and time it. Avoid jargon; end with an invitation, not a monologue. -->

### 5.1 Ten seconds

[*Example:* [Product] is a private Markdown workspace where teams write
together and keep every file.]

### 5.2 Thirty seconds

[*Example:* Most teams keep docs in five places and nobody knows which copy
is current. [Product] gives you one live Markdown document the whole team
edits together, with history and review comments, and the files stay
yours: plain text, on your device, open in any editor. Teams in our beta
cut review time by more than half.]

### 5.3 Two minutes

[*Example:* Problem: describe the cost of scattered documents in the
listener's world (one or two sentences). Solution: what the product does,
in three short sentences mapped to the three pillars. Proof: one customer
story with a number. Difference: why this is not another wiki. Close: a
low-effort next step, such as "Shall I set up a workspace with your
current docs so you can see it on real content?"]

## 6. Objection handling

<!-- Guidance: Collect real objections from sales calls and support tickets. Answer with acknowledgement, a reframe and proof. Never disparage competitors. -->

| Objection | Acknowledge | Response | Proof |
|---|---|---|---|
| *Example:* "We already have a wiki." | Many teams do, and it works for intranet pages. | Keep it for that; use [Product] for docs that ship with your code and need review. | Integration guide; customer using both |
| *Example:* "Markdown is too technical for our team." | Not everyone knows the syntax. | The toolbar and live preview mean people can write without learning syntax first. | Onboarding completion 92% for non-engineers |
| *Example:* "Is it secure?" | You should ask that of every tool. | Documents are stored locally by default; sharing is explicit. | Security overview; open-source code |
| *Example:* "Too expensive." | Budgets are tight. | Compare with hours lost reconciling copies; free plan for individuals. | Time-savings calculator |
| [Objection] | [Acknowledge] | [Response] | [Proof] |

## 7. Vocabulary

<!-- Guidance: Words we use and words we avoid, with the reason. Align with brand guidelines; this list is usually product-specific. -->

| Use | Avoid | Reason |
|---|---|---|
| *Example:* workspace | platform, hub | Concrete and accurate |
| *Example:* private by default | bank-grade security | Verifiable, not hype |
| *Example:* plain Markdown files | proprietary format | Core differentiator |
| *Example:* team, people | users, seats (in customer copy) | Human; "seats" only in pricing |
| [Term] | [Term] | [Reason] |

## 8. Testing and approval

<!-- Guidance: Record how messages were validated and who approved them. Re-test after major product or market changes. -->

| Test | Method | Result | Date |
|---|---|---|---|
| *Example:* Message preference | 8 customer interviews | Ownership pillar ranked first by 6 of 8 | YYYY-MM-DD |
| *Example:* Headline A/B test | Landing page, 2 weeks | "One live document" +18% sign-ups | YYYY-MM-DD |

| Role | Name | Decision | Date |
|---|---|---|---|
| Product marketing | @name | [Approved] | YYYY-MM-DD |
| Sales | @name | [Approved] | YYYY-MM-DD |
| Brand | @name | [Approved] | YYYY-MM-DD |

## Standard and licence note

Based on common industry practice for product messaging frameworks
(positioning statement, messaging house, proof points and objection
handling). Template licence: MIT.