--- name: mohitagw15856/go-to-market source: https://app.decimal.ai/s/mohitagw15856-go-to-market@4/SKILL.md source_sha256: d33ca233e72e --- # 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`](../professional-brain/SKILL.md) (`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"