Build a message hierarchy from a positioning decision, with the proof beside every line

Start from the positioning decision and its proof

Open your positioning brief. It names the buyer, the job, the alternative they compare you with, the difference you can support and the situations you exclude, and it ends with a proposed message. That lesson does not approve public copy, so keep the strategy, the proposed wording and any approved copy visibly separate in your files. A positioning memo records a decision; it does not prove every empirical claim inside it, so bring the product checks and permission-cleared buyer notes the decision rested on, the objections already in your notes, and any policy on who edits approved copy.

Crayon's positioning-versus-messaging explainer puts positioning first because messaging is built on it. That order does not make every wording edit a strategic reset. Reopen the positioning decision when its substance changes, meaning the buyer, the alternative or the supported difference. Wanting a better sentence for the anchor is copy work, and it goes through your copy-approval rule rather than back to the brief.

Work in the Claude Project that holds your company file and approved wording. Anthropic's Projects page says free accounts can create up to five Projects, and its Project management page says anything uploaded to a Project is used across the chats in it. A single chat with the same files attached works for a one-off pass; no Code, Research or connector is needed.

First ask Claude to restate the buyer, job, alternative, supported difference and exclusions from the supplied files, quoting where each appears, and resolve any conflict before drafting a word. The file you are building has six parts:

• Scope. Product, segment, market, date, version and owner.
• Anchor. The one-sentence message, marked proposed or approved.
• Claims. Each distinct claim with an ID, its supporting passage and source, the date checked, and qualifications such as plan or segment.
• Audience variants. One per audience that has the need, stored beside its claim ID.
• Objections. Each marked observed, hypothesis or open, with the answering passage or the evidence still needed.
• Usage rule. Fixed wording, adaptable wording, approver, source of truth, distribution owner.

Choose only the claims the evidence supports

Ask for a short anchor and as many independent claims as the evidence warrants, which may be one or two. Each claim explains one reason the anchor matters. Three or four pillars is an optional starting format, and nothing in the sources makes it an optimum. Wynter's messaging-hierarchy article argues that the pyramid model does not tell marketers how to write copy that resonates, and spends its remaining pages on clarity, relevance, value, differentiation and message testing. Merge candidates that say the same thing in different words, and do not invent a third pillar to fill a template.

One prompt earns a place here because it asks for output you can check:

Using the supplied positioning decision and proof, propose distinct message pillars. For each, quote its supporting passage and name the source. Put unsupported candidates under "needs evidence". For every audience variant, identify any factual claim it adds. Do not turn a proposed objection into a buyer quote.

The prompt makes the output checkable; it cannot enforce truth. Anthropic's guidance on incorrect responses says Claude can occasionally produce responses that are incorrect or misleading, and a quoted passage can mention a topic without supporting the claim placed on it. Read every quoted passage against its source. A claim whose passage does not hold moves to needs evidence, and that list goes back to research.

Change the audience emphasis without enlarging the claim

Write one version for each audience that has the need. 才流's guide to value propositions (in Japanese) says choosing which segment and which need you answer is mandatory, so an audience the decision excludes gets no variant. Store each variant beside its canonical claim ID with the qualifications attached: the plan, the date, the customer segment.

Then ask what new factual implication the variant adds. A shared claim ID does not cover a variant that promises more than the claim, so each variant is checked for its own extra implication. A variant that needs a new claim for its audience needs new evidence, or it is withheld.

An illustrative example, invented for this lesson and continuing the onboarding product from the positioning lesson. The verified capability is that each onboarding task shows its approver; there is no measured speed benefit.

Reuse the claim ledger if you already keep one; the hierarchy points at its IDs rather than starting a second evidence register. Writing "our recommendation" beside a line labels an editorial judgment honestly; it does not substantiate a product or outcome claim, which still needs evidence. The Product Marketing Alliance's messaging framework asks you to share messaging with product management so it accurately reflects the product's capabilities, then to refine it and apply it consistently across channels. This file supports that order.

Keep objections tied to what buyers actually said

Start with the objections already present in your notes: a buyer who says the spreadsheet works fine, a competitor's documentation that shows the same feature, a limit in your own product. Objections Claude proposes are hypotheses to test, never buyer quotations. Record an answer only when a supporting passage answers the objection; otherwise mark it open and name the evidence that would close it. A competitor's page that omits a feature is not proof the competitor lacks it.

Check what the message makes people expect

Ask a person in the intended audience what they think the product does, for whom, and what result it promises; their answer is the comprehension test. Check factual accuracy with the product owners. Claude can critique the drafts, and that critique is a draft review, not buyer validation. Revise confusing wording without silently changing the claim, and repeat the added-implication check on every revision.

Save the wording and decide who may change it

The owner decides which claims are fixed, which wording is adaptable, who approves a change and where the source of truth lives. Claude can format a policy you supply; it cannot invent authority your company never gave. Keep the rule short enough to sit at the top of the file:

• Fixed: the anchor and each claim sentence. Rewording goes through the named approver; reopen the positioning decision only when the buyer, the alternative or the supported difference has changed.
• Adaptable: the audience variants, within their claim, with no added outcome or comparison.
• Owner, approver, version number and the date of the last review.
• Source of truth: the shared location, plus every Claude Project copy that gets replaced when it changes.
• Distribution: a named owner sends each accepted revision to sellers and writers through the document or update channel they already read.
• Open objections: a seller records the objection and asks, rather than improvising a rebuttal.

The hierarchy is an internal reference; any public sentence taken from it still passes your normal approval. That distinction is our recommendation, not a sourced rule.

Save the reviewed file as Project knowledge and in the team's shared location, with its date, version and open questions. Anthropic's memory page says Claude can remember context from your chats and carry it into new conversations; the reason to save explicit files anyway is that a file has a version and a date a reviewer can open. On the next task, ask for the exact approved passage and version before reusing it.

Recheck the file when the positioning decision changes, when a cited source changes, or when a seller reports an objection it does not answer. Update the source line and the affected variants together, then replace the managed copies. This manual workflow has no configured monitoring or delivery step: a reminder prompts the review, and the owner still checks the sources and sends the accepted revision. When the message feeds a specific launch, the launch brief lesson carries it into dates, assets and owners.

Where competitive battlecards fit later

Positioning and hierarchy ownership stay with the team. Steve does not offer a dedicated feature for creating or governing a message hierarchy. It lets you add project resources to a battlecard, but that is generic intake rather than a hierarchy with locked language or versions. What exists nearby is Steve's Objection Handling battlecard, which pairs competitor objections with rebuttals. It does not inherit this hierarchy. If turning competitive evidence into seller objection answers is the recurring job, Steve's competitive intelligence product is the adjacent option to evaluate; the DIY alternative is a shared, reviewed card that links back to this file.