Go-To-Market Skill

Create go-to-market assets for any product or feature.

Go-To-Market Skill — The Skill Playground: pick the Executive Update skill, fill in a few notes, hit run, and watch a structured executive… (from the mohitagw15856/pm-claude-skills README)

From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/go-to-market, including the files SKILL.md points to.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/go-to-market#main ~/.claude/skills/go-to-market

For one project only, change the path to .claude/skills/go-to-market. This skill also uses context.md — copying SKILL.md alone won't be enough. See the folder on GitHub.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Go-To-Market Skill

Show the full text135 lines
namedescription
go-to-marketCreate go-to-market assets for any product or feature. Use when asked for a GTM plan, positioning statement, product launch plan, messaging pillars, use cases, or feature/benefit list. Produces a full GTM pack: positioning statement, messaging pillars, feature-to-benefit mapping, and role-specific use cases. For a tiered launch plan with cross-functional coordination use go-to-market-planner instead.

Go-To-Market Skill

This skill produces a complete go-to-market asset pack for a product, feature, or initiative. It follows Geoffrey Moore's positioning framework and structures all outputs for use in sales decks, landing pages, launch emails, and internal alignment docs.

Working from a brief

You will often get a short brief without every detail. Always deliver the full GTM pack anyway — do not stop to ask questions and do not leave bracketed placeholders like [ADD PROOF POINT] or [Technical capability]. Where a detail is missing (differentiators, proof points, features), infer specific, realistic ones from the product description and the target customer, and mark anything inferred as (assumed — confirm). A concrete, labelled assumption is always better than a blank.

Inputs (infer any not provided — label assumptions)

  • Product/feature name
  • One-line description (what it does, technically)
  • Target customer (role, company size, industry if relevant)
  • Primary problem it solves
  • Key competitor or alternative (what people do today without this)
  • Top 3 differentiators

Reads from / Writes to the Brain

If a professional-brain (brain/) exists, use it before asking:

  • Read first: context.md (product, ICP, voice), knowledge/market.md and knowledge/strategy.md, and the matching entities/ feature being launched.
  • Write after: save the launch plan to entities/, and any positioning or channel decision to decisions/, each provenance-tagged.

Output Structure

Always produce all four sections below in order.


1. Positioning Statement

Use the Geoffrey Moore format exactly:

For [target customer] who [has this problem or need], [Product Name] is a [product category] that [key benefit/outcome]. Unlike [primary alternative or competitor], our product [key differentiator].

Write one primary positioning statement, then offer a shorter tagline version (10 words or fewer) suitable for a hero headline.


2. Messaging Pillars

Generate 3–5 messaging pillars. Each pillar must include:

  • Pillar name (2–4 words, bold)
  • One-sentence summary of what this pillar claims
  • 2–3 proof points (specific and evidence-backed; if no data was provided, infer a realistic proof point and mark it (assumed) — never leave a bare placeholder)
  • Example use in copy (one sentence as it would appear in a landing page or deck)

Pillars should be distinct — avoid overlap. Each pillar should be defensible against the primary competitor.


3. Feature & Functionality List

Produce a two-column table:

Feature / Functionality Buyer Benefit (what it means for the user)
[Technical capability] [Outcome in plain language — start with a verb: "Reduces...", "Enables...", "Eliminates..."]

Rules:

  • Never list a feature without a corresponding benefit
  • Benefits should reference the target customer's workflow or pain point
  • Aim for 6–12 rows; if only 1–2 features were given, infer the rest plausibly from the product description
  • Avoid jargon in the benefit column — write as if explaining to a buyer, not an engineer

4. Use Cases

Generate 3–5 role-specific use cases. Each use case must follow this format:

Use Case [N]: [Role] — [Scenario Title]

  • Who: [Job title / role]
  • Situation: [The specific moment or trigger that leads them to use the product]
  • Before: [What they had to do without this product — be specific about time, friction, or risk]
  • With [Product Name]: [What they do now — concrete action, not vague benefit]
  • Outcome: [Measurable or tangible result]

Use cases should cover different buyer personas if possible (e.g. end user, manager, admin).


Deeper Materials

This skill ships with support files — use them when they are available:

  • references/messaging-hierarchy.md — The Messaging Hierarchy: One Claim, Then Everything Else. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
  • templates/gtm-pack.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Dimension 0 5 10
Positioning precision Generic value statement, no target or alternative Moore format followed but the "unlike" clause is soft Moore format with a sharp target segment and an "unlike" that names the real alternative buyers weigh
Message-proof integrity Pillars are unsupported claims Proof points exist but some are restated claims Every pillar carries ≥2 genuine proof points (or honestly flagged placeholders), and the hierarchy leads with one claim
Feature-to-benefit conversion Feature list with no benefits Benefits present but passive or feature-shaped Every feature paired with an action-verb benefit a buyer would repeat to their boss
Launch usability A positioning essay, not a pack Pack complete but pieces inconsistent with each other Tagline, pillars, use cases and benefit list all tell the same story and are lift-ready for a launch page

Quality Checks

Before delivering output, verify:

  • Positioning statement follows Moore format exactly
  • Tagline is 10 words or fewer
  • Each pillar has at least 2 proof points (or flagged placeholders)
  • Every feature has a benefit — no orphaned features
  • Benefits start with action verbs
  • Use cases include a Before/After structure
  • Language is consistent with the target customer's vocabulary (not internal engineering terms)

Anti-Patterns

  • Do not write feature descriptions instead of benefits — the GTM pack must translate features into customer value
  • Do not use the same messaging across all buyer personas — each role has different priorities and language
  • Do not create a positioning statement that could apply to any competitor — differentiation must be specific and defensible
  • Do not skip the "not for" section — defining who this is not for sharpens positioning and prevents misdirected sales effort
  • Do not list use cases without tying them to specific job titles or buyer roles

Example Trigger Phrases

  • "Create a positioning statement for [product]"
  • "Write a GTM plan for [feature]"
  • "Give me key pillars for [product name]"
  • "Build a feature and use case list for [product]"
  • "We're launching [X] — help me with the messaging"
1---
2name: go-to-market
3description: "Create go-to-market assets for any product or feature. Use when asked for a GTM plan, positioning statement, product launch plan, messaging pillars, use cases, or feature/benefit list. Produces a full GTM pack: positioning statement, messaging pillars, feature-to-benefit mapping, and role-specific use cases. For a tiered launch plan with cross-functional coordination use go-to-market-planner instead."
4---
5 
6# Go-To-Market Skill
7 
8This skill produces a complete go-to-market asset pack for a product, feature, or initiative. It follows Geoffrey Moore's positioning framework and structures all outputs for use in sales decks, landing pages, launch emails, and internal alignment docs.
9 
10## Working from a brief
11 
12You will often get a short brief without every detail. **Always deliver the full GTM pack anyway** — do not stop to ask questions and do not leave bracketed placeholders like `[ADD PROOF POINT]` or `[Technical capability]`. Where a detail is missing (differentiators, proof points, features), infer specific, realistic ones from the product description and the target customer, and mark anything inferred as *(assumed — confirm)*. A concrete, labelled assumption is always better than a blank.
13 
14## Inputs (infer any not provided — label assumptions)
15 
16- **Product/feature name**
17- **One-line description** (what it does, technically)
18- **Target customer** (role, company size, industry if relevant)
19- **Primary problem it solves**
20- **Key competitor or alternative** (what people do today without this)
21- **Top 3 differentiators**
22 
23## Reads from / Writes to the Brain
24 
25If a [`professional-brain`](../professional-brain/SKILL.md) (`brain/`) exists, use it before asking:
26 
27- **Read first:** `context.md` (product, ICP, voice), `knowledge/market.md` and `knowledge/strategy.md`, and the matching `entities/` feature being launched.
28- **Write after:** save the launch plan to `entities/`, and any positioning or channel decision to `decisions/`, each provenance-tagged.
29 
30## Output Structure
31 
32Always produce all four sections below in order.
33 
34---
35 
36### 1. Positioning Statement
37 
38Use the Geoffrey Moore format exactly:
39 
40> For **[target customer]** who **[has this problem or need]**, **[Product Name]** is a **[product category]** that **[key benefit/outcome]**. Unlike **[primary alternative or competitor]**, our product **[key differentiator]**.
41 
42Write one primary positioning statement, then offer a shorter tagline version (10 words or fewer) suitable for a hero headline.
43 
44---
45 
46### 2. Messaging Pillars
47 
48Generate 3–5 messaging pillars. Each pillar must include:
49 
50- **Pillar name** (2–4 words, bold)
51- **One-sentence summary** of what this pillar claims
52- **2–3 proof points** (specific and evidence-backed; if no data was provided, infer a realistic proof point and mark it *(assumed)* — never leave a bare placeholder)
53- **Example use in copy** (one sentence as it would appear in a landing page or deck)
54 
55Pillars should be distinct — avoid overlap. Each pillar should be defensible against the primary competitor.
56 
57---
58 
59### 3. Feature & Functionality List
60 
61Produce a two-column table:
62 
63| Feature / Functionality | Buyer Benefit (what it means for the user) |
64|---|---|
65| [Technical capability] | [Outcome in plain language — start with a verb: "Reduces...", "Enables...", "Eliminates..."] |
66 
67Rules:
68- Never list a feature without a corresponding benefit
69- Benefits should reference the target customer's workflow or pain point
70- Aim for 6–12 rows; if only 1–2 features were given, infer the rest plausibly from the product description
71- Avoid jargon in the benefit column — write as if explaining to a buyer, not an engineer
72 
73---
74 
75### 4. Use Cases
76 
77Generate 3–5 role-specific use cases. Each use case must follow this format:
78 
79**Use Case [N]: [Role] — [Scenario Title]**
80 
81- **Who:** [Job title / role]
82- **Situation:** [The specific moment or trigger that leads them to use the product]
83- **Before:** [What they had to do without this product — be specific about time, friction, or risk]
84- **With [Product Name]:** [What they do now — concrete action, not vague benefit]
85- **Outcome:** [Measurable or tangible result]
86 
87Use cases should cover different buyer personas if possible (e.g. end user, manager, admin).
88 
89---
90 
91## Deeper Materials
92 
93This skill ships with support files — use them when they are available:
94 
95- **`references/messaging-hierarchy.md`** — The Messaging Hierarchy: One Claim, Then Everything Else. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
96- **`templates/gtm-pack.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.
97 
98## Scoring Rubric (0–40)
99 
100Score any output of this skill before handing it over; 32+ is ship-quality.
101 
102| Dimension | 0 | 5 | 10 |
103|---|---|---|---|
104| Positioning precision | Generic value statement, no target or alternative | Moore format followed but the "unlike" clause is soft | Moore format with a sharp target segment and an "unlike" that names the real alternative buyers weigh |
105| Message-proof integrity | Pillars are unsupported claims | Proof points exist but some are restated claims | Every pillar carries ≥2 genuine proof points (or honestly flagged placeholders), and the hierarchy leads with one claim |
106| Feature-to-benefit conversion | Feature list with no benefits | Benefits present but passive or feature-shaped | Every feature paired with an action-verb benefit a buyer would repeat to their boss |
107| Launch usability | A positioning essay, not a pack | Pack complete but pieces inconsistent with each other | Tagline, pillars, use cases and benefit list all tell the same story and are lift-ready for a launch page |
108 
109## Quality Checks
110 
111Before delivering output, verify:
112- [ ] Positioning statement follows Moore format exactly
113- [ ] Tagline is 10 words or fewer
114- [ ] Each pillar has at least 2 proof points (or flagged placeholders)
115- [ ] Every feature has a benefit — no orphaned features
116- [ ] Benefits start with action verbs
117- [ ] Use cases include a Before/After structure
118- [ ] Language is consistent with the target customer's vocabulary (not internal engineering terms)
119 
120## Anti-Patterns
121 
122- [ ] Do not write feature descriptions instead of benefits — the GTM pack must translate features into customer value
123- [ ] Do not use the same messaging across all buyer personas — each role has different priorities and language
124- [ ] Do not create a positioning statement that could apply to any competitor — differentiation must be specific and defensible
125- [ ] Do not skip the "not for" section — defining who this is not for sharpens positioning and prevents misdirected sales effort
126- [ ] Do not list use cases without tying them to specific job titles or buyer roles
127 
128## Example Trigger Phrases
129 
130- "Create a positioning statement for [product]"
131- "Write a GTM plan for [feature]"
132- "Give me key pillars for [product name]"
133- "Build a feature and use case list for [product]"
134- "We're launching [X] — help me with the messaging"
135 

Discussion

Alternatives

Also in Launch planningSee all 277 in Product →
AI Product Launch PlaybookLaunch your AI product to global attention — the playbook behind Manus, Devin, and AFFiNE's breakout launches. Covers AI-specific GTM strategy, hype cycle management, waitlist tactics, and multi-market rollout for maximum day-one impact.Business & ops · MITShipping and launchPrepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.Business & ops · MITLaunch StrategyWhen the user wants to plan a product launch, feature announcement, or release strategy. Also use when the user mentions 'launch,' 'Product Hunt,' 'feature release,' 'announcement,' 'go-to-market,' 'beta launch,' 'early access,' 'waitlist,' 'product update,' 'how do I launch this,' 'launch checklist,' 'GTM plan,' or 'we're about to ship.' Use this whenever someone is preparing to release something publicly. For ongoing marketing after launch, see marketing-ideas. For the offer being launched (bonuses, guarantees, scarcity, naming), see offers.Marketing · MITPacsomaticOperator toolkit for nf-core/pacsomatic matched tumor-normal workflows from BAM inputs. Use this skill when the user needs to validate run inputs, generate pacsomatic-compliant samplesheets, prepare reproducible Nextflow launch artifacts, run locally or submit to schedulers (LSF/Slurm/PBS/SGE), and triage execution failures. Triggers on requests to run pacsomatic, prepare launch commands/scripts, perform dry-run checks, or troubleshoot pipeline startup and scheduler submission errors.Science · MIT