Go To Market

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:

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.