Write messaging that only claims what you can prove

---
name: pumpgtm-brand-context
description: Apply PumpGTM positioning and a practical writing baseline to its GTM copy, content briefs, and product explanations. Use when work represents PumpGTM; use the relevant customer's own brand context for customer campaigns.
---

# PumpGTM brand context

Help a reader understand the buyer problem, the workflow, and the evidence behind the proposed outcome. This is a portable business context, not a biography or a requirement for unrelated work.

## What this package actually knows

The supplied PumpGTM project notes describe its positioning as helping teams find buyers and start conversations. They identify early-stage founders and GTM practitioners as the intended content audience and record X as a publishing channel.

Those notes also describe demonstration screens for research, an inbox, and sequences. A screen or a seeded demo number does not establish a live capability or a customer result. Confirm current functionality before describing specific integrations, automated actions, or product performance.

No approved price list, customer case study, service commitment, or complete brand manual was supplied. Leave those claims unresolved rather than filling them from another company's material.

## Build the working brand brief

Before writing, identify the speaker, reader, job, deliverable, intended action, and available proof. A PumpGTM brand post, a founder's personal post, and a customer's outreach message can have different speakers and audiences. Do not silently use one identity for another.

Use context in this order: the user's current brief, current approved product and brand material, supplied customer evidence, then the provisional defaults in this file. Record conflicts that affect a claim or deliverable. Ask one focused question when a conflict prevents correct work; otherwise proceed with the supported interpretation.

Capture the essential context in a working brief:

| Field | What to establish |
|---|---|
| Speaker | Company, founder, team member, or customer |
| Reader | Specific role and situation relevant to this piece |
| Reader's question | What they need to understand or decide |
| One takeaway | The idea they should remember |
| Product relevance | The confirmed relationship between the idea and the offer |
| Proof | Example, data, demonstration, or documented experience |
| Next action | A useful step appropriate to the reader's readiness |
| Constraints | Length, channel, format, tone, and supplied restrictions |

## Positioning and message architecture

Treat "finding buyers and starting conversations" as the supplied positioning boundary. Convert it into a specific reader problem before writing. Avoid expanding this into unverified promises about autonomous sales, guaranteed pipeline, or automatic improvement.

Build a message through five connected elements:

1. **Situation:** what the reader is trying to do.
2. **Obstacle:** the practical difficulty that makes the job costly.
3. **Mechanism:** the action or workflow that could help.
4. **Proof:** what can be shown or substantiated.
5. **Next step:** what the reader should do with the information.

Use the elements that serve the format. A short post might show only a situation, mechanism, and useful next step. A product page may need all five. Never pad a short artifact to satisfy a formula.

Distinguish category, capability, and outcome. "Helps teams find buyers" is positioning from supplied context. A named integration is a capability claim requiring current evidence. "Increases meetings" is an outcome claim requiring measured support. They are not interchangeable proof levels.

## Working editorial baseline

Use these defaults when the user has not supplied a campaign-specific voice. They are proposed writing conventions for this package, not historical findings about every PumpGTM publication.

- Open with a recognizable buyer or operator situation.
- Explain the practical action before naming an abstract benefit.
- Use concise sentences and concrete verbs. Introduce specialist language only when the intended reader uses it.
- Make one useful point per piece, with a next step suited to the reader's stage.
- Include a number only when its source, meaning, and time window are known.
- Prefer sentence case and restrained formatting. Match a different requested format when it serves the assignment.

Do not inherit another founder's personal history, audience statistics, posting schedule, affiliate relationships, fonts, or visual identity. Establish PumpGTM-specific design rules from an approved reference when design is part of the request.

## Voice dimensions

These proposed defaults make the writing concrete without copying another person's mannerisms:

| Dimension | Default behavior | How it appears in the work |
|---|---|---|
| Directness | Begin with the useful point | Name the task or friction in the opening |
| Practicality | Explain an action the reader can take | Show what to inspect, compare, or ask |
| Specificity | Use the narrowest supported statement | Name the workflow without inventing a result |
| Candor | Match certainty to the evidence | Distinguish an example from a finding |
| Restraint | Let the evidence create interest | Remove inflated adjectives and excessive calls to action |

Prefer terms such as account, buyer context, relevant conversation, workflow, evidence, and next step when they match the reader's vocabulary. Explain specialist terms for a general founder audience. Avoid empty claims such as "revolutionary growth engine" unless the user is explicitly requesting that style; even then, do not invent factual support.

If approved writing samples are supplied, derive actual voice traits from them. For each trait, record a short exact excerpt, the pattern it demonstrates, and the contexts where it applies. Distinguish a repeated pattern from a one-off flourish. Identify contradictions between samples rather than flattening them into a false universal rule.

## Content territories

Use these as starting directions, not a compulsory posting calendar:

- **Buyer selection:** how to turn an observable account signal into a fit hypothesis.
- **Conversation relevance:** how to connect context to a useful question.
- **Research practice:** how to distinguish source evidence from assumptions.
- **Workflow explanation:** how a confirmed process moves from research to action.
- **Learning from tests:** how a bounded experiment changes a GTM decision.

Choose a territory because it answers a reader question and the team has something supportable to contribute. Do not make every educational piece a product pitch. Do not publish repeated variants of a competitor's successful post under a new name.

## Choose the message by reader intent

| Reader situation | Useful message | Evidence to request |
|---|---|---|
| Uncertain who to pursue | Explain how to distinguish an account signal from a guess | A worked selection example |
| Struggling to start relevant conversations | Show the connection between buyer context and a question | An approved message example and its context |
| Comparing workflows | Explain what the product actually does at each step | Current product documentation or an inspected workflow |
| Evaluating an outcome claim | Show how the result was measured and bounded | Customer permission, baseline, denominator, and dates |

Draft from the approved product facts and the reader's problem. Do not copy a competitor's sentence pattern and replace its brand name.

An illustrative editorial line could be: "Start with the account signal. Build the conversation around what it suggests." This is proposed copy, not a product guarantee or customer quotation.

## Adapt to the deliverable

### Short social post

Open with a recognizable situation or a useful distinction. Show a compact mechanism or example. End with one proportionate action or question. Do not impose a fixed posting time, hashtag rule, keyword funnel, or engagement ritual copied from another brand. Match the user's requested channel constraints.

### Educational thread or article

State the question, explain the process in a useful order, show evidence, identify limits, and close with the action the reader can take. Each section should move the explanation forward. Avoid repeating the opening claim with different adjectives.

### Product explanation or landing-page copy

Identify who the offer is for, what job it addresses, what the documented workflow does, and what action is available. Keep feature descriptions aligned with the current product. If the product facts are incomplete, mark gaps in the handoff rather than filling them with plausible functionality.

### Conversation or outreach draft

Use a verified context cue, a tentative connection to the buyer's job, and an easy-to-answer question. Do not claim familiarity, hidden knowledge, or prior contact that does not exist. Keep the sender's role accurate and the proposed next step appropriate to the situation.

### Demo or video script

Map each spoken or written claim to the corresponding visible action. Put any necessary qualification close enough to the claim that the viewer can understand it. Separate illustrative data from customer evidence. A polished demonstration cannot substitute for a documented outcome.

## Keep proof visible

Maintain a compact claim register while drafting: proposed statement, supporting material, publication status, and unresolved qualification. Demo values remain explicitly identified as demonstrations; forecasts remain forecasts. Avoid presenting views as pipeline or replies as booked meetings.

When the brief lacks proof for a desired promise, offer a supportable formulation or flag the missing evidence. Do not add invented scarcity, endorsements, comparative superiority, or contractual assurances.

## Revision procedure

Audit claims before polishing style. Then check whether the opening identifies a meaningful situation, the explanation shows a mechanism, and the next step follows naturally. Remove unsupported superlatives, repeated promises, and unnecessary jargon. Preserve supplied factual meaning when changing the wording.

Return the finished artifact first. If useful, add a short review table with claim accuracy, audience relevance, specificity, originality of expression, and format fit. A score should not imply a measured likelihood of engagement or conversion.

Use [the messaging workbook](references/messaging-workbook.md) for the complete brand brief, channel templates, before-and-after examples, claim register, and a worked PumpGTM content brief. These examples are suggested copy rather than verified performance claims.

## Produce the requested artifact

Return the requested copy first. Add a short note only for assumptions or claims that need review. For a team handoff, include the audience, intended action, usable facts, and open questions. Keep channel-specific instructions scoped to that deliverable. Creating copy does not authorize posting, scheduling, or sending it.

## Completion check

The artifact should sound consistent, identify a specific reader situation, explain a useful idea, preserve factual meaning, and have a proportionate next action. Any unpublished claim needing proof must be visible in the handoff. A proposed voice convention must not be described as an established company rule without approved evidence.