Write a launch brief whose claims, owners and metric can all be checked

Start with the release facts and the decision the brief supports

Write down first what changes, who gets it, when it becomes available, and which decision this brief is for, such as a readiness review on a given date. Separate beta or limited availability from general availability. A packaging, pricing or availability change is a launch with no new customer capability, and it needs the same brief.

The positioning brief gives you the buyer, the alternative, the supported difference, the proof and the exclusions. It is strategic context and does not say what will ship, so the release owner supplies the current scope, the rollout by segment and plan, any price or packaging change, and the readiness evidence behind each statement. Add the exact approved wording from your message hierarchy, any permitted customer or competitor proof, and the real records of who owns what. Give each input a short source ID, a link, the date you checked it and its approval state. Keep private buyer or employee records out of any workspace not approved for them.

Work in a chat inside the Claude Project you keep for this product; the project setup lesson covers instructions and files once. Anthropic's Projects page says free accounts can create up to five Projects, so nothing here needs a paid plan, and a one-off chat with the same documents attached works too. No Research, Code or connector is needed for this drafting job.

The brief has six connected sections:

• Audience: the buyer or user, affected customers and partners, and the internal teams the release touches, with what each needs to know.
• Change: the actual release scope, availability by segment and plan, the date, and any pricing or packaging change, each with a source ID.
• Narrative: the approved wording carried in unchanged, or a candidate sentence marked proposed.
• Enablement: each asset and communication, its audience, its owner, the readiness evidence, and its place in the sequence.
• Risks and open decisions: the evidence, the possible consequence, the accountable contact, the next action and its date.
• Measurement: the primary decision metric, its definition, source, population and window, the owner and the review date.

Connect the audience, the change and the message

Name only the audiences the release touches. The buyer or user from the positioning brief comes first. Existing customers whose workflow moves, partners who resell or integrate, and an admin who has to switch something on are affected audiences when the change reaches them; sales, support and customer success are internal audiences when they will be asked about it.

The change section states what will be available, to whom, from when, taken from the release owner's record rather than from the positioning brief's description of the difference. A capability on the roadmap does not belong in the change section; if the narrative depends on it, it goes to the open decisions.

The narrative carries the approved wording from the message hierarchy without editing it. If no approved sentence exists yet, draft one from the positioning brief and mark it proposed, so a reader can tell a candidate from an approved line. An illustrative example, invented for this lesson: the release note says an export is available only in a private beta on one plan, and a draft headline says "available to everyone". A sound review flags the contradiction, keeps the beta scope in the change section, and withholds the general-availability wording until the release record changes.

Give sales and support a usable handoff

The enablement section names each asset and communication, who it is for, who owns it, what shows it is ready, and its place in the sequence, with internal communications before external ones. A typical list is short: the narrative sentence, answers to the likely first objections, the pricing change with its effective date, a demo path, the first-week escalation contact, and the enablement session. Where a seller asset such as a battlecard changes, name the specific line and its owner; the battlecards lesson covers how short that line should be.

Each row links to a confirmation the owner can point to. "Enablement: done" is not a row, because nobody can check it. The brief records the handoff; it is not the team's task tracker.

Keep risks and open decisions visible

Write each risk as five fields: the evidence that it exists, the possible consequence, the accountable contact, the next action, and the date. Typical rows are a dependency that may slip, a claim in the narrative with no supporting passage yet, a support team that has not seen the feature, and a competitor page change that weakens the story. Our recommendation is a named person in the contact field rather than a team, because a person can confirm the row; it is a recommendation, not a rule any source imposes.

Open decisions get the same treatment. The GTM Playbook brief template describes open questions as decisions not yet made and says to write them down, assign owners and set resolution dates. Pendo's product launch brief template publicly describes a launch summary, timing and milestones, beta responsibilities and a GA checklist; the full artifact sits behind a form, so this lesson claims nothing about it beyond that description. Both are practitioner formats; what this lesson adds is the source ID on each claim and the check against the release record.

Make the success measure readable by someone else

Write the primary metric so that a reader can open the source and reproduce what will be counted: the event, the qualifying population, the denominator, the time window, where the number is read, who reads it and on what date. Record a baseline or target only if the team actually agreed one. "Adoption" on its own tells nobody where to look; "accounts on the affected plan that used the export at least once within 30 days of availability, read from the product analytics dashboard on the review date" can be checked.

One primary metric focuses the review, and a supporting or guardrail measure can be appropriate; the single-metric preference is our recommendation. A count during the launch period does not establish that the launch caused it. If the number is not instrumented, that is an open decision with an owner and a date, not a metric.

Draft, check and save the brief with Claude

1. List the inputs each section needs before drafting

   Give Claude the source pack with its IDs and ask which inputs each of the six sections requires and which are missing from the pack. Check: missing owner acceptance, unsupported outcomes and roadmap-dependent wording appear as gaps rather than defaults filled from general knowledge.

2. Draft the six sections with a source ID on each claim

   Use the prompt below. Check: every material sentence carries an ID you can open, exact approved wording is unchanged, and conflicting dates are still flagged rather than resolved.

3. Open each cited passage and confirm each commitment with its owner

   Read the passage behind each claim and confirm it says what the brief says, at the same scope. Ask each named owner to confirm their row through the team's normal process. Check: nothing is described as generally available because a plan said it would be; every unaccepted assignment is visibly unaccepted.

4. Save the reviewed brief and its source index as dated files

   Add the approved working version to Project knowledge and to the team's shared location. Check: the file carries its date, its open decisions and the source index, so a reviewer can follow any claim back without you.

One prompt earns its place because it separates missing evidence from unmade decisions, the distinction the review depends on:

Draft the six launch-brief sections from these source IDs. Preserve approved wording. For each material claim, cite its source ID. Mark unsupported facts or unconfirmed commitments [OPEN: needed evidence or decision]. Do not resolve conflicting dates or turn planned availability into released availability. Return the brief and its unresolved items.

The prompt makes the draft checkable, not true. Anthropic's memory page says each Project has its own memory space, so a chat may carry context from earlier work. Instruct Claude to ground material claims in the supplied pack anyway, and keep the dated approved files as the record, because a file has a version and a date a reviewer can open. Anthropic's connectors page says Claude can access connected apps, and its Google Workspace connectors page covers Google services such as Drive and Gmail; this method uses a manually supplied pack, so anything not in it is missing until you add it. A record Claude finds in a connected service still does not make a human commitment or a launch decision.

Keep competitive evidence current

When the scope, the price, a cited passage or a date changes, compare the old and new sources, list the brief statements and assets that depend on them, revise or remove superseded claims, and have the affected owners confirm changed commitments again. Reuse the headings and checks for the next launch; start its dates, targets and owners from zero.

For competitor evidence in the risk section, the DIY method is to save dated copies of the competitor pages the narrative depends on and recheck them at the next readiness review, at a frequency set by what a missed change would cost and how often those pages move. One or two competitors is a reasonable place to start; it is not proof that manual coverage is enough.

Steve's adjacent fit is narrow. It detects changes to tracked competitor websites and posts them to Slack, which a PMM can read as input to a risk row. Steve has no launch-brief, owner-assignment or readiness workflow, and nothing updates a brief on its own. If keeping competitor page evidence current across many pages is the part that slips, Steve's competitive intelligence product is the adjacent option to evaluate; the brief and its decisions stay with your team either way.