Compare commits
4 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 mohitagw15856
|
4f14c7cd7c | ||
 mohitagw15856
|
96109f1cdd | ||
|
mohitagw15856
|
cbd22b57a6 | ||
|
mohitagw15856
|
994bf95eba |
@@ -1,107 +1,136 @@
|
||||
# Product Management Claude Skills
|
||||
|
||||
**Transform your PM workflow with specialized Claude Skills for common product management tasks.**
|
||||
**Transform your PM workflow with 33 specialised Claude Skills across the full PM lifecycle. Save 10–15 hours per week.**
|
||||
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
|
||||
[](#available-skills)
|
||||
[](#changelog)
|
||||
|
||||
> 📖 **Built across a four-part Medium series:**
|
||||
> - Part 1 — How Skills changed my PM workflow
|
||||
> - Part 2 — The complete 12-skill toolkit
|
||||
> - Part 3 — Building Skills the right way (official guide)
|
||||
> - Part 4 — Advanced skills based on what top companies want
|
||||
> - **Part 5 — 15 new skills covering every gap in the PM lifecycle** *(new)*
|
||||
|
||||
> 📖 **Background**: Built across a four-part Medium series:
|
||||
> - [Part 1 — How Skills changed my PM workflow](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
> - [Part 2 — The complete 12-skill toolkit](https://medium.com/@mohit15856/12-claude-skills-for-product-managers-the-complete-toolkit-with-skill-files-for-jira-figma-fcc73a4c1e58)
|
||||
> - [Part 3 — Building Skills the right way (official guide)](https://medium.com/@mohit15856/claude-skills-advanced-guide-what-3-months-of-daily-pm-use-actually-taught-me-18324d6ef7bc)
|
||||
> - [Part 4 — Advanced skills based on what top companies want](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
>
|
||||
> Product Management Skills for Claude AI — 18 skills across the full PM lifecycle. Save 10+ hours per week.
|
||||
|
||||
---
|
||||
|
||||
## What Are These Skills?
|
||||
|
||||
Claude Skills are reusable, specialized procedures that teach Claude your exact workflows. Instead of re-explaining your PRD format or meeting notes structure every time, you create a Skill once and Claude automatically applies it whenever relevant.
|
||||
Claude Skills are reusable, specialised procedures that teach Claude your exact workflows. Instead of re-explaining your PRD format or meeting notes structure every time, you create a Skill once and Claude automatically applies it whenever relevant.
|
||||
|
||||
Think of Skills as "onboarding guides" for Claude—they package your best practices, templates, and processes so Claude consistently delivers outputs the way you want them.
|
||||
Think of Skills as "onboarding guides" for Claude — they package your best practices, templates, and processes so Claude consistently delivers outputs the way you want them.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Who Is This For?
|
||||
|
||||
- **Product Managers** looking to automate repetitive documentation tasks
|
||||
- **PM Teams** wanting to standardize processes and share best practices
|
||||
- **PM Teams** wanting to standardise processes and share best practices
|
||||
- **Anyone** tired of reformatting Claude's outputs to match their standards
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Quick Start (5 Minutes)
|
||||
|
||||
1. **Prerequisites**: You need Claude Pro, Team, or Enterprise account
|
||||
2. **Enable Code Execution**: Settings → Features → Enable "Code Execution and File Creation"
|
||||
3. **Install Your First Skill**:
|
||||
- Download the [`prd-template`](skills/prd-template) folder
|
||||
- Zip the folder (it should contain SKILL.md and any other files)
|
||||
- Rename the .zip to .skill (e.g., `prd-template.skill`)
|
||||
1. **Prerequisites:** Claude Pro, Team, or Enterprise account
|
||||
2. **Enable Code Execution:** Settings → Features → Enable "Code Execution and File Creation"
|
||||
3. **Install your first skill:**
|
||||
- Download a skill folder (e.g. `skills/prd-template`)
|
||||
- Zip the folder contents, rename `.zip` → `.skill`
|
||||
- Go to claude.ai → Settings → Skills → Upload Skill
|
||||
- Try it: "Help me write a PRD for a mobile app onboarding feature"
|
||||
4. **Try it:** "Help me write a PRD for a mobile app onboarding feature"
|
||||
|
||||
That's it! Claude now knows your PRD format.
|
||||
That's it. Claude now knows your format.
|
||||
|
||||
## 📦 Available Skills
|
||||
---
|
||||
|
||||
### Free Essential Skills (Included)
|
||||
## 📦 Available Skills — v3.0 (33 Skills)
|
||||
|
||||
### ✅ Free Essential Skills (Original)
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|-------|---------|------------|--------|
|
||||
| **PRD Template** | Standardized product requirements | 2-3 hrs/PRD | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | 15-30 min/meeting | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | 30-45 min/update | [View](skills/stakeholder-update) |
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | 2-3 hrs/study | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | 1-2 hrs/analysis | [View](skills/competitive-analysis) |
|
||||
|---|---|---|---|
|
||||
| **PRD Template** | Standardised product requirements | 2–3 hrs/PRD | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | 15–30 min/meeting | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | 30–45 min/update | [View](skills/stakeholder-update) |
|
||||
| **User Research Synthesis** | Analyse and synthesise research findings | 2–3 hrs/study | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | 1–2 hrs/analysis | [View](skills/competitive-analysis) |
|
||||
|
||||
### Discovery & User Research
|
||||
---
|
||||
|
||||
### 🔍 Discovery & User Research
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|---|---|---|---|
|
||||
| **User Interview Synthesis** | Synthesise transcripts into structured findings | Notion | [View](skills/user-interview-synthesis) |
|
||||
| **Assumption Mapper** | Risk-rate hidden assumptions in any PRD | Miro | [View](skills/assumption-mapper) |
|
||||
|
||||
### Roadmapping & Prioritisation
|
||||
---
|
||||
|
||||
### 🗺️ Roadmapping & Prioritisation
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **RICE Prioritisation** | Score and rank initiatives objectively | Jira | [View](skills/rice-prioritisation) |
|
||||
| **Roadmap Narrative** | Turn ranked lists into strategic narratives | Notion, Miro | [View](skills/roadmap-narrative) |
|
||||
| **RICE + Impact Matrix** | RICE scoring + strategic alignment combined | Miro, Jira | [View](skills/rice-impact-matrix) |
|
||||
|
||||
### Sprint & Delivery
|
||||
---
|
||||
|
||||
### 🚀 Sprint & Delivery
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **Sprint Brief** | Generate sprint briefs from Jira data | Jira, Slack | [View](skills/sprint-brief) |
|
||||
| **Retro Analysis** | Data-grounded retrospective briefs | Jira, Miro | [View](skills/retro-analysis) |
|
||||
|
||||
### Data & Metrics
|
||||
---
|
||||
|
||||
### 📊 Data & Metrics
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **Product Health Analysis** | Interpret metrics and surface signals | Analytics | [View](skills/product-health-analysis) |
|
||||
|
||||
### Strategy & Competitive Intel
|
||||
---
|
||||
|
||||
### 🏆 Strategy & Competitive Intel
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **Competitor Signal Tracker** | Analyse competitor moves strategically | Notion | [View](skills/competitor-signal-tracker) |
|
||||
|
||||
### Stakeholder Communication
|
||||
---
|
||||
|
||||
### 📢 Stakeholder Communication
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **PRD Template** | Standardized product requirements | — | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | — | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | — | [View](skills/stakeholder-update) |
|
||||
|---|---|---|---|
|
||||
| **Executive Update** | Sharp executive briefings | Slack, Teams | [View](skills/executive-update) |
|
||||
|
||||
### Go-to-Market & Launch
|
||||
---
|
||||
|
||||
### 🎯 Go-to-Market & Launch
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **Launch Readiness** | Pre-launch go/no-go assessment | Notion, Jira, Slack | [View](skills/launch-readiness) |
|
||||
|
||||
### Cross-functional Collaboration
|
||||
---
|
||||
|
||||
### 🤝 Cross-functional Collaboration
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | Notion | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | — | [View](skills/competitive-analysis) |
|
||||
|---|---|---|---|
|
||||
| **Design Handoff Brief** | PM-to-designer structured briefs | Figma, Notion | [View](skills/design-handoff-brief) |
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Advanced Skills (Part 4 — Role-Based Capabilities)
|
||||
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
|---|---|---|---|
|
||||
| **Competitive Intelligence Monitor** | Weekly diff-based competitor tracking | Notion, OpenClaw | [View](skills/competitive-intelligence-monitor) |
|
||||
| **Experiment Designer** | A/B test design + results interpretation | Analytics | [View](skills/experiment-designer) |
|
||||
| **Stakeholder Influence Mapper** | Influence strategy + tailored talking points | Slack | [View](skills/stakeholder-influence-mapper) |
|
||||
@@ -109,158 +138,200 @@ That's it! Claude now knows your PRD format.
|
||||
| **Multi-Source Signal Synthesiser** | Reconciles user signals across all research channels | Notion, OpenClaw | [View](skills/multi-source-signal-synthesiser) |
|
||||
| **Strategic Narrative Generator** | Roadmap-to-strategy storytelling for executives | Notion | [View](skills/strategic-narrative-generator) |
|
||||
|
||||
---
|
||||
|
||||
### 🆕 New Skills — Part 5 (15 New Skills)
|
||||
|
||||
Want a specific Skill? [Request it here](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md)
|
||||
#### Discovery & Research
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **Discovery Interview Guide** | Full screener + discussion guide + synthesis framework for user interviews | 1–2 hrs/sprint | [View](skills/discovery-interview-guide) |
|
||||
| **Job Story Mapper** | Maps JTBD across functional, emotional, and social dimensions with opportunity scoring | 1–2 hrs/workshop | [View](skills/job-story-mapper) |
|
||||
|
||||
#### Planning & Strategy
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **OKR Builder** | Writes outcome-focused OKRs, flags vanity metrics and anti-patterns automatically | 1–2 hrs/quarter | [View](skills/okr-builder) |
|
||||
| **Feature Prioritisation** | Applies RICE, MoSCoW, Kano, ICE frameworks with rationale for every decision | 1–2 hrs/sprint | [View](skills/feature-prioritisation) |
|
||||
| **Roadmap Presentation** | Now/Next/Later roadmaps calibrated to executive, team, or customer audiences | 2–3 hrs/quarter | [View](skills/roadmap-presentation) |
|
||||
| **Pricing Strategy** | Value metric, tier design, freemium decision, competitive positioning, rollout plan | 3–4 hrs/review | [View](skills/pricing-strategy) |
|
||||
|
||||
#### Delivery & Execution
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **Sprint Planning** | Sprint goals, velocity-calibrated backlogs, capacity plans, and planning agendas | 45–60 min/sprint | [View](skills/sprint-planning) |
|
||||
| **Technical Spec Template** | Full tech spec bridging product requirements and engineering implementation | 2–3 hrs/spec | [View](skills/technical-spec-template) |
|
||||
| **A/B Test Planner** | Statistically rigorous experiment design with sample size, duration, guardrail metrics | 1–2 hrs/test | [View](skills/ab-test-planner) |
|
||||
| **Go-to-Market Planner** | Cross-functional GTM plan with launch tiers, messaging, and activity tracker | 3–4 hrs/launch | [View](skills/go-to-market-planner) |
|
||||
| **Product Launch Checklist** | Pre-launch, launch day, and post-launch checklists with Go/No-Go framework | 1–2 hrs/launch | [View](skills/product-launch-checklist) |
|
||||
|
||||
#### Analysis & Metrics
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **Data Analysis Standard** | Metric deep-dives, funnel analysis, cohort studies with stakeholder-ready outputs | 2–3 hrs/analysis | [View](skills/data-analysis-standard) |
|
||||
| **Retention Analysis** | Diagnoses churn, identifies the "aha moment", recommends testable interventions | 2–3 hrs/analysis | [View](skills/retention-analysis) |
|
||||
|
||||
#### AI Product Building
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **AI Product Canvas** | Structures AI/LLM product decisions — model selection, data, evaluation, responsible AI | 3–4 hrs/canvas | [View](skills/ai-product-canvas) |
|
||||
|
||||
#### PM Rituals
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|---|---|---|---|
|
||||
| **PM Weekly Review** | 20-minute weekly metrics + shipping + insights + priorities ritual | 30–40 min/week | [View](skills/pm-weekly-review) |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Real Results
|
||||
|
||||
> "These Skills have become indispensable. I used to spend 3-4 hours every Friday on stakeholder updates. Now it takes 20 minutes to compile everything and let Claude format it. Game-changer."
|
||||
> "These Skills have become indispensable. I used to spend 3–4 hours every Friday on stakeholder updates. Now it takes 20 minutes to compile everything and let Claude format it. Game-changer."
|
||||
> — **Mohit Aggarwal, Senior PM**
|
||||
|
||||
**Time savings per week:**
|
||||
- PRD creation: -2.5 hours
|
||||
- Meeting notes: -1.5 hours
|
||||
- Stakeholder updates: -2.0 hours
|
||||
- Research synthesis: -2.5 hours
|
||||
- **Total: ~8-9 hours/week back in your schedule**
|
||||
**Time savings across all 33 skills:**
|
||||
|
||||
## 📚 Documentation
|
||||
| Activity | Before | After | Saved/week |
|
||||
|---|---|---|---|
|
||||
| PRD creation | 3–4 hrs | 45 min | ~3 hrs |
|
||||
| Sprint planning | 1.5 hrs | 30 min | ~1 hr |
|
||||
| Weekly review & update | 60 min | 20 min | ~40 min |
|
||||
| Meeting notes | 30 min | 8 min | ~20 min |
|
||||
| Stakeholder updates | 45 min | 15 min | ~30 min |
|
||||
| OKR writing | 2 hrs | 30 min | ~1.5 hrs |
|
||||
| GTM planning | 4 hrs | 1 hr | ~3 hrs |
|
||||
| Data analysis write-up | 3 hrs | 45 min | ~2 hrs |
|
||||
| **Total** | | | **~12+ hrs/week** |
|
||||
|
||||
- [Installation Guide](docs/installation.md) - Step-by-step setup
|
||||
- [Customization Guide](docs/customization.md) - Adapt Skills to your workflow
|
||||
- [Troubleshooting](docs/troubleshooting.md) - Common issues and fixes
|
||||
- [Creating Your Own Skills](docs/creating-skills.md) - Build custom Skills
|
||||
---
|
||||
|
||||
## 🛠️ Installation
|
||||
|
||||
### Method 1: Download Individual Skills (Easiest)
|
||||
|
||||
1. Navigate to the skill folder (e.g., `skills/prd-template`)
|
||||
1. Navigate to the skill folder (e.g. `skills/sprint-planning`)
|
||||
2. Download all files in that folder
|
||||
3. Create a zip file containing those files
|
||||
4. Rename from `.zip` to `.skill`
|
||||
5. Upload to Claude via Settings → Skills
|
||||
3. Create a zip file and rename `.zip` → `.skill`
|
||||
4. Upload to Claude via Settings → Skills
|
||||
|
||||
### Method 2: Clone the Repo
|
||||
|
||||
bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
|
||||
# Package a skill (creates .skill file)
|
||||
cd skills/prd-template
|
||||
zip -r ../../prd-template.skill .
|
||||
cd ../..
|
||||
|
||||
# Now upload prd-template.skill to Claude
|
||||
cd pm-claude-skills/skills/sprint-planning
|
||||
zip -r ../../sprint-planning.skill .
|
||||
# Upload sprint-planning.skill to Claude Settings → Skills
|
||||
|
||||
|
||||
### Method 3: Direct Download (When Available)
|
||||
### Method 3: Pre-packaged Releases
|
||||
Check the [Releases](https://github.com/mohitagw15856/pm-claude-skills/releases) page for bundled `.skill` files.
|
||||
|
||||
Check the [Releases](https://github.com/mohitagw15856/pm-claude-skills/releases) page for pre-packaged `.skill` files.
|
||||
---
|
||||
|
||||
## 🎓 How to Use
|
||||
|
||||
1. **Upload a Skill**: Follow installation instructions above
|
||||
2. **Just ask Claude**: Claude will automatically recognize when to use the Skill
|
||||
- "Help me write a PRD for X"
|
||||
- "Take notes from this meeting transcript"
|
||||
- "Create a competitive analysis of X, Y, Z"
|
||||
3. **No special commands needed**: Skills activate automatically based on context
|
||||
Skills activate automatically — just ask Claude naturally:
|
||||
|
||||
## 🔧 Customization
|
||||
|
||||
Every company has different formats and processes. These Skills are designed to be customized:
|
||||
"Help me plan our next sprint — we have 3 engineers and 8 points carry-over"
|
||||
"Build OKRs for our retention goal this quarter"
|
||||
"Design an A/B test for our new onboarding flow"
|
||||
"Write a job story map for our dashboard feature"
|
||||
"Create a GTM plan for our API launch in 4 weeks"
|
||||
"Build an AI product canvas for our summarisation feature"
|
||||
|
||||
1. Download the Skill folder
|
||||
2. Edit the `SKILL.md` file to match your standards
|
||||
3. Add your company's examples to the instructions
|
||||
|
||||
No slash commands. No special syntax. Claude recognises the context and loads the right skill.
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Customisation
|
||||
|
||||
1. Download the skill folder
|
||||
2. Edit `SKILL.md` to match your company's formats and terminology
|
||||
3. Add your own templates, examples, or frameworks
|
||||
4. Re-package and upload
|
||||
|
||||
See the [Customization Guide](docs/customization.md) for detailed instructions.
|
||||
See [docs/customization.md](docs/customization.md) for full instructions.
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
Found a bug? Want to suggest an improvement? Contributions are welcome!
|
||||
Contributions welcome! Current gaps:
|
||||
- Domain-specific skills (B2B SaaS, Consumer, Platform/API)
|
||||
- Tool-specific skills (Linear, Amplitude, Mixpanel)
|
||||
- Non-English language skills
|
||||
|
||||
- 🐛 [Report an Issue](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=bug-report.md)
|
||||
- 💡 [Request a Skill](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md)
|
||||
- 🔀 [Submit a Pull Request](https://github.com/mohitagw15856/pm-claude-skills/pulls)
|
||||
- 💬 [Join Discussions](https://github.com/mohitagw15856/pm-claude-skills/discussions)
|
||||
[→ Request a skill](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md) · [→ Submit a PR](https://github.com/mohitagw15856/pm-claude-skills/pulls) · [→ Join Discussions](https://github.com/mohitagw15856/pm-claude-skills/discussions)
|
||||
|
||||
See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
|
||||
|
||||
## ⭐ Show Your Support
|
||||
|
||||
If these Skills save you time, please:
|
||||
1. ⭐ Star this repository
|
||||
2. 📢 Share with fellow PMs
|
||||
3. 🐛 Report bugs or suggest improvements
|
||||
4. ✍️ Write about your experience
|
||||
---
|
||||
|
||||
## 📈 Roadmap
|
||||
|
||||
**Q1 2026:**
|
||||
- [ ] Add Data Analysis Standard Skill
|
||||
- [ ] Add Roadmap Presentation Skill
|
||||
- [ ] Create video tutorials
|
||||
- [ ] Pre-packaged .skill files in Releases
|
||||
**v3.1 (Q2 2026):**
|
||||
- [ ] Jira Integration Skill (create/update tickets via Claude)
|
||||
- [ ] Amplitude Analysis Skill (structured metric queries)
|
||||
- [ ] Linear Sprint Skill (Linear-specific sprint management)
|
||||
- [ ] B2B SaaS PM Skill Pack
|
||||
|
||||
**Q2 2026:**
|
||||
- [ ] Domain-specific Skills (SaaS PM, B2B PM, Growth PM)
|
||||
- [ ] Team collaboration Skills
|
||||
- [ ] Notion/Confluence template packs
|
||||
**v4.0 (Q3 2026):**
|
||||
- [ ] Team Skills Pack (shared skills across a PM team)
|
||||
- [ ] PM Career Coaching Skill (promotion prep, feedback synthesis)
|
||||
- [ ] Community Skill Library (submitted by the community)
|
||||
|
||||
**Long-term:**
|
||||
- [ ] Interactive Skill builder tool
|
||||
- [ ] Integration examples with PM tools
|
||||
- [ ] Community-contributed Skills library
|
||||
---
|
||||
|
||||
## 📄 License
|
||||
## 📚 Documentation
|
||||
|
||||
This project is licensed under the MIT License - see [LICENSE](LICENSE) for details.
|
||||
- [Installation Guide](docs/installation.md)
|
||||
- [Customisation Guide](docs/customization.md)
|
||||
- [Troubleshooting](docs/troubleshooting.md)
|
||||
- [Creating Your Own Skills](docs/creating-skills.md)
|
||||
|
||||
You're free to use, modify, and distribute these Skills. Attribution appreciated but not required.
|
||||
---
|
||||
|
||||
## 🙋 FAQ
|
||||
|
||||
**Q: Do I need a paid Claude account?**
|
||||
**Q: Do I need a paid Claude account?**
|
||||
A: Yes, Skills require Claude Pro, Team, or Enterprise.
|
||||
|
||||
**Q: Can I customize these Skills for my team?**
|
||||
A: Absolutely! See our [Customization Guide](docs/customization.md).
|
||||
**Q: Can I customise these for my team?**
|
||||
A: Absolutely — see the Customisation Guide.
|
||||
|
||||
**Q: Do Skills work with the Claude API?**
|
||||
A: Yes! Skills work in claude.ai, Claude Code, and via the API.
|
||||
**Q: Do Skills work with the Claude API?**
|
||||
A: Yes — claude.ai, Claude Code, and the API all support Skills.
|
||||
|
||||
**Q: What if a Skill doesn't work?**
|
||||
A: Check [Troubleshooting](docs/troubleshooting.md) or [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues).
|
||||
**Q: How do I create my own Skills?**
|
||||
A: See Creating Your Own Skills for a complete guide.
|
||||
|
||||
**Q: How do I create my own Skills?**
|
||||
A: See [Creating Your Own Skills](docs/creating-skills.md) for a complete guide.
|
||||
**Q: Can I use these commercially?**
|
||||
A: Yes — MIT licence allows commercial use.
|
||||
|
||||
**Q: Can I use these commercially?**
|
||||
A: Yes! MIT license allows commercial use.
|
||||
---
|
||||
|
||||
## 📄 Licence
|
||||
|
||||
MIT — use, modify, and distribute freely. Attribution appreciated.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Links
|
||||
|
||||
- 📝 [Original Medium Article](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
- 💼 [Connect on LinkedIn](www.linkedin.com/in/mohitaggarwal4)
|
||||
- ✉️ [Email me](mailto:mohit15856@gmail.com)
|
||||
- Writing these up and refining them took a fair few evenings. If they saved you some time, a [coffee](https://buymeacoffee.com/mohit15856) is always appreciated
|
||||
- 📝 [Part 1 — Original Medium Article](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
- 📝 Part 5 — 15 New Skills *(link once published)*
|
||||
- 💼 [Connect on LinkedIn](https://www.linkedin.com/in/mohitaggarwal4)
|
||||
- ✉️ [Email](mailto:mohit15856@gmail.com)
|
||||
|
||||
## 🙏 Acknowledgments
|
||||
|
||||
Thank you to everyone who read and shared my Medium article, and to the Anthropic team for building such a powerful feature.
|
||||
|
||||
Special thanks to the early testers who provided feedback on these Skills.
|
||||
Writing these up and refining them took a fair few evenings. If they saved you some time, [a coffee is always appreciated](https://buymeacoffee.com).
|
||||
|
||||
---
|
||||
|
||||
**Made with ☕ by [Mohit Aggarwal](https://mohit-pm.netlify.app/)**
|
||||
|
||||
*Helping product managers work smarter with AI*
|
||||
*Helping product managers work smarter with AI — one skill at a time.*
|
||||
|
||||
⭐ **Star this repo to get updates as new Skills are added!**
|
||||
⭐ **Star this repo to get notified when new skills drop.**
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: ab-test-planner
|
||||
description: Designs statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, run an A/B test, calculate sample size, or interpret test results. Triggers on "A/B test", "experiment", "split test", "statistical significance", "sample size".
|
||||
---
|
||||
|
||||
# A/B Test Planner Skill
|
||||
|
||||
Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
|
||||
|
||||
## Experiment Design Checklist
|
||||
|
||||
Before running any test, confirm:
|
||||
- [ ] Clear hypothesis with predicted direction
|
||||
- [ ] Single primary metric (plus up to 2 guardrail metrics)
|
||||
- [ ] Minimum detectable effect (MDE) defined
|
||||
- [ ] Sample size calculated
|
||||
- [ ] Test duration estimated
|
||||
- [ ] Segment isolated (no overlap with other running tests)
|
||||
- [ ] Rollback plan defined
|
||||
|
||||
## Hypothesis Template
|
||||
|
||||
> "We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."
|
||||
|
||||
Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.
|
||||
|
||||
## Sample Size Calculator Logic
|
||||
|
||||
Use this formula (provide the output, not the formula, to the user):
|
||||
|
||||
- **Baseline conversion rate:** Current rate of primary metric
|
||||
- **MDE:** Smallest change worth detecting (recommend 10–20% relative lift for most features)
|
||||
- **Statistical power:** 80% (standard)
|
||||
- **Significance level:** 95% (p < 0.05)
|
||||
|
||||
For common scenarios, provide pre-calculated estimates:
|
||||
|
||||
| Baseline Rate | MDE (Relative) | Required Sample per Variant |
|
||||
|---|---|---|
|
||||
| 5% | 20% | ~19,000 |
|
||||
| 10% | 15% | ~14,000 |
|
||||
| 20% | 10% | ~15,000 |
|
||||
| 40% | 10% | ~9,500 |
|
||||
| 60% | 5% | ~42,000 |
|
||||
|
||||
Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."
|
||||
|
||||
## Test Duration Guidance
|
||||
|
||||
Minimum: 2 full weeks (to capture weekly seasonality)
|
||||
Maximum: 4 weeks (novelty effect distorts results beyond this)
|
||||
|
||||
`Duration = Required sample ÷ (Daily traffic × % exposed)`
|
||||
|
||||
Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).
|
||||
|
||||
## Output Format
|
||||
|
||||
### A/B Test Plan — [Test Name] — [Date]
|
||||
|
||||
**Hypothesis:**
|
||||
> [Filled hypothesis template]
|
||||
|
||||
**Variants:**
|
||||
- Control (A): [Current experience]
|
||||
- Treatment (B): [Changed experience — be specific]
|
||||
|
||||
**Primary Metric:** [Metric name + how measured]
|
||||
**Guardrail Metrics:** [Metrics that must not degrade]
|
||||
|
||||
**Target Segment:** [Who sees the test — % of traffic, user type]
|
||||
**Traffic Split:** [50/50 recommended unless ramp-up needed]
|
||||
|
||||
**Sample Size Required:** ~[N] users per variant
|
||||
**Estimated Duration:** [X] weeks (based on [Y] daily eligible users)
|
||||
**Significance Threshold:** 95% confidence, 80% power
|
||||
|
||||
**Exclusions:** [Any user segments to exclude and why]
|
||||
|
||||
**Rollback Trigger:** If [guardrail metric] degrades by [X%], stop the test immediately.
|
||||
|
||||
**Results Interpretation Guide:**
|
||||
- ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
|
||||
- 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
|
||||
- ❌ Reject if: No lift or negative direction at significance
|
||||
- ⚠️ Inconclusive: Do not ship. Do not call it a win.
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
|
||||
- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
|
||||
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
|
||||
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
name: ai-product-canvas
|
||||
description: Structures AI and ML product decisions including model selection, data requirements, evaluation frameworks, and responsible AI considerations. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Triggers on "AI product", "LLM feature", "AI canvas", "build with AI", "AI integration", "AI-powered", "machine learning feature".
|
||||
---
|
||||
|
||||
# AI Product Canvas Skill
|
||||
|
||||
Define AI products with the same rigour as any product decision — but with additional layers for data, model, evaluation, and responsible AI. This canvas prevents the most common AI product failure: building a technically impressive feature that doesn't solve a real problem.
|
||||
|
||||
## AI Product Anti-Patterns to Check First
|
||||
|
||||
Before building, flag if any of these apply:
|
||||
- ❌ "We should add AI to [existing feature]" — with no user problem defined
|
||||
- ❌ Accuracy target undefined before build begins
|
||||
- ❌ No plan for what happens when the model is wrong
|
||||
- ❌ User-facing AI output with no human review or fallback
|
||||
- ❌ Training data not audited for bias or quality
|
||||
- ❌ No evaluation metric — "we'll know it when we see it"
|
||||
|
||||
---
|
||||
|
||||
## AI Product Canvas Output Format
|
||||
|
||||
### AI Product Canvas — [Feature Name] — [Date]
|
||||
|
||||
**PM Owner:** [Name]
|
||||
**ML/AI Lead:** [Name]
|
||||
**Status:** Discovery / Design / Build / Evaluation / Live
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Definition
|
||||
**User problem being solved:**
|
||||
> [What specific situation is the user in? What job are they trying to get done?]
|
||||
|
||||
**Why AI?**
|
||||
> [What makes this problem require AI vs a deterministic solution? If the answer is "because we can," stop here.]
|
||||
|
||||
**Success for the user looks like:**
|
||||
> [What outcome does the user experience when the AI feature is working well?]
|
||||
|
||||
---
|
||||
|
||||
#### 2. AI Approach
|
||||
|
||||
**Task type:**
|
||||
- [ ] Classification
|
||||
- [ ] Generation (text, image, code)
|
||||
- [ ] Summarisation / extraction
|
||||
- [ ] Recommendation
|
||||
- [ ] Search / retrieval
|
||||
- [ ] Prediction / forecasting
|
||||
- [ ] Conversation / agent
|
||||
|
||||
**Model approach:**
|
||||
- [ ] LLM API (GPT-4, Claude, Gemini, etc.) — specify: [Model name + version]
|
||||
- [ ] Fine-tuned model on own data
|
||||
- [ ] Custom model trained from scratch
|
||||
- [ ] RAG (retrieval-augmented generation)
|
||||
- [ ] Embedding + vector search
|
||||
|
||||
**Rationale for chosen approach:** [Why this, not alternatives]
|
||||
|
||||
---
|
||||
|
||||
#### 3. Data Requirements
|
||||
|
||||
| Data Type | Source | Volume | Quality Status | Bias Risk |
|
||||
|---|---|---|---|---|
|
||||
| [Training data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
| [Evaluation data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
|
||||
**Data gaps:** [What's missing and plan to get it]
|
||||
**Privacy considerations:** [Any PII in training or inference data]
|
||||
**Data ownership:** [Do we own this data? Can we use it for training?]
|
||||
|
||||
---
|
||||
|
||||
#### 4. Evaluation Framework
|
||||
|
||||
**Primary metric:** [The number that defines success — accuracy, F1, BLEU, user rating, task completion rate]
|
||||
**Minimum acceptable threshold:** [Below X, the feature does not ship]
|
||||
**Human evaluation plan:** [How will humans review model outputs? Sampling rate? Review panel?]
|
||||
|
||||
| Evaluation Type | Method | Cadence | Owner |
|
||||
|---|---|---|---|
|
||||
| Offline (pre-launch) | [Test set, benchmark] | Pre-launch | ML Lead |
|
||||
| Online (post-launch) | [A/B test, user feedback] | Weekly | PM + ML |
|
||||
| Adversarial | [Red-team, edge cases] | Pre-launch | Safety reviewer |
|
||||
|
||||
---
|
||||
|
||||
#### 5. User Experience Design
|
||||
|
||||
**How is AI output presented?**
|
||||
- [ ] Direct output shown to user (high trust required)
|
||||
- [ ] AI-assisted with user confirmation
|
||||
- [ ] Suggestion user can accept/reject
|
||||
- [ ] Background action with audit log
|
||||
|
||||
**Confidence and uncertainty handling:**
|
||||
- What happens when confidence is low? [Show alternative, ask for clarification, fallback to manual]
|
||||
- How is uncertainty communicated to the user? [UI pattern]
|
||||
|
||||
**Fallback plan:**
|
||||
- If the model fails or returns an error: [Specific fallback behaviour]
|
||||
- If accuracy degrades below threshold: [Kill switch or graceful degradation plan]
|
||||
|
||||
---
|
||||
|
||||
#### 6. Responsible AI Checklist
|
||||
|
||||
- [ ] Bias audit completed on training data
|
||||
- [ ] Demographic fairness evaluated (does performance differ by user group?)
|
||||
- [ ] Hallucination / confabulation risk assessed and mitigated
|
||||
- [ ] User can see and correct AI output
|
||||
- [ ] Opt-out mechanism exists (can user disable the AI feature?)
|
||||
- [ ] Output provenance visible when relevant (does user know AI generated this?)
|
||||
- [ ] PII not used in ways user didn't consent to
|
||||
- [ ] Regulatory review completed (GDPR, AI Act, sector-specific)
|
||||
- [ ] Model cards / documentation completed
|
||||
|
||||
---
|
||||
|
||||
#### 7. Launch & Monitoring Plan
|
||||
|
||||
**Rollout:** [% of users, with staged expansion criteria]
|
||||
**Monitoring metrics:**
|
||||
- Model performance: [Metric + alert threshold]
|
||||
- User engagement with AI output: [Acceptance rate, override rate, feedback score]
|
||||
- Error rate: [% of failed inferences]
|
||||
- Latency: [P95 target]
|
||||
|
||||
**Model refresh cadence:** [How often is the model retrained or updated?]
|
||||
**Drift detection:** [How will you know when model performance degrades in production?]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never skip the "Why AI?" section — it's the most important question in AI product development
|
||||
- The fallback UX is not optional — what happens when AI fails defines your product's trustworthiness
|
||||
- Responsible AI checklist must be completed before launch, not after
|
||||
- Include latency in success metrics — a 5-second AI response is often worse than no AI at all
|
||||
- Recommend starting with a human-in-the-loop design and automating only when accuracy is proven
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: data-analysis-standard
|
||||
description: Structures product data analysis, metric deep-dives, funnel analysis, and cohort studies. Use when asked to analyse product metrics, investigate a drop in conversion, build a dashboard spec, or explain data to stakeholders. Triggers on "analyse metrics", "funnel analysis", "cohort analysis", "data deep dive", "why did X drop".
|
||||
---
|
||||
|
||||
# Data Analysis Standard Skill
|
||||
|
||||
Turn raw numbers into product decisions. Structure every analysis with a clear question, methodology, finding, and recommended action.
|
||||
|
||||
## Analysis Framework: The 4-Question Method
|
||||
|
||||
Every analysis starts here:
|
||||
1. **What changed?** (describe the metric and its movement)
|
||||
2. **Why did it change?** (root cause — segment, funnel step, cohort, channel)
|
||||
3. **So what?** (business or product impact)
|
||||
4. **Now what?** (recommended action with confidence level)
|
||||
|
||||
Never deliver data without answering all four. A chart with no narrative is not an analysis.
|
||||
|
||||
---
|
||||
|
||||
## Metric Triage Template
|
||||
|
||||
Use when a metric has moved unexpectedly:
|
||||
|
||||
```
|
||||
METRIC: [Name]
|
||||
MOVEMENT: [X% change over Y period]
|
||||
BASELINE: [What was normal]
|
||||
|
||||
SEGMENTATION CHECK:
|
||||
- By platform (iOS / Android / Web)?
|
||||
- By user cohort (new / returning / power users)?
|
||||
- By acquisition channel?
|
||||
- By geography?
|
||||
- By plan/tier?
|
||||
|
||||
ROOT CAUSE HYPOTHESIS:
|
||||
1. [Most likely explanation] — Evidence: [data point]
|
||||
2. [Alternative explanation] — Evidence: [data point]
|
||||
3. [Ruling out] — Eliminated because: [reason]
|
||||
|
||||
CONCLUSION: [Single sentence answer to "why did this change?"]
|
||||
CONFIDENCE: [High / Medium / Low] — based on [data available]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Funnel Analysis Structure
|
||||
|
||||
| Stage | Metric | Current | Benchmark/Target | Drop-off % | Notes |
|
||||
|---|---|---|---|---|---|
|
||||
| [Top of funnel] | [Users] | [N] | [N] | — | |
|
||||
| [Step 2] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Step 3] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Conversion] | [Users] | [N] | [N] | [X%] | |
|
||||
|
||||
**Biggest drop-off:** [Step X → Step Y] — Hypothesis: [reason]
|
||||
**Recommended investigation:** [specific query or test]
|
||||
|
||||
---
|
||||
|
||||
## Cohort Analysis Guidelines
|
||||
|
||||
Always define:
|
||||
- **Cohort definition:** [What groups users — signup week, first action, plan type]
|
||||
- **Retention metric:** [What counts as retained — login, core action, revenue]
|
||||
- **Retention window:** [D1, D7, D30, W4, M3, etc.]
|
||||
|
||||
Output a cohort retention table and annotate:
|
||||
- Baseline retention for each cohort
|
||||
- Cohorts that over/underperform and why (feature launch? campaign? seasonal?)
|
||||
- Trend direction across cohorts (improving / declining / stable)
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder Analysis Output Format
|
||||
|
||||
### [Analysis Title] — [Date]
|
||||
|
||||
**Question being answered:** [Specific question in plain English]
|
||||
**Time period:** [Date range]
|
||||
**Data source:** [Where data comes from]
|
||||
|
||||
**Finding:**
|
||||
> [1–2 sentence plain-English summary of what the data shows]
|
||||
|
||||
**Key chart / table:** [Include or describe]
|
||||
|
||||
**Root cause:** [Best explanation with evidence]
|
||||
|
||||
**Confidence level:** [High / Medium / Low] — [reason]
|
||||
|
||||
**Recommended action:**
|
||||
1. [Immediate action — owner, timeline]
|
||||
2. [Investigation needed — what to check next]
|
||||
3. [Monitoring — what metric to watch and at what cadence]
|
||||
|
||||
**What this analysis does NOT tell us:** [Important caveat — what data is missing or what can't be concluded]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always state what the data *cannot* tell you — never oversell confidence
|
||||
- Correlations are not causation — flag this every time
|
||||
- If the user has no baseline, recommend establishing one before drawing conclusions
|
||||
- Recommend the simplest chart for each finding: bar for comparison, line for trends, scatter for correlation, table for detailed breakdowns
|
||||
- Always specify the time window — "conversion dropped" is meaningless without "from X to Y over Z period"
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: discovery-interview-guide
|
||||
description: Creates structured user discovery interview guides with screener questions, discussion guides, and synthesis frameworks. Use when planning user interviews, customer discovery sessions, Jobs-to-be-Done research, or problem validation. Triggers on "user interview", "discovery interview", "customer research", "JTBD", "problem validation".
|
||||
---
|
||||
|
||||
# Discovery Interview Guide Skill
|
||||
|
||||
Design interviews that surface genuine insight — not validation of what you already believe. Every guide follows a story-based, past-behaviour-focused structure.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Never ask about the future.** "Would you use X?" tells you nothing. "Tell me about the last time you did X" tells you everything.
|
||||
2. **Interview for behaviour, not opinion.** Opinions are cheap. Behaviour is evidence.
|
||||
3. **The 5 Whys.** Every surface answer is a door. Keep opening doors.
|
||||
4. **Confirm the problem before exploring the solution.** Never show a prototype until you've confirmed the pain exists unprompted.
|
||||
|
||||
## Interview Structure (60 minutes standard)
|
||||
|
||||
### 1. Warm-Up (5 min)
|
||||
Build rapport. Get them talking. Don't discuss the topic yet.
|
||||
- "Tell me a bit about your role and what a typical week looks like for you."
|
||||
- "What tools do you rely on most day-to-day?"
|
||||
|
||||
### 2. Context Setting (10 min)
|
||||
Understand their world before diving into the problem space.
|
||||
- "Walk me through how you currently [handle the domain area]."
|
||||
- "What does that process look like from start to finish?"
|
||||
- "Who else is involved when you do this?"
|
||||
|
||||
### 3. Problem Exploration (25 min) — THE CORE
|
||||
Surface pain without leading.
|
||||
- "Tell me about the last time you had to [relevant task]. What happened?"
|
||||
- "What was the hardest part of that?"
|
||||
- "How did you handle it?"
|
||||
- "What did you try before settling on that approach?"
|
||||
- "What does it cost you when this goes wrong?" (time, money, stress, reputation)
|
||||
- "If you could wave a magic wand and change one thing about this process, what would it be?"
|
||||
|
||||
⚠️ **Do not mention your product or feature during this phase.**
|
||||
|
||||
### 4. Current Solutions (10 min)
|
||||
Understand the competitive landscape from their perspective.
|
||||
- "What tools or workarounds do you use today for this?"
|
||||
- "What do you like about [current solution]? What frustrates you?"
|
||||
- "Have you tried other approaches? What happened?"
|
||||
|
||||
### 5. Wrap-Up (10 min)
|
||||
- "Is there anything about this topic we haven't covered that you think I should know?"
|
||||
- "Is there anyone else you'd recommend I speak to?"
|
||||
- "Would you be open to a follow-up if I have more questions?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Discovery Interview Guide — [Topic] — [Date]
|
||||
|
||||
**Research Goal:** [One sentence: what decision will this research inform?]
|
||||
**Target Participant Profile:** [Role, company size, behaviour qualifier]
|
||||
|
||||
**Screener Questions** (for recruiting):
|
||||
1. [Question] → Must answer: [Y/N or specific]
|
||||
2. [Question] → Must answer: [Y/N or specific]
|
||||
3. [Disqualifier question] → Disqualify if: [answer]
|
||||
|
||||
**Interview Guide:**
|
||||
|
||||
[Full structured guide using the format above, customised to the specific research topic]
|
||||
|
||||
**Synthesis Template** (fill after each interview):
|
||||
- Key quote: "[verbatim]"
|
||||
- Core pain: [1 sentence]
|
||||
- Current workaround: [what they're doing today]
|
||||
- Intensity (1–5): [how painful is this?]
|
||||
- Surprise/unexpected finding: [anything that challenged your assumptions]
|
||||
|
||||
**Pattern Detection** (after 5+ interviews):
|
||||
- Pain mentioned by [X/N] participants: [theme]
|
||||
- Workaround used by [X/N] participants: [theme]
|
||||
- Most emotionally charged moment in interviews: [observation]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Recommend 5–8 interviews to reach thematic saturation for most discovery questions
|
||||
- Always record with permission — transcripts beat notes
|
||||
- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
|
||||
- Never synthesise during the interview — do it after, when you can look across sessions
|
||||
- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: feature-prioritisation
|
||||
description: Applies prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs. Triggers on "prioritise features", "what should we build", "backlog grooming", "RICE score", "MoSCoW".
|
||||
---
|
||||
|
||||
# Feature Prioritisation Skill
|
||||
|
||||
Apply the right prioritisation framework to any backlog and produce a clear, defensible ranking with rationale — not just a sorted list.
|
||||
|
||||
## Framework Selection Guide
|
||||
|
||||
Ask the user which framework they prefer, or recommend based on context:
|
||||
|
||||
| Situation | Recommended Framework |
|
||||
|---|---|
|
||||
| Need a quick, data-driven score | RICE |
|
||||
| Stakeholder alignment meeting | MoSCoW |
|
||||
| Understanding customer delight vs expectations | Kano |
|
||||
| Early-stage startup, fast decisions | ICE |
|
||||
| Identifying underserved customer needs | Opportunity Scoring |
|
||||
| Strategic portfolio decisions | Value vs Effort Matrix |
|
||||
|
||||
---
|
||||
|
||||
## RICE Scoring
|
||||
|
||||
**Formula:** (Reach × Impact × Confidence) ÷ Effort
|
||||
|
||||
| Factor | Definition | Scale |
|
||||
|---|---|---|
|
||||
| Reach | Users impacted per quarter | Actual number |
|
||||
| Impact | Effect on goal per user | 0.25 / 0.5 / 1 / 2 / 3 |
|
||||
| Confidence | How certain are you? | 50% / 80% / 100% |
|
||||
| Effort | Person-months required | Actual number |
|
||||
|
||||
Output table:
|
||||
| Feature | Reach | Impact | Confidence | Effort | RICE Score | Priority |
|
||||
|---|---|---|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## MoSCoW Method
|
||||
|
||||
Categorise each feature as:
|
||||
- **Must Have** — non-negotiable for launch/sprint; product fails without it
|
||||
- **Should Have** — important but not critical; workarounds exist
|
||||
- **Could Have** — nice to have; include only if time allows
|
||||
- **Won't Have (this time)** — explicitly out of scope now; may revisit
|
||||
|
||||
Always ask: "Must have for *what*?" — define the scope (launch, sprint, quarter) before categorising.
|
||||
|
||||
---
|
||||
|
||||
## ICE Scoring (Startup/fast mode)
|
||||
|
||||
**Formula:** Impact + Confidence + Ease (each 1–10)
|
||||
|
||||
Quick, subjective — good for early decisions before data exists.
|
||||
|
||||
---
|
||||
|
||||
## Kano Model
|
||||
|
||||
Classify features into:
|
||||
- **Basic (Must-be):** Expected; absence causes dissatisfaction
|
||||
- **Performance:** More = better satisfaction; linear relationship
|
||||
- **Excitement (Delighters):** Unexpected; creates delight; absence is neutral
|
||||
- **Indifferent:** Users don't care either way
|
||||
- **Reverse:** Some users want it, others don't
|
||||
|
||||
Recommend building: all Basic features first → Performance features for key use cases → 1–2 Excitement features per release.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Feature Prioritisation — [Product/Team] — [Date]
|
||||
|
||||
**Framework Used:** [RICE / MoSCoW / ICE / Kano / Custom]
|
||||
**Scope:** [Sprint / Quarter / Release]
|
||||
**Goal being prioritised against:** [Metric or objective]
|
||||
|
||||
[Scored table using selected framework]
|
||||
|
||||
**Recommended Build Order:**
|
||||
1. [Feature] — [1-line rationale]
|
||||
2. [Feature] — [1-line rationale]
|
||||
3. ...
|
||||
|
||||
**Explicitly Deprioritised:**
|
||||
- [Feature] — Reason: [brief]
|
||||
|
||||
**Assumptions Made:**
|
||||
- [Any estimates or judgements used in scoring]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always anchor prioritisation to a specific goal or metric — never prioritise in a vacuum
|
||||
- Flag when two features have similar scores but very different risk profiles
|
||||
- If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
|
||||
- Recommend revisiting priorities every 2 weeks minimum
|
||||
- Never produce a single-column ranked list without rationale — explain the top 3 and bottom 3 decisions
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: go-to-market-planner
|
||||
description: Builds go-to-market (GTM) plans for product launches, feature releases, and new market entries. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Triggers on "go-to-market", "GTM plan", "product launch plan", "launch strategy", "release plan".
|
||||
---
|
||||
|
||||
# Go-to-Market Planner Skill
|
||||
|
||||
Produce a complete, cross-functional GTM plan that aligns product, marketing, sales, and support around a single launch — with clear owners, timelines, and success metrics.
|
||||
|
||||
## Launch Tier Framework
|
||||
|
||||
Before planning, classify the launch:
|
||||
|
||||
| Tier | Scope | Typical Effort | Examples |
|
||||
|---|---|---|---|
|
||||
| **Tier 1 — Major Launch** | New product / significant platform change | 8–12 weeks | New pricing model, platform rebrand, new product line |
|
||||
| **Tier 2 — Feature Launch** | Significant new capability | 4–6 weeks | Major feature, API release, new integration |
|
||||
| **Tier 3 — Incremental Release** | Improvement, bug fix, minor feature | 1–2 weeks | UI tweak, performance improvement, small enhancement |
|
||||
|
||||
Always confirm tier with the user before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## GTM Plan Output Format
|
||||
|
||||
### GTM Plan — [Product/Feature Name] — [Launch Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner (PM):** [Name]
|
||||
**Target Launch Date:** [Date]
|
||||
**Soft Launch Date (Beta/Limited):** [Date, if applicable]
|
||||
|
||||
---
|
||||
|
||||
### 1. What We're Launching
|
||||
**One-line description:** [What it is, for whom, and why now]
|
||||
**Key customer problem solved:** [Specific pain point]
|
||||
**Key differentiator:** [Why ours, why now]
|
||||
|
||||
---
|
||||
|
||||
### 2. Target Audience
|
||||
**Primary segment:** [Who benefits most — be specific]
|
||||
**Secondary segment:** [Who else benefits]
|
||||
**Not for:** [Who this is NOT for — helps sales and support]
|
||||
|
||||
---
|
||||
|
||||
### 3. Messaging
|
||||
|
||||
**Headline:** [Customer-facing headline — lead with outcome, not feature]
|
||||
**Sub-headline:** [Supporting context — how it works or why it matters]
|
||||
**3 key messages:**
|
||||
1. [Problem solved]
|
||||
2. [How it works / what's new]
|
||||
3. [Proof / social proof / data]
|
||||
|
||||
**Elevator pitch (30 seconds):**
|
||||
> [For [target user] who [has this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternative], we [differentiator].]
|
||||
|
||||
---
|
||||
|
||||
### 4. Launch Activities by Function
|
||||
|
||||
| Function | Activity | Owner | Due Date | Status |
|
||||
|---|---|---|---|---|
|
||||
| Product | Feature flagging / rollout plan | PM | [date] | |
|
||||
| Marketing | Blog post / landing page | Marketing | [date] | |
|
||||
| Marketing | Email campaign to existing users | Marketing | [date] | |
|
||||
| Marketing | Social media content | Marketing | [date] | |
|
||||
| Sales | Sales enablement deck | PM + Sales | [date] | |
|
||||
| Sales | FAQ for sales team | PM | [date] | |
|
||||
| Support | Help centre articles | Support | [date] | |
|
||||
| Support | Support team training | Support | [date] | |
|
||||
| Engineering | Monitoring/alerting in place | Eng | [date] | |
|
||||
|
||||
---
|
||||
|
||||
### 5. Success Metrics
|
||||
|
||||
| Metric | Baseline | Target | Measurement Window |
|
||||
|---|---|---|---|
|
||||
| [Adoption metric] | [X] | [Y] | 30 days post-launch |
|
||||
| [Engagement metric] | [X] | [Y] | 60 days post-launch |
|
||||
| [Business metric] | [X] | [Y] | 90 days post-launch |
|
||||
|
||||
---
|
||||
|
||||
### 6. Risks & Contingencies
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Action if it happens] |
|
||||
|
||||
---
|
||||
|
||||
### 7. Launch Day Checklist
|
||||
- [ ] Feature live for [X%] of users
|
||||
- [ ] Monitoring dashboard active
|
||||
- [ ] Support team briefed
|
||||
- [ ] Blog post published
|
||||
- [ ] Email sent / scheduled
|
||||
- [ ] Sales team notified
|
||||
- [ ] Executive announcement sent (if Tier 1)
|
||||
- [ ] Rollback procedure confirmed
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never plan a Tier 1 launch without at least 8 weeks of lead time
|
||||
- Always include a "Not for" section — it prevents misdirected sales and support tickets
|
||||
- Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
|
||||
- Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: job-story-mapper
|
||||
description: Writes Jobs-to-be-Done (JTBD) job stories and maps customer jobs across functional, social, and emotional dimensions. Use when defining user needs, writing job stories, conducting JTBD research, or reframing features around customer outcomes. Triggers on "job story", "JTBD", "jobs to be done", "when I want to", "user need", "hire a product".
|
||||
---
|
||||
|
||||
# Job Story Mapper Skill
|
||||
|
||||
Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.
|
||||
|
||||
## Jobs-to-be-Done Fundamentals
|
||||
|
||||
A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.
|
||||
|
||||
Three dimensions of every job:
|
||||
- **Functional job:** The practical task ("get from A to B")
|
||||
- **Emotional job:** How they want to feel ("feel confident I made the right choice")
|
||||
- **Social job:** How they want to be perceived ("look like a competent professional to my team")
|
||||
|
||||
Great products address all three. Most roadmaps only address the functional one.
|
||||
|
||||
---
|
||||
|
||||
## Job Story Format
|
||||
|
||||
**Template:**
|
||||
> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].
|
||||
|
||||
**Not a user story:**
|
||||
User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."
|
||||
Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."
|
||||
|
||||
**The situation is the most important part.** "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."
|
||||
|
||||
---
|
||||
|
||||
## Mapping Process
|
||||
|
||||
### Step 1: Identify the main job
|
||||
One sentence: What is the core job your product is hired for?
|
||||
> "Help [user type] [accomplish outcome] when [context]."
|
||||
|
||||
### Step 2: Break into job steps
|
||||
What are all the sub-tasks within the main job?
|
||||
(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)
|
||||
|
||||
### Step 3: Identify pain points per step
|
||||
Where does the job fall down today? Where do customers use workarounds?
|
||||
|
||||
### Step 4: Write job stories for each pain point
|
||||
One job story per distinct situation-motivation pair.
|
||||
|
||||
### Step 5: Map to product opportunities
|
||||
Which job stories are underserved? Which have existing solutions? Where is your differentiation?
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Job Story Map — [Product/Feature Area] — [Date]
|
||||
|
||||
**Core Job Statement:**
|
||||
> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].
|
||||
|
||||
---
|
||||
|
||||
**Job Map:**
|
||||
|
||||
| Step | Sub-Job | Current Solution | Pain Points | Underserved? |
|
||||
|---|---|---|---|---|
|
||||
| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |
|
||||
| Locate | | | | |
|
||||
| Prepare | | | | |
|
||||
| Confirm | | | | |
|
||||
| Execute | | | | |
|
||||
| Monitor | | | | |
|
||||
| Modify | | | | |
|
||||
| Conclude | | | | |
|
||||
|
||||
---
|
||||
|
||||
**Job Stories (prioritised by underservice):**
|
||||
|
||||
**Job Story 1 — [Situation label]**
|
||||
> When [specific situation], I want to [motivation], so I can [outcome].
|
||||
|
||||
Functional dimension: [What they need to get done]
|
||||
Emotional dimension: [How they want to feel]
|
||||
Social dimension: [How they want to be perceived]
|
||||
|
||||
Current workaround: [What they do today]
|
||||
Pain intensity: [High / Medium / Low]
|
||||
Frequency: [How often this situation occurs]
|
||||
Product opportunity: [What we could build to address this]
|
||||
|
||||
---
|
||||
|
||||
Repeat for each major job story.
|
||||
|
||||
**Opportunity Scoring:**
|
||||
Rate each job story on:
|
||||
- Importance to customer (1–10)
|
||||
- Satisfaction with current solution (1–10)
|
||||
- Opportunity score = Importance + max(Importance – Satisfaction, 0)
|
||||
- Prioritise: Opportunity score > 10
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never write a job story for a feature — write it for the situation that makes the feature valuable
|
||||
- If you can't identify the situation, you don't understand the job yet — go back to user research
|
||||
- Social and emotional jobs are harder to surface but often the most defensible differentiators
|
||||
- Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: okr-builder
|
||||
description: Creates well-structured OKRs (Objectives and Key Results) for product teams, startups, and individuals. Use when asked to write OKRs, set quarterly goals, define key results, or review existing OKRs. Triggers on "OKR", "objective and key results", "quarterly goals", "north star metric".
|
||||
---
|
||||
|
||||
# OKR Builder Skill
|
||||
|
||||
Write ambitious, measurable OKRs that connect product work to company strategy. Avoid vanity metrics, output-focused key results, and objectives that sound like task lists.
|
||||
|
||||
## OKR Fundamentals
|
||||
|
||||
**Objective:** Qualitative, inspiring, time-bound. Answers "where are we going?"
|
||||
**Key Result:** Quantitative, specific, measurable. Answers "how will we know we've arrived?"
|
||||
|
||||
### The Test for a Good KR
|
||||
- Can it be scored 0.0–1.0 at the end of the period?
|
||||
- Does it measure outcome, not output? ("Revenue from new customers increased by 30%" not "Launch 3 features")
|
||||
- Is it ambitious but achievable? (Aim for 70% attainment as the gold standard)
|
||||
- Is it within the team's control?
|
||||
|
||||
## Common OKR Anti-Patterns to Flag and Fix
|
||||
|
||||
| Anti-Pattern | Example | Better Version |
|
||||
|---|---|---|
|
||||
| Task masquerading as KR | "Launch onboarding redesign" | "New user activation rate increases from 42% to 65%" |
|
||||
| Vanity metric | "Get 10,000 app downloads" | "30-day retention for new users reaches 40%" |
|
||||
| Binary KR | "Ship API v2" | "API v2 adopted by 80% of active integrations" |
|
||||
| Too many KRs | 6+ per objective | Max 3–4 KRs per objective |
|
||||
| No baseline | "Improve NPS" | "NPS increases from 32 to 50" |
|
||||
|
||||
Always flag anti-patterns and offer a rewrite.
|
||||
|
||||
## Output Format
|
||||
|
||||
### [Quarter] OKRs — [Team/Product Area]
|
||||
|
||||
---
|
||||
|
||||
**Objective 1: [Inspiring, qualitative statement]**
|
||||
|
||||
*Why this matters:* [1–2 sentence strategic context]
|
||||
|
||||
| # | Key Result | Baseline | Target | Measurement Method |
|
||||
|---|---|---|---|---|
|
||||
| KR1 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
| KR2 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
| KR3 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
|
||||
*Owner:* [Name/Role]
|
||||
*Check-in cadence:* Weekly
|
||||
|
||||
---
|
||||
|
||||
Repeat for each objective. Recommend 2–4 objectives per team per quarter.
|
||||
|
||||
## Scoring Guide to Include
|
||||
|
||||
At quarter end, score each KR:
|
||||
- 0.7–1.0 = Excellent (0.7 is the "sweet spot" — if all KRs score 1.0, they weren't ambitious enough)
|
||||
- 0.4–0.6 = Made progress but missed
|
||||
- 0.0–0.3 = Missed — needs retrospective discussion
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always ask for the company-level or product-level North Star metric before writing OKRs
|
||||
- Recommend no more than 3 objectives per team per quarter
|
||||
- If user provides output-based goals, always reframe as outcomes
|
||||
- Include a "health check" section flagging which KRs have no current baseline data
|
||||
- Remind user: OKRs are not performance reviews — they should be ambitious enough that missing them is okay
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: pm-weekly-review
|
||||
description: Structures a PM's weekly review and planning session — synthesising metrics, shipping progress, blockers, and next-week priorities into a shareable update. Use when doing a weekly PM review, writing a weekly update, preparing for a Monday planning session, or reviewing sprint health. Triggers on "weekly review", "weekly update", "PM standup", "weekly planning", "end of week summary".
|
||||
---
|
||||
|
||||
# PM Weekly Review Skill
|
||||
|
||||
Turn the chaotic end-of-week brain dump into a structured 20-minute ritual that keeps you, your team, and your stakeholders aligned — without a meeting.
|
||||
|
||||
## The Weekly Review Structure (20 minutes)
|
||||
|
||||
**5 min — Metrics check:** What moved? What didn't? What's surprising?
|
||||
**5 min — Ship progress:** What shipped? What slipped? What's blocked?
|
||||
**5 min — Insights:** Any customer feedback, support tickets, or research findings?
|
||||
**5 min — Next week priorities:** What are the 3 things that matter most?
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### PM Weekly Review — Week of [Date]
|
||||
|
||||
**Product Area:** [What you own]
|
||||
**Written by:** [PM Name]
|
||||
**Time to read:** ~3 minutes
|
||||
|
||||
---
|
||||
|
||||
### 📊 Metrics This Week
|
||||
|
||||
| Metric | This Week | Last Week | Target | Trend |
|
||||
|---|---|---|---|---|
|
||||
| [Primary metric] | [Value] | [Value] | [Target] | ↑ / ↓ / → |
|
||||
| [Secondary metric] | [Value] | [Value] | [Target] | ↑ / ↓ / → |
|
||||
| [Health metric] | [Value] | [Value] | [Target] | ↑ / ↓ / → |
|
||||
|
||||
**Notable movement:**
|
||||
- [What changed and why — 1 sentence each]
|
||||
|
||||
**Concern to watch:**
|
||||
- [Anything trending in the wrong direction]
|
||||
|
||||
---
|
||||
|
||||
### 🚢 This Week's Progress
|
||||
|
||||
**Shipped:**
|
||||
- ✅ [What went live] — [1-line impact or observation]
|
||||
|
||||
**In Progress:**
|
||||
- 🔄 [Feature/initiative] — [% complete or current status]
|
||||
|
||||
**Slipped / Blocked:**
|
||||
- ⚠️ [What didn't happen] — Reason: [brief] — Action: [who's unblocking it]
|
||||
|
||||
**Carry-forward to next week:**
|
||||
- [Item + why it's carrying over]
|
||||
|
||||
---
|
||||
|
||||
### 💡 Insights & Signals
|
||||
|
||||
**Customer feedback:**
|
||||
- "[Quote or paraphrase]" — Source: [user/channel] — Theme: [tag]
|
||||
|
||||
**Support signals:**
|
||||
- [Top ticket category this week + volume]
|
||||
- [Anything that signals a product gap]
|
||||
|
||||
**Research / data:**
|
||||
- [Any discovery from user interviews, analytics, or experiments]
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Next Week — Top 3 Priorities
|
||||
|
||||
| # | Priority | Why This Week | Owner | Done = |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Most important thing] | [Reason it can't wait] | [Name] | [Clear definition of done] |
|
||||
| 2 | [Second priority] | [Why] | [Name] | [Done criteria] |
|
||||
| 3 | [Third priority] | [Why] | [Name] | [Done criteria] |
|
||||
|
||||
**Decisions needed:**
|
||||
- [Any decision that's blocking progress — who needs to make it]
|
||||
|
||||
**Asks / dependencies:**
|
||||
- [What you need from engineering / design / data / leadership]
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Reflection (Optional but powerful)
|
||||
|
||||
> What's one thing from this week I'd do differently?
|
||||
> [Your honest answer — 1–2 sentences]
|
||||
|
||||
> What's the biggest unknown I'm carrying into next week?
|
||||
> [Name the uncertainty explicitly]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Keep the whole document under 400 words — if stakeholders won't read it, it doesn't exist
|
||||
- The reflection section is for you, not your stakeholders — keep it honest
|
||||
- Always name a clear owner for every blocked item — "the team will figure it out" is a blocker in disguise
|
||||
- Recommend sending this by end of Friday — Monday morning is too late to course-correct
|
||||
- If three weeks of weekly reviews show the same blocked item, escalate immediately
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: pricing-strategy
|
||||
description: Structures pricing strategy decisions, packaging options, and pricing page design for SaaS and digital products. Use when reviewing or setting pricing, designing pricing tiers, evaluating freemium vs paid, or preparing a pricing change. Triggers on "pricing strategy", "pricing tiers", "freemium", "pricing page", "how should we price", "pricing change".
|
||||
---
|
||||
|
||||
# Pricing Strategy Skill
|
||||
|
||||
Build pricing that reflects value delivered — not cost to build. Structure every pricing decision with customer segmentation, value metric identification, competitive context, and a packaging recommendation.
|
||||
|
||||
## Pricing Foundations
|
||||
|
||||
Three questions to answer before any pricing decision:
|
||||
1. **Who is our buyer?** (Role, company size, willingness to pay)
|
||||
2. **What value do we deliver?** (Quantifiable outcome — time saved, revenue generated, risk reduced)
|
||||
3. **What is our pricing model?** (Per seat, usage-based, flat, hybrid)
|
||||
|
||||
---
|
||||
|
||||
## Pricing Models
|
||||
|
||||
| Model | Best For | Risk |
|
||||
|---|---|---|
|
||||
| **Per Seat** | Collaboration tools, team software | Disincentivises adoption as team grows |
|
||||
| **Usage-Based** | APIs, infrastructure, consumption tools | Revenue unpredictability for both sides |
|
||||
| **Flat Rate** | Simple tools, early-stage | Leaves money on table from power users |
|
||||
| **Tiered** | Products with clear user segments | Feature gatekeeping frustrates users |
|
||||
| **Freemium** | Viral/PLG products with low marginal cost | Conversion to paid is hard to engineer |
|
||||
| **Value-Based** | Enterprise, outcomes-driven products | Requires strong ROI story |
|
||||
|
||||
---
|
||||
|
||||
## Freemium Decision Framework
|
||||
|
||||
Use freemium when:
|
||||
- ✅ Marginal cost per free user is near zero
|
||||
- ✅ Product is inherently viral (network effects or sharing)
|
||||
- ✅ Free tier creates genuine value (not just a demo)
|
||||
- ✅ Clear upgrade trigger exists (feature, volume, or team size)
|
||||
- ✅ Conversion benchmark is realistic (2–5% free-to-paid is typical)
|
||||
|
||||
Avoid freemium when:
|
||||
- ❌ Support cost per free user is high
|
||||
- ❌ No natural upgrade trigger in the product
|
||||
- ❌ Core value requires features you'd need to gate
|
||||
|
||||
---
|
||||
|
||||
## Packaging / Tiering Framework
|
||||
|
||||
Recommended 3-tier structure for SaaS:
|
||||
|
||||
| Tier | Target | Price Signal | Key Features | Lock-in Mechanism |
|
||||
|---|---|---|---|---|
|
||||
| **Free / Starter** | Individual, early discovery | $0 | Core value, usage-limited | Invite colleagues, export limit |
|
||||
| **Pro / Growth** | SMB, growing teams | $[X]/seat/mo | Full features, higher limits | Team collaboration, integrations |
|
||||
| **Business / Enterprise** | Mid-market, enterprise | $[X]/seat/mo or custom | Admin, SSO, SLAs, dedicated support | Security, compliance, volume |
|
||||
|
||||
Tier design rules:
|
||||
- Each tier should be genuinely sufficient for its target segment
|
||||
- The upgrade trigger should be felt naturally — not manufactured
|
||||
- Price jumps of 3–5x between tiers are normal and defensible
|
||||
|
||||
---
|
||||
|
||||
## Competitive Pricing Context
|
||||
|
||||
| Competitor | Model | Price | Key Differentiator |
|
||||
|---|---|---|---|
|
||||
| [Name] | [Model] | [Price] | [What they lead with] |
|
||||
|
||||
Positioning options:
|
||||
- **Premium:** Price 20–40% above market. Justify with enterprise features, support, or brand.
|
||||
- **Parity:** Match the market leader. Win on product or distribution.
|
||||
- **Value:** Price below market. Win on volume. Dangerous without strong unit economics.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Pricing Strategy Recommendation — [Product] — [Date]
|
||||
|
||||
**Current State:** [What pricing exists today, if any]
|
||||
**Problem to Solve:** [Why pricing is being reviewed]
|
||||
|
||||
**Recommended Pricing Model:** [Model name + rationale]
|
||||
|
||||
**Value Metric:** [The single unit that scales with customer value — e.g., "active users", "API calls", "documents processed"]
|
||||
|
||||
**Proposed Tiers:**
|
||||
|
||||
[Table using 3-tier structure above]
|
||||
|
||||
**Free-to-Paid Upgrade Trigger:** [Specific moment or threshold that creates natural upgrade pressure]
|
||||
|
||||
**Competitive Position:** [Premium / Parity / Value + reasoning]
|
||||
|
||||
**Pricing Change Rollout (if applicable):**
|
||||
- Grandfathering: [Yes / No — recommendation and rationale]
|
||||
- Communication plan: [How to tell customers + timing]
|
||||
- Rollback plan: [Under what conditions you'd revert]
|
||||
|
||||
**Risks:**
|
||||
- [Risk] → Mitigation: [Action]
|
||||
|
||||
**Metrics to Monitor Post-Change:**
|
||||
- Conversion rate (free to paid)
|
||||
- Churn rate by tier
|
||||
- Average revenue per user (ARPU)
|
||||
- Expansion revenue
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never price based on cost — price based on value delivered to the customer
|
||||
- Always A/B test price changes where possible; use geographic holdouts if A/B isn't feasible
|
||||
- Recommend annual pricing with 15–20% discount — improves cash flow and reduces churn
|
||||
- If enterprise pricing is "contact us", recommend adding a price floor to qualify inbound
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: product-launch-checklist
|
||||
description: Generates comprehensive pre-launch, launch day, and post-launch checklists for product releases. Use when preparing for a product launch, feature release, or major update. Triggers on "launch checklist", "pre-launch", "launch day", "release checklist", "ship checklist", "go-live checklist".
|
||||
---
|
||||
|
||||
# Product Launch Checklist Skill
|
||||
|
||||
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
Provide:
|
||||
- Launch name and date
|
||||
- Launch tier (1 = major, 2 = feature, 3 = incremental)
|
||||
- Team members and their roles
|
||||
|
||||
The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Checklist — [Feature/Product Name] — Target Date: [Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner:** [PM Name]
|
||||
**Engineering Lead:** [Name]
|
||||
**Go/No-Go Decision By:** [Date and time — typically 24 hours before launch]
|
||||
|
||||
---
|
||||
|
||||
### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)
|
||||
- [ ] Feature flag created and tested in staging
|
||||
- [ ] All acceptance criteria signed off by PM
|
||||
- [ ] Code reviewed and merged to main
|
||||
- [ ] QA sign-off completed (regression + new feature)
|
||||
- [ ] Performance testing completed (load, latency)
|
||||
- [ ] Security review completed (if data or auth changes)
|
||||
- [ ] Rollback procedure documented and tested
|
||||
- [ ] Monitoring and alerting configured
|
||||
- [ ] Error logging in place with correct severity levels
|
||||
- [ ] Database migrations tested on staging with production data volume
|
||||
|
||||
### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week)
|
||||
- [ ] Blog post written, reviewed, and scheduled
|
||||
- [ ] In-app announcement or tooltip configured
|
||||
- [ ] Email campaign drafted and QA'd
|
||||
- [ ] Social media posts drafted and scheduled
|
||||
- [ ] Landing page or feature page live in staging
|
||||
- [ ] Press outreach sent (Tier 1 only)
|
||||
- [ ] Product Hunt / community posts prepared (Tier 1 only)
|
||||
|
||||
### 🎓 PRE-LAUNCH — Sales & Support (T-1 week)
|
||||
- [ ] Sales enablement one-pager completed
|
||||
- [ ] FAQ document shared with sales and support teams
|
||||
- [ ] Help centre articles written and published
|
||||
- [ ] Support team demo / training completed
|
||||
- [ ] Customer success team briefed on top accounts
|
||||
- [ ] Pricing updated (if applicable)
|
||||
- [ ] Contracts / ToS updated (if applicable)
|
||||
|
||||
### 📊 PRE-LAUNCH — Analytics (T-1 week)
|
||||
- [ ] Analytics events firing correctly in staging
|
||||
- [ ] Dashboard configured for launch metrics
|
||||
- [ ] Baseline metrics documented
|
||||
- [ ] Success criteria documented and shared with team
|
||||
- [ ] A/B test configured (if applicable)
|
||||
|
||||
---
|
||||
|
||||
### ✅ GO / NO-GO DECISION — T-24 hours
|
||||
|
||||
| Criteria | Status | Owner |
|
||||
|---|---|---|
|
||||
| All critical bugs resolved | 🟢 / 🔴 | Eng Lead |
|
||||
| QA sign-off complete | 🟢 / 🔴 | QA |
|
||||
| Rollback tested | 🟢 / 🔴 | Eng Lead |
|
||||
| Help centre articles live | 🟢 / 🔴 | Support |
|
||||
| Monitoring active | 🟢 / 🔴 | Eng Lead |
|
||||
| PM sign-off | 🟢 / 🔴 | PM |
|
||||
|
||||
**Go / No-Go Decision:** [GO / NO-GO]
|
||||
**Decision Owner:** [PM + Eng Lead jointly]
|
||||
|
||||
---
|
||||
|
||||
### 🚀 LAUNCH DAY
|
||||
- [ ] Feature flag enabled for [X%] of users (start low — 5–10%)
|
||||
- [ ] Launch confirmed in team Slack/channel
|
||||
- [ ] Metrics dashboard open and being monitored
|
||||
- [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr
|
||||
- [ ] Blog post published / email sent
|
||||
- [ ] Social posts live
|
||||
- [ ] Support team on standby for first 4 hours
|
||||
- [ ] PM available and reachable all day
|
||||
- [ ] Feature flag expanded to 50% if T+2hr checks pass
|
||||
- [ ] Feature flag expanded to 100% if T+4hr checks pass
|
||||
|
||||
---
|
||||
|
||||
### 📈 POST-LAUNCH (D+7, D+30)
|
||||
- [ ] D+7 metrics review: adoption, errors, support tickets
|
||||
- [ ] D+7 customer feedback synthesised
|
||||
- [ ] Retrospective scheduled
|
||||
- [ ] Learnings documented
|
||||
- [ ] D+30 success metrics reviewed against targets
|
||||
- [ ] Feature flag removed from codebase (clean up)
|
||||
- [ ] Follow-up features added to backlog based on feedback
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
- Never launch on a Friday unless you have weekend engineering coverage
|
||||
- Recommend starting all launches at <10% traffic — even for simple features
|
||||
- Document rollback time: "We can revert this in X minutes" should be known before launch
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
name: retention-analysis
|
||||
description: Structures retention analysis, churn investigations, and engagement deep-dives for product teams. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Triggers on "retention analysis", "churn", "DAU/MAU", "user retention", "why are users leaving".
|
||||
---
|
||||
|
||||
# Retention Analysis Skill
|
||||
|
||||
Diagnose why users leave, identify what keeps them, and recommend specific, testable interventions — not vague "improve onboarding" suggestions.
|
||||
|
||||
## Retention Fundamentals
|
||||
|
||||
**The retention curve has two components:**
|
||||
1. **Steepness of initial drop** (D1–D7) — onboarding problem
|
||||
2. **Long-term floor level** — product-market fit indicator
|
||||
|
||||
A product with PMF has a retention curve that flattens. If it trends to zero, you have a PMF problem, not an onboarding problem. Name this distinction explicitly.
|
||||
|
||||
---
|
||||
|
||||
## Retention Metrics Definitions
|
||||
|
||||
| Metric | Formula | What It Tells You |
|
||||
|---|---|---|
|
||||
| D1 Retention | Users who return on day 2 ÷ new users day 1 | Quality of first experience |
|
||||
| D7 Retention | Users active on day 8 ÷ users who joined 7 days ago | Early habit formation |
|
||||
| D30 Retention | Users active on day 31 ÷ users who joined 30 days ago | Product-market fit signal |
|
||||
| DAU/MAU Ratio | Daily active users ÷ monthly active users | Stickiness (>20% good, >50% excellent) |
|
||||
| Churn Rate | Users lost in period ÷ users at start of period | Monthly or annual |
|
||||
| Net Revenue Retention | MRR at end of period ÷ MRR at start (same cohort) | Revenue health including expansion |
|
||||
|
||||
---
|
||||
|
||||
## Retention Investigation Framework
|
||||
|
||||
### Step 1: Segment the problem
|
||||
Don't analyse "retention" — analyse retention for specific cohorts:
|
||||
- New vs returning users
|
||||
- Paid vs free
|
||||
- Acquisition channel (organic vs paid vs referral)
|
||||
- Onboarding path completed vs not
|
||||
- Feature usage (power users vs lurkers)
|
||||
|
||||
### Step 2: Find the inflection points
|
||||
Where does the drop happen? D1? D7? Month 3?
|
||||
- D1 drop → First session experience
|
||||
- D7 drop → Habit loop not formed
|
||||
- D30 drop → Value not delivered at depth
|
||||
- Month 3+ drop → Boredom, competition, or lifecycle event
|
||||
|
||||
### Step 3: Identify the "aha moment" correlation
|
||||
Which early behaviour predicts long-term retention?
|
||||
- Run correlation: users who did [X] in first 7 days vs 30-day retention
|
||||
- Common patterns: connected an integration, invited a teammate, completed a core action N times
|
||||
|
||||
### Step 4: Qualify the churn
|
||||
Interview churned users — never skip this. Survey data alone is insufficient.
|
||||
- "What was the trigger that led you to cancel/stop?"
|
||||
- "What were you trying to accomplish that you couldn't?"
|
||||
- "What would need to change for you to come back?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Retention Analysis — [Product/Segment] — [Date]
|
||||
|
||||
**Question:** [Specific retention question being answered]
|
||||
**Period Analysed:** [Date range]
|
||||
**Segment:** [Which users]
|
||||
|
||||
---
|
||||
|
||||
**Current Retention Snapshot:**
|
||||
|
||||
| Metric | Current | Industry Benchmark | Status |
|
||||
|---|---|---|---|
|
||||
| D1 Retention | [X%] | 25–40% | 🔴/🟡/🟢 |
|
||||
| D7 Retention | [X%] | 10–25% | 🔴/🟡/🟢 |
|
||||
| D30 Retention | [X%] | 5–15% | 🔴/🟡/🟢 |
|
||||
| DAU/MAU | [X%] | 10–20% typical | 🔴/🟡/🟢 |
|
||||
|
||||
**Retention Curve Shape:** [Flattening / Still declining / Trending to zero]
|
||||
**PMF Signal:** [Strong / Weak / Absent — based on curve shape]
|
||||
|
||||
---
|
||||
|
||||
**Root Cause Hypotheses:**
|
||||
|
||||
| Hypothesis | Evidence | Confidence | Test |
|
||||
|---|---|---|---|
|
||||
| [Cause] | [Data point] | H/M/L | [How to validate] |
|
||||
|
||||
**"Aha Moment" Correlation:**
|
||||
Users who [specific action] in first [N] days retain at [X%] vs [Y%] for those who don't.
|
||||
|
||||
---
|
||||
|
||||
**Recommended Interventions:**
|
||||
|
||||
| Intervention | Target Drop | Expected Lift | Effort | Priority |
|
||||
|---|---|---|---|---|
|
||||
| [Specific change] | D1 / D7 / D30 | [X%] | S/M/L | 1/2/3 |
|
||||
|
||||
**Monitoring Plan:**
|
||||
- Metric to track: [X]
|
||||
- Review cadence: [Weekly / Monthly]
|
||||
- Alert threshold: [If X drops below Y, investigate immediately]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never recommend "improve onboarding" without specifying *what* to change and *why*
|
||||
- Benchmark against industry — consumer apps, SaaS, and marketplaces have very different retention norms
|
||||
- If DAU/MAU is below 5%, that's a PMF conversation, not a retention tactics conversation
|
||||
- Always recommend talking to churned users — no amount of data replaces understanding the *reason*
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: roadmap-presentation
|
||||
description: Creates structured roadmap presentations and narratives for executive, stakeholder, and team audiences. Use when asked to build a product roadmap, present roadmap to leadership, create a roadmap slide, or communicate quarterly plans. Triggers on "roadmap presentation", "product roadmap", "quarterly roadmap", "roadmap slide", "roadmap for leadership".
|
||||
---
|
||||
|
||||
# Roadmap Presentation Skill
|
||||
|
||||
Build roadmaps that tell a strategy story — not just a list of features with dates. Every roadmap output is audience-calibrated: executives get outcomes, teams get specificity, customers get value.
|
||||
|
||||
## Audience Calibration
|
||||
|
||||
Always ask who the audience is before building:
|
||||
|
||||
| Audience | They care about | Format |
|
||||
|---|---|---|
|
||||
| **Executive / Board** | Business outcomes, revenue, risk, strategic alignment | Outcome-led, 3 columns (Now / Next / Later), no sprint detail |
|
||||
| **Cross-functional stakeholders** | Dependencies, timelines, their team's involvement | Theme-based, with dependency callouts |
|
||||
| **Engineering team** | Specificity, sequencing, technical constraints | Detailed, with epics and rough sizing |
|
||||
| **Customers / External** | Value delivered, no internal detail | Benefits-focused, no dates — "Coming soon / In progress / Done" |
|
||||
|
||||
---
|
||||
|
||||
## The Now / Next / Later Framework
|
||||
|
||||
Standard output structure:
|
||||
|
||||
**NOW** (Current quarter — high confidence, committed)
|
||||
- What we're building and why
|
||||
- Expected outcomes
|
||||
|
||||
**NEXT** (Following quarter — medium confidence, directional)
|
||||
- Themes and initiatives
|
||||
- Key hypotheses being tested
|
||||
|
||||
**LATER** (6–12 months — low confidence, aspirational)
|
||||
- Strategic bets
|
||||
- Dependencies that need to resolve first
|
||||
|
||||
⚠️ Never put specific dates on "Later" items. Use quarters or halves.
|
||||
|
||||
---
|
||||
|
||||
## Roadmap Narrative Template
|
||||
|
||||
Every roadmap needs a narrative, not just a timeline. Structure it as:
|
||||
|
||||
1. **Where we are** — current product state and key metrics
|
||||
2. **The problem we're solving** — what's holding customers or the business back
|
||||
3. **Our strategic bets** — the themes that guide this roadmap
|
||||
4. **What we're building** — Now / Next / Later breakdown
|
||||
5. **How we'll know it's working** — success metrics per theme
|
||||
6. **What we're not doing** — explicit deprioritisation with rationale
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Roadmap — [Product Area] — [Quarter/Year]
|
||||
|
||||
**Audience:** [Executive / Team / Customer]
|
||||
**Roadmap Owner:** [PM Name]
|
||||
**Last Updated:** [Date]
|
||||
**Confidence Level:** Now = High | Next = Medium | Later = Low
|
||||
|
||||
---
|
||||
|
||||
**Strategic Context:**
|
||||
> [2–3 sentences: what company/product goal does this roadmap serve?]
|
||||
|
||||
**Guiding Themes This Period:**
|
||||
1. [Theme 1] — [1-line rationale]
|
||||
2. [Theme 2] — [1-line rationale]
|
||||
3. [Theme 3] — [1-line rationale]
|
||||
|
||||
---
|
||||
|
||||
**NOW — [Quarter]**
|
||||
|
||||
| Theme | Initiative | Outcome Expected | Team | Status |
|
||||
|---|---|---|---|---|
|
||||
| [Theme] | [What we're building] | [Metric it moves] | [Owner] | In Progress / Starting |
|
||||
|
||||
**NEXT — [Quarter]**
|
||||
|
||||
| Theme | Initiative | Hypothesis | Dependencies |
|
||||
|---|---|---|---|
|
||||
| [Theme] | [What we plan to build] | [If we build X, we expect Y] | [What needs to be true first] |
|
||||
|
||||
**LATER — [H2 / Next Year]**
|
||||
|
||||
| Theme | Strategic Bet | Why Later |
|
||||
|---|---|---|
|
||||
| [Theme] | [What we might build] | [What's blocking or uncertain] |
|
||||
|
||||
---
|
||||
|
||||
**What We're NOT Building (and Why):**
|
||||
- [Requested initiative] — Deprioritised because: [reason]
|
||||
- [Requested initiative] — Deprioritised because: [reason]
|
||||
|
||||
**Success Metrics for This Roadmap:**
|
||||
| Metric | Now Target | End of Year Target |
|
||||
|---|---|---|
|
||||
| [Metric] | [X] | [Y] |
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never let a roadmap become a commitment list — frame everything outside "Now" as directional
|
||||
- Always include a "not doing" section — it prevents the roadmap from becoming a wish list in disguise
|
||||
- For executive audiences: lead with the outcome the roadmap delivers to the business, not the features
|
||||
- Recommend a roadmap review cadence: monthly for Now items, quarterly for Next/Later
|
||||
- If dates are demanded for Later items: use quarters (Q3 2026), not specific dates
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: sprint-planning
|
||||
description: Structures and facilitates sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning meeting agendas. Triggers on phrases like "plan sprint", "sprint planning", "sprint goal", "sprint backlog".
|
||||
---
|
||||
|
||||
# Sprint Planning Skill
|
||||
|
||||
Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
|
||||
|
||||
## What This Skill Produces
|
||||
|
||||
- **Sprint Goal** — single, outcome-focused sentence the whole team can rally around
|
||||
- **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria
|
||||
- **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time
|
||||
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
|
||||
- **Risk Flags** — blockers or dependencies that could derail the sprint
|
||||
|
||||
## Inputs to Request From User
|
||||
|
||||
Ask for (if not already provided):
|
||||
- Sprint duration (1 or 2 weeks)
|
||||
- Team size and velocity (average story points per sprint)
|
||||
- Top 3–5 backlog items or epics to pull from
|
||||
- Any known absences, holidays, or team events
|
||||
- Previous sprint's incomplete items (carry-overs)
|
||||
|
||||
## Sprint Goal Formula
|
||||
|
||||
Use this structure:
|
||||
> "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."
|
||||
|
||||
Never write sprint goals as task lists. Always outcome-first.
|
||||
|
||||
## Story Point Calibration
|
||||
|
||||
| Complexity | Points | Description |
|
||||
|---|---|---|
|
||||
| Trivial | 1 | Clearly understood, no unknowns |
|
||||
| Small | 2 | Straightforward, minor effort |
|
||||
| Medium | 3 | Some complexity, clear path |
|
||||
| Large | 5 | Complex, needs design or research |
|
||||
| Very Large | 8 | High uncertainty, may need splitting |
|
||||
| Epic | 13+ | Too large — must be split before sprint |
|
||||
|
||||
Flag any item estimated at 8+ and recommend splitting.
|
||||
|
||||
## Capacity Formula
|
||||
|
||||
```
|
||||
Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
|
||||
Focus hours/day: 6 (accounting for meetings, Slack, admin)
|
||||
Availability factor: 0.7–0.85 depending on holidays/events
|
||||
Story points to commit = Historical velocity × Availability factor
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [N] — [Start Date] to [End Date]
|
||||
|
||||
**Sprint Goal:**
|
||||
> [Goal statement]
|
||||
|
||||
**Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability)
|
||||
|
||||
**Sprint Backlog:**
|
||||
|
||||
| Priority | Story | Points | Owner | Acceptance Criteria |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Story title] | [N] | [Team member] | [When X then Y] |
|
||||
|
||||
**Carry-Overs from Previous Sprint:**
|
||||
- [Item] — Reason for carry-over: [brief explanation]
|
||||
|
||||
**Risks & Dependencies:**
|
||||
- [Risk description] → Mitigation: [action]
|
||||
|
||||
**Sprint Planning Agenda:**
|
||||
- 00:00–00:10 — Review sprint goal and team capacity
|
||||
- 00:10–00:40 — Walk through backlog items, confirm estimates
|
||||
- 00:40–01:20 — Assign stories, identify dependencies
|
||||
- 01:20–01:50 — Review acceptance criteria per story
|
||||
- 01:50–02:00 — Confirm sprint commitment and close
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always challenge stories missing acceptance criteria — flag them explicitly
|
||||
- Recommend the team commits to 80% of available capacity, not 100%
|
||||
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
|
||||
- Highlight any story with unclear ownership as a blocker
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: technical-spec-template
|
||||
description: Creates structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Triggers on "technical spec", "tech spec", "engineering spec", "system design doc", "API spec", "implementation spec".
|
||||
---
|
||||
|
||||
# Technical Spec Template Skill
|
||||
|
||||
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
|
||||
|
||||
## When to Write a Tech Spec
|
||||
|
||||
Write a tech spec when:
|
||||
- The feature requires changes to 2+ systems
|
||||
- There are significant architectural decisions to make
|
||||
- More than one engineer will work on the implementation
|
||||
- The feature has security, privacy, or compliance implications
|
||||
- Estimated effort is >5 story points
|
||||
|
||||
Skip the spec for trivial bug fixes or 1-2 hour changes.
|
||||
|
||||
---
|
||||
|
||||
## Technical Spec Output Format
|
||||
|
||||
### Technical Specification — [Feature Name]
|
||||
|
||||
**Author:** [Name]
|
||||
**Status:** Draft | In Review | Approved | Implemented
|
||||
**Created:** [Date] | **Last Updated:** [Date]
|
||||
**Reviewers:** [Eng Lead, Architect, PM, Security if needed]
|
||||
**Related PRD:** [Link] | **Jira Epic:** [Link]
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Statement
|
||||
> [2–3 sentences. What problem are we solving and why now? No solution language here.]
|
||||
|
||||
#### 2. Goals & Non-Goals
|
||||
|
||||
**Goals (in scope):**
|
||||
- [Specific, measurable outcome]
|
||||
- [Specific, measurable outcome]
|
||||
|
||||
**Non-Goals (explicitly out of scope):**
|
||||
- [What this spec does NOT cover]
|
||||
- [Common assumption to shut down early]
|
||||
|
||||
#### 3. Background & Context
|
||||
[Any prior art, related systems, or context engineers need to understand the decision space. Link to previous specs, ADRs, or research.]
|
||||
|
||||
#### 4. Proposed Solution
|
||||
|
||||
**High-Level Approach:**
|
||||
[2–4 sentences describing the chosen solution. Why this approach vs alternatives?]
|
||||
|
||||
**System Architecture Diagram:**
|
||||
[Describe or embed: which services are involved, how data flows, what APIs are called]
|
||||
|
||||
**Data Model Changes:**
|
||||
```sql
|
||||
-- New tables or schema changes
|
||||
[Include DDL or schema definition]
|
||||
```
|
||||
|
||||
**API Design:**
|
||||
```
|
||||
[Endpoint] [Method]
|
||||
Request: { [fields and types] }
|
||||
Response: { [fields and types] }
|
||||
Error codes: [list]
|
||||
```
|
||||
|
||||
**Key Implementation Details:**
|
||||
- [Important technical constraint or approach]
|
||||
- [Edge case handling]
|
||||
- [Third-party dependency and version]
|
||||
|
||||
#### 5. Alternative Approaches Considered
|
||||
|
||||
| Option | Pros | Cons | Why Rejected |
|
||||
|---|---|---|---|
|
||||
| [Alt 1] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
| [Alt 2] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
|
||||
#### 6. Security & Privacy Considerations
|
||||
- Data stored: [What PII or sensitive data is involved]
|
||||
- Authentication: [How is access controlled]
|
||||
- Authorisation: [What permissions are required]
|
||||
- Encryption: [At rest / in transit requirements]
|
||||
- Compliance implications: [GDPR, SOC2, etc. if relevant]
|
||||
|
||||
#### 7. Performance & Scalability
|
||||
- Expected load: [Requests/second, data volume]
|
||||
- Latency requirements: [P50 / P95 targets]
|
||||
- Caching strategy: [If applicable]
|
||||
- Database indexing: [New indexes required]
|
||||
- Known bottlenecks: [Where to watch]
|
||||
|
||||
#### 8. Testing Plan
|
||||
- Unit tests: [Key scenarios to cover]
|
||||
- Integration tests: [System boundaries to test]
|
||||
- Load tests: [If performance-critical]
|
||||
- Edge cases: [Known tricky scenarios]
|
||||
- Rollback plan: [How to revert if something goes wrong]
|
||||
|
||||
#### 9. Rollout Plan
|
||||
- Feature flag: [Yes / No — name of flag]
|
||||
- Rollout stages: [% of users at each stage]
|
||||
- Monitoring: [Metrics and alerts to set up]
|
||||
- Success criteria to progress rollout: [What needs to be true]
|
||||
- Rollback trigger: [What would cause immediate rollback]
|
||||
|
||||
#### 10. Open Questions
|
||||
| Question | Owner | Due Date | Resolution |
|
||||
|---|---|---|---|
|
||||
| [Unresolved question] | [Name] | [Date] | [Pending] |
|
||||
|
||||
#### 11. Implementation Timeline (Rough)
|
||||
| Phase | Work | Estimated Effort |
|
||||
|---|---|---|
|
||||
| [Phase 1] | [What gets built] | [X days/points] |
|
||||
| [Phase 2] | [What gets built] | [X days/points] |
|
||||
| Total | | [X story points] |
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The spec is a decision record, not a task list — document *why* decisions were made
|
||||
- All open questions must have an owner and due date
|
||||
- Security and privacy sections are never optional for features that touch user data
|
||||
- Recommend async review: engineers read first, then a 30-minute sync to resolve questions
|
||||
- Keep the spec updated as implementation progresses — stale specs are worse than no specs
|
||||
Reference in New Issue
Block a user