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.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add mohitagw15856/pm-claude-skills --skill go-to-market --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Go To Market?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mohitagw15856-go-to-market-pm-claude-skills)More formats (shields.io, HTML) on the badges page.
---
name: go-to-market
description: "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."
homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/go-to-market.html
metadata:
{
"openclaw": { "emoji": "🚀" }
}
---
# 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**
## 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).
---
## 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"
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!