brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent,…
Create a Geoffrey Moore-style positioning statement. Use when clarifying who you serve, what problem you solve, your category, and why you're different from alternatives.
$ npx -y skills add getcrew44/crew44 --skill positioning-statement --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/positioning-statementContext preview
The summary Claude sees to decide when to auto-load this skill.
Create a Geoffrey Moore-style positioning statement. Use when clarifying who you serve, what problem you solve, your category, and why you're different from alternatives.
name: positioning-statement description: Create a Geoffrey Moore-style positioning statement. Use when clarifying who you serve, what problem you solve, your category, and why you're different from alternatives. intent: >- Create a Geoffrey Moore-style positioning statement that clearly articulates who your product serves, what need it addresses, how it's categorized, what benefit it delivers, and how it differs from alternatives. Use this when you need to align stakeholders on product strategy, guide messaging, or test if your value proposition is crisp and defensible. type: component theme: strategy-positioning best_for: - "Defining your product's market position clearly for the first time" - "Differentiating from specific competitors in your messaging" - "Aligning your team on who you serve, what problem you solve, and why you're different" scenarios: - "I need to write a positioning statement for a new B2B SaaS product targeting mid-market HR teams" - "Our positioning feels generic and I need to sharpen it against two specific competitors" estimated_time: "10-15 min"
Create a Geoffrey Moore-style positioning statement that clearly articulates who your product serves, what need it addresses, how it's categorized, what benefit it delivers, and how it differs from alternatives. Use this when you need to align stakeholders on product strategy, guide messaging, or test if your value proposition is crisp and defensible.
This is not a tagline or elevator pitch—it's a strategic clarity tool that forces you to make hard choices about target, need, and differentiation.
From *Crossing the Chasm*, Moore's framework splits positioning into two parts:
**Value Proposition:**
**Differentiation Statement:**
---
Use `template.md` for the full fill-in structure.
Before drafting, ensure you have:
**If missing context:** Use discovery interviews, market research, or customer interviews to fill gaps. Don't guess.
---
Fill in the template:
## Value Proposition **For** [specific target customer/persona] - **that need** [statement of underserved need—focus on pains, gains, JTBD] - [product or service name] - **is a** [product category] - **that** [benefit statement—focus on outcomes, not features]
**Quality checks:**
---
Fill in the template:
## Differentiation Statement - **Unlike** [primary competitor or competitive alternative] - [product or service name] - **provides** [unique differentiation—outcomes, not features]
**Quality checks:**
---
Ask these questions: 1. **Would a customer recognize themselves?** Read the "For [target]" aloud. Does it feel specific or generic? 2. **Is the need defensible?** Can you point to research, interviews, or data that validates this need? 3. **Does the category help or hurt?** Does it anchor you against the right competitors? Or does it box you in? 4. **Is differentiation believable?** Could you prove this claim with a demo, case study, or data? 5. **Does this guide decisions?** If someone asked "Should we build feature X?" would this positioning he
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent,…
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting…
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical…
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes