Messaging hierarchy for product launch approval

Use this workflow to produce one messaging hierarchy that reviewers can approve, amend or reject. It is for product marketers and brand leads who need to turn scattered launch inputs into decisions before ad copy and landing pages are written.

The output is not a pile of copy options. It is a short decision document: the audience to prioritise, the promise to lead with, the proof required to support it, the objections to answer and the claims that need approval.

1. Assemble the source pack

Create one folder or working document with only the material that should influence launch messaging. Name each source clearly and add its date.

Include:

• Product notes: what changed, who can use it, dependencies, known gaps and rollout details.
• Customer research: interview excerpts, survey responses, sales-call notes and support themes. Preserve direct quotes where possible.
• Brand guidance: positioning, voice rules, approved terminology, prohibited claims and current category language.
• Market evidence: competitor pages, campaign claims and category conventions. Record the page title, claim and date seen. Do not treat a competitor's claim as fact.
• Launch constraints: target segments, regions, channels, timings, legal or compliance review requirements, and the named approver for each area.

Separate evidence from interpretation. For example, put Customers said setup takes too long in evidence. Put Lead with speed of setup in interpretation. This makes it easier for reviewers to challenge the right thing.

2. Extract the decision-ready facts

Ask the model you are using to turn the source pack into an evidence sheet. Give it the files or pasted material, then use a constrained prompt such as:

Create an evidence sheet for launch messaging.

Use only the supplied material. For each item, include:
- customer or audience segment
- job, problem or desired outcome
- supporting quote or source reference
- product capability or proof
- stated objection, risk or uncertainty
- confidence: supported, partial or unsupported

Keep evidence and inference in separate columns. Do not write campaign copy. List contradictions and missing evidence at the end.

Read the contradictions before doing anything else. Common examples include a product note that says a capability is available to all customers and a rollout plan that limits access, or research that points to a different priority audience from the launch brief.

If you are handling material through an API or a product workspace, check the current handling options and version-dependent behaviour in the xAI documentation. Do not upload customer research that your organisation has not approved for that use.

3. Choose one priority audience and job

Do not begin with a broad label such as mid-market teams. Choose the audience that has both a clear problem and a credible reason to act at launch.

Write this sentence in the hierarchy document:

For [specific audience] who need to [job or outcome], this launch helps them [measurable or observable improvement] because [capability or mechanism].

Then test it against the source pack:

• Does this audience appear in the research, not merely the launch plan?
• Is the job urgent enough to justify attention now?
• Can the product team demonstrate the mechanism?
• Does the statement avoid benefits that depend on unavailable features or services?

Name secondary audiences separately. They may need tailored proof later, but they should not displace the primary audience in the approval document.

4. Draft the hierarchy in a fixed order

Create a one-page table. Keep the first version factual and plain. Avoid headlines, taglines and polished advertising language until the underlying choices are approved.

Layer	Write	Approval question
Audience priority	Primary audience, job and trigger	Is this the launch audience we will lead with?
Core promise	One outcome the product can credibly deliver	Is this distinct, useful and supportable?
Proof points	Two to four capabilities, facts or customer outcomes	Can each point be substantiated?
Objections	Reasons the audience may delay, doubt or reject	Are these the objections sales and research actually show?
Response	Proof, qualification or action that addresses each objection	Is the response accurate and sufficient?
Message boundaries	Claims to avoid, required qualifiers and terms not to use	What must not appear in campaign work?
Decisions needed	Named choices, owners and deadline	Who approves each unresolved point?

Use one core promise only. If two promises seem equally important, the work is not to place both at the top. Decide whether they serve different audiences, whether one is proof of the other, or whether one lacks evidence.

For each proof point, add a source label such as Product note, 14 May or Customer interview 03, operations lead. This saves time when a reviewer asks, “Where did that come from?”

5. Run an objection check before review

Ask the model to challenge the draft, not improve its style. Paste the hierarchy and use this prompt:

Act as a sceptical product marketing reviewer.

Find claims in this messaging hierarchy that are vague, unsupported, too broad, indistinguishable from category language, or contradicted by the evidence sheet.

For each issue, quote the exact wording, explain the risk, identify the missing evidence, and suggest a narrower replacement. Do not invent proof or customer quotes.

Use the response as a review list, not as an automatic rewrite. Make changes only where the source pack supports them. If the challenge identifies a genuine gap, add it to Decisions needed with an owner.

6. Know when the hierarchy is wrong

A fluent hierarchy can still be unusable. Check for these failure signals before sending it for approval.

If you see this	It usually means	Do this
The promise could describe several competitors	The message is category-level, not product-specific	Add the mechanism or choose a narrower customer outcome
Proof points are feature names only	The link from capability to customer value is missing	State what the capability enables, then verify it
Every audience is called primary	The launch has no prioritisation	Choose the first audience and list others as secondary
Objections are generic, such as “price”	The draft is avoiding real buying friction	Return to interviews, sales notes and support evidence
Reviewers debate wording but not decisions	The approval questions are hidden	Put unresolved choices in the final row with owners

7. Send a review pack people can decide from

Send the hierarchy with three items only:

1. The one-page hierarchy.
2. The evidence sheet or a link to it.
3. A short list of decisions required, each with an owner and decision date.

In the meeting, ask for decisions in hierarchy order: audience, promise, proof, objections, boundaries. Record a decision beside each item. Do not end with “any feedback?” because it invites broad comments without ownership.

After approval, treat the hierarchy as the source document for the creative brief, landing-page outline and ad-variant request. When someone proposes a new claim, ask which approved layer it belongs to and what evidence supports it.

When it does not work

If reviewers cannot choose a core promise, do not solve it by adding more options. Return to the evidence sheet and find the missing decision: an unclear launch audience, an unverified capability, or a disagreement about the product's strategic role. Assign that decision to the product, research or brand owner who can resolve it.

If the source pack is thin, produce a provisional hierarchy with every assumption labelled. Ask for the specific missing interview, product confirmation or brand ruling. A clearly incomplete document is safer than confident launch copy built on guesses.