# Create Gtm Brief

> Create a go-to-market brief with positioning, messaging, and launch plan when the user asks to plan a launch, create a GTM strategy, or write a go-to-market plan

- Skill: `majiayu000/create-gtm-brief` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/create-gtm-brief`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/create-gtm-brief/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/create-gtm-brief

---


# Create GTM Brief

## Overview

Generate a go-to-market brief covering positioning (Geoffrey Moore format), key messages per audience, launch tier classification, enablement checklist, and timeline. Aligns product, marketing, sales, and support around a coordinated launch.

## Workflow

1. **Read product context** -- Scan `.chalk/docs/product/` for the product profile, PRD for the feature being launched, competitive analysis, and any existing GTM materials. Understand the product positioning and target users before planning the launch.

2. **Parse the launch scope** -- Extract from `$ARGUMENTS` the feature or product to create a GTM brief for. If unspecified, ask the user to name the feature and its target launch timing.

3. **Determine the next file number** -- Read filenames in `.chalk/docs/product/` to find the highest numbered file. The next number is `highest + 1`.

4. **Write the positioning statement** -- Use Geoffrey Moore's format: "For [target customer] who [need/opportunity], [product name] is a [category] that [key benefit]. Unlike [primary competitor], our product [primary differentiation]."

5. **Define key messages per audience** -- Write 2-3 key messages tailored to each audience:
   - End users (focus on value and ease)
   - Technical buyers / developers (focus on capabilities and integration)
   - Business decision makers (focus on ROI and risk reduction)
   - Internal teams (focus on what changed and how to support it)

6. **Classify the launch tier**:
   - **Silent**: Ship it, update docs, no announcement (bug fixes, minor improvements)
   - **Soft**: Blog post, changelog entry, email to affected users (incremental features)
   - **Hard**: Full campaign, press, event, coordinated cross-functional launch (major features, new products)

7. **Build the enablement checklist** -- What must be ready before launch:
   - Documentation: user docs, API reference, migration guide
   - Support: runbooks, FAQ, escalation path, training
   - Sales: talk track, demo script, competitive positioning
   - Engineering: monitoring, feature flags, rollback plan

8. **Draft the timeline** -- Key milestones from now to launch and post-launch review.

9. **Write the file** -- Save to `.chalk/docs/product/<n>_gtm_brief_<feature-slug>.md`.

10. **Confirm** -- Share the file path and highlight any enablement gaps that need to be resolved before launch.

## Output

- **File**: `.chalk/docs/product/<n>_gtm_brief_<feature-slug>.md`
- **Format**: Plain markdown with positioning statement, audience messages, launch tier, enablement checklist, and timeline
- **First line**: `# GTM Brief: <Feature Name>`

## Anti-patterns

- **Positioning without differentiation** -- "We are the best solution for X" is not positioning. The Geoffrey Moore format forces you to name the competitor and state how you are different. Do not skip this.
- **One message for all audiences** -- Developers care about API design; executives care about ROI. Reusing the same message for every audience means it resonates with none.
- **Hard launch for everything** -- Not every feature deserves a full campaign. Over-launching fatigues your audience and dilutes impact. Match the launch tier to the significance of the change.
- **No enablement checklist** -- Launching a feature that support cannot explain, sales cannot demo, and docs do not cover creates a poor experience. Every launch needs an enablement check.
- **Missing post-launch review** -- The timeline should include a post-launch review milestone to assess what worked and capture learnings.