Product strategy doc — 5-part GSBS structure
SkillDocs & knowledgeProduces a 5-part GSBS (Good Strategy Bad Strategy) product strategy document via guided interview: target problem, approach (guiding policy not features), who-for (one persona ideally), key metrics (SMART, anti-vanity), and 2-4 tracks. Anchors the agent-native PM operating loop with /product-pulse and /ship-learnings. Triggers: "product strategy", "strategy doc", "GSBS strategy", "what should we build", "strategy interview". Recommended upstream: company-context, icp-research, positioning. Feeds product-pulse + ship-learnings. NOT for positioning/messaging (use /positioning + /product-messaging) or feature specs (use external product-management:write-spec).
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Product strategy doc — 5-part GSBS structure skill
What this skill tells your AI
The instructions your AI receives, as published by matteotitta/genesys-skills in skills/primitives/product-management/strategy/strategy-doc/SKILL.md and read by ahel’s review.
Produce a locked product strategy document that anchors the agent-native PM operating loop. Adapted from /ce-strategy in EveryInc/compound-engineering-plugin v3.5.0 (MIT). Based on Marcus Moretti's AI PM Guide (Every.to) and Richard Rumelt's Good Strategy Bad Strategy.
This is not a spec or PRD. Strategy describes the guiding policy (what we'll do and why); requirements describe the artifacts (what we'll build). Keep them separate.
When to run
Invoke when the user says:
- "Run product strategy for [Genesys ship / client product]"
- "What's our strategy for [product]?"
- "Time for the quarterly strategy refresh"
- "Run the strategy interview"
Do NOT invoke when:
- User wants positioning / category framing →
/positioning(PMM-side, different artifact) - User wants a feature spec / PRD → external
product-management:write-specplugin - User wants the daily product pulse →
/product-pulse(downstream of this skill) - User wants post-ship learnings →
/ship-learnings
Workflow sequences:
- New product:
company-context → icp-research → positioning → strategy-doc → product-pulse → ship-learnings - Refresh:
ship-learnings (last cycle) + product-pulse (last cycle) → strategy-doc (refreshed)
Inputs
Required:
- Product name + 1-line description
- Stakeholder for review (founder / PM / ops lead)
Recommended (improve quality):
company-context— firmographics, traction, qualification contexticp-research/icp-behavioural— sharpens the "who-for" sectionpositioning— gives anchors and differentiators (the "approach")win-loss-analysis— what users actually pay for vs. ignore- Latest
product-pulseandship-learningsfrom prior cycle (for refresh runs)
If inputs missing: Run a 5-section guided interview anyway. Flag data gaps. Recommend running upstream skills before lock.
The 5 parts (GSBS structure)
The doc has exactly 5 sections. Don't add more. Don't merge them.
1. Target problem
A recurring, expensive problem worth solving. Not "better tools for X." Specific. Cite evidence (user quotes, win-loss patterns, support tickets).
Anti-pattern: "Help users [verb] better." Vague. Reject.
2. Approach (guiding policy, not features)
How we'll solve the target problem. The policy that guides every feature decision — not the features themselves. One-paragraph statement that someone could apply to a feature decision without seeing this doc.
Anti-pattern: A list of features ("we'll build X, Y, Z"). Reject — that's a roadmap.
3. Who-for (one persona, ideally)
The persona we focus on first. Per Crossing the Chasm: "ideally one." If two, justify why and which leads. If three or more, reject — the strategy isn't focused enough.
Anti-pattern: "PMs, marketers, and founders." Reject — that's an audience, not a persona.
4. Key metrics (SMART, anti-vanity)
2-4 metrics. Each must:
- Be Specific (named, not "engagement")
- Be Measurable (have a data source — name it)
- Be Achievable (target value, not aspirational)
- Be Relevant (ties back to target problem)
- Be Time-bound (deadline)
Apply the K2 anti-vanity-metrics rule: page views, impressions, MAU without conversion are rejected. Per Moretti: "Pick the metrics that undeniably show people are getting value."
Anti-pattern: "Increase engagement." Reject. Specify what engagement, measured how, to what target, by when.
5. Tracks (2-4 core capabilities)
The 2-4 capabilities the team will build to deliver the approach. Not features — capability areas (e.g., "fast onboarding," "AI-native search," "collaborative workflows").
If you have >4, you're not focused. Cut. If you have <2, the strategy is probably a single feature dressed as strategy.
Steps
- Phase 1 — Pre-interview load. Read recommended inputs (
company-context,icp-research,positioning, latestship-learnings). Surface data gaps before starting the interview. - Phase 2 — Guided interview. Walk the user through 5 questions, one per section. Push back when answers are vague (the anti-patterns above are common). The interview is the work — the doc is the artifact.
- Phase 3 — Draft. Compose the 5-section doc. Apply length discipline: each section ≤ 250 words, total ≤ 1500 words.
- Phase 4 — Self-roast. Run the checks below. Surface any failures before review.
- Phase 5 — Review gate (Level 3). Stakeholder review. Iterate until approved.
- Phase 6 — Lock. Set
status: locked,locked_by,locked_date,lock_version: 1. Doc is now the canonical strategy reference for the cycle. - Phase 7 — Schedule next refresh. Schedule a quarterly refresh via the
/scheduleskill or Trigger.dev cron. Default: 90 days.
Self-roast (run before review)
- Target problem cites specific evidence (user quote, win-loss pattern, ticket count) — not generic
- Approach is a policy, not a feature list
- Who-for is one persona (or 2 with justification); not an audience
- Each metric passes SMART; no vanity metrics (page views / impressions / MAU without conversion)
- Tracks count 2-4; each is a capability area, not a feature
- Total word count ≤ 1500 (single-document discipline; if longer, the strategy is unfocused)
- No requirements / specs leaked in (K6: strategy ≠ PRD)
- Refresh date scheduled
{Product name} — Product strategy
Locked: {date} · Stakeholder: {name} · Refresh: {next date}
1. Target problem
{specific, evidence-backed statement}
2. Approach
{guiding policy paragraph}
3. Who-for
{persona — ideally one}
4. Key metrics
| Metric | Source | Target | By when |
|---|---|---|---|
| ... | ... | ... | ... |
5. Tracks
- {Track 1} — {capability description}
- {Track 2} —...
## Composition rule reference
This skill is the anchor of the **PM closed loop** (P3 in `.claude/discovery/0526-every-ai-pm-guide-steal-analysis.md`). See [.claude/rules/pm-loop.md](../../../../../rules/pm-loop.md) for how `strategy-doc` ↔ `product-pulse` ↔ `ship-learnings` compose.
## Attribution
Adapted from [EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin) v3.5.0 (MIT). Source pattern: `/ce-strategy`. Framework basis: Richard Rumelt, *Good Strategy Bad Strategy*. Persona constraint basis: Geoffrey Moore, *Crossing the Chasm*.
Signals
- GitHub stars
- 36
- Forks
- 14
- Last commit
- Jul 2026
Advanced
- Catalog kind
- skill
- Gateway key
strategy-doc- Source
- github.com/matteotitta/genesys-skills