go-to-market

GitHub

为产品或功能生成完整的市场进入(GTM)资产包,包括定位声明、消息支柱、特性与利益映射及角色特定用例。遵循Geoffrey Moore框架,自动推断缺失细节并标记假设,适用于销售演示和发布材料。

exports/openclaw/go-to-market/SKILL.md mohitagw15856/pm-claude-skills

Trigger Scenarios

制定 GTM 计划 编写定位声明 创建产品发布计划 定义消息支柱 列举使用场景 生成特性与利益列表

Install

npx skills add mohitagw15856/pm-claude-skills --skill go-to-market -g -y
More Options

Non-standard path

npx skills add https://github.com/mohitagw15856/pm-claude-skills/tree/main/exports/openclaw/go-to-market -g -y

Use without installing

npx skills use mohitagw15856/pm-claude-skills@go-to-market

指定 Agent (Claude Code)

npx skills add mohitagw15856/pm-claude-skills --skill go-to-market -a claude-code -g -y

安装 repo 全部 skill

npx skills add mohitagw15856/pm-claude-skills --all -g -y

预览 repo 内 skill

npx skills add mohitagw15856/pm-claude-skills --list

SKILL.md

Frontmatter
{
    "name": "go-to-market",
    "homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/go-to-market.html",
    "metadata": {
        "openclaw": {
            "emoji": "🚀"
        }
    },
    "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."
}

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"

Version History

  • 54fad50 Current 2026-07-19 12:21

Same Skill Collection

exports/openclaw/360-feedback-template/SKILL.md
exports/openclaw/401k-plan-decoder/SKILL.md
exports/openclaw/ab-test-planner/SKILL.md
exports/openclaw/ab-test-readout/SKILL.md
exports/openclaw/accessibility-audit/SKILL.md
exports/openclaw/account-plan/SKILL.md
exports/openclaw/acquirer-red-team/SKILL.md
exports/openclaw/ad-copy/SKILL.md
exports/openclaw/aeo-optimizer/SKILL.md
exports/openclaw/agenda-or-cancel/SKILL.md
exports/openclaw/agent-design-review/SKILL.md
exports/openclaw/agent-observability-spec/SKILL.md
exports/openclaw/agent-spec/SKILL.md
exports/openclaw/ai-ethics-review/SKILL.md
exports/openclaw/ai-eval-plan/SKILL.md
exports/openclaw/ai-feature-prd/SKILL.md
exports/openclaw/ai-product-canvas/SKILL.md
exports/openclaw/air-quality/SKILL.md
exports/openclaw/altitude-shifter/SKILL.md
exports/openclaw/ambiguity-resolver/SKILL.md
exports/openclaw/analyst-relations-brief/SKILL.md
exports/openclaw/announcement-card/SKILL.md
exports/openclaw/api-docs-writer/SKILL.md
exports/openclaw/api-test-plan/SKILL.md
exports/openclaw/api-versioning-strategy/SKILL.md
exports/openclaw/apology-letter/SKILL.md
exports/openclaw/architecture-decision-record/SKILL.md
exports/openclaw/architecture-diagram/SKILL.md
exports/openclaw/archive-strategy/SKILL.md
exports/openclaw/assumption-bounty/SKILL.md
exports/openclaw/assumption-mapper/SKILL.md
exports/openclaw/async-update-format/SKILL.md
exports/openclaw/auto-repair-estimate-decoder/SKILL.md
exports/openclaw/autopilot-charter/SKILL.md
exports/openclaw/benefits-decoder/SKILL.md
exports/openclaw/bid-tender-review/SKILL.md
exports/openclaw/board-deck-narrative/SKILL.md
exports/openclaw/board-minutes/SKILL.md
exports/openclaw/board-pre-read/SKILL.md
exports/openclaw/bom-cost-review/SKILL.md
exports/openclaw/bookkeeping-categorization/SKILL.md
exports/openclaw/boolean-search-builder/SKILL.md
exports/openclaw/brag-doc/SKILL.md
exports/openclaw/brainstorming/SKILL.md
exports/openclaw/brief-builder/SKILL.md
exports/openclaw/briefing-note/SKILL.md
exports/openclaw/budget-builder/SKILL.md
exports/openclaw/budget-variance-analysis/SKILL.md
exports/openclaw/bug-diagnosis/SKILL.md
exports/openclaw/bug-report/SKILL.md

Metadata

Files
0
Version
471c606
Hash
4980f6bc
Indexed
2026-07-19 12:21

- 위키
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-07-30 18:10
浙ICP备14020137号-1 $방문자$