| name | product-management |
| version | 1.0.0 |
| description | Provides the "Best-Outcome" PRD framework and standard operating procedures for Product Managers. Includes templates for full PRDs, light specs, and user stories. |
| user-invocable | true |
| allowed-tools | ["Read","Write","Edit","Bash","WebSearch"] |
Product Management Skill
This skill equips you with the standard operating procedures (SOPs) and templates required to deliver "Best-Outcome" Product Requirements Documents (PRDs).
The "Best-Outcome" Protocol
To ensure engineering success, you must follow this 3-step protocol for every significant feature request.
Phase 1: The Clarification Loop (Mandatory)
Never draft a PRD from a vague prompt. You must ask questions until you can fill out the "Strategic Context" section of the PRD.
- Problem: What user pain point are we solving? (vs. just building a feature)
- Goal: What is the specific business metric we want to move? (e.g., "Increase conversion by 5%", not "Make it better")
- Constraint: What are the hard technical or timeline limits?
Phase 2: Definition & Trade-offs
Once clarified, define the solution boundaries using these frameworks:
- MoSCoW Prioritisation:
- Must Have: Non-negotiable for launch.
- Should Have: Important but can wait for a fast-follow.
- Could Have: "Nice to have" if time permits.
- Won't Have: Explicitly out of scope for this release.
- RICE Scoring (for deciding between features):
- (R)each x (I)mpact x (C)onfidence / (E)ffort
Phase 3: The Specification
Draft the PRD using the appropriate template.
- Use
prd-full.md for: New products, major features, or complex architectural changes.
- Use
prd-light.md for: Iterations, minor enhancements, or UI tweaks.
Template Library
Templates are located in the templates/ directory relative to this skill.
1. The Full PRD (templates/prd-full.md)
The "Gold Standard" for engineering specifications. It forces you to think through:
- Happy Paths vs. Edge Cases: (e.g., What if the user is offline?)
- Data Models: (e.g., specific JSON schemas or SQL table changes)
- NFRs: (Performance, Security, Accessibility)
2. The Light PRD (templates/prd-light.md)
A streamlined format for speed. Focuses on:
- Context: Why are we changing this?
- Changes: specific "Before" vs. "After" descriptions.
- Acceptance Criteria: A checklist for QA.
3. User Story Bank (templates/user-story-bank.md)
A structured file for collecting Gherkin-style requirements:
Given [context], When [action], Then [outcome].- Use this to bridge the gap between Product and QA/Automation.
Best Practices
- Be Specific: Avoid words like "fast", "easy", or "intuitive". Use "loads in <200ms", "requires <3 clicks", or "passes WCAG AA standards".
- Define Counter-Metrics: What shouldn't happen? (e.g., "We want to increase signups, but NOT increase support tickets").
- Live Documents: Treat PRDs as living specs. If requirements change during development, update the PRD.
