Add files via upload
This commit is contained in:
mohitagw15856
GitHub
+197
@@ -0,0 +1,197 @@
|
|||||||
|
# Contributing to PM Claude Skills
|
||||||
|
|
||||||
|
Thank you for considering contributing to PM Claude Skills! This document provides guidelines for contributing.
|
||||||
|
|
||||||
|
## Ways to Contribute
|
||||||
|
|
||||||
|
### 1. Report Bugs 🐛
|
||||||
|
|
||||||
|
If you find a bug in a Skill:
|
||||||
|
|
||||||
|
1. Check if the issue already exists in [Issues](https://github.com/yourusername/pm-claude-skills/issues)
|
||||||
|
2. If not, create a new issue using the Bug Report template
|
||||||
|
3. Include:
|
||||||
|
- Which Skill has the issue
|
||||||
|
- What you expected to happen
|
||||||
|
- What actually happened
|
||||||
|
- Steps to reproduce
|
||||||
|
- Your Claude version (Pro/Team/Enterprise)
|
||||||
|
|
||||||
|
### 2. Request Skills 💡
|
||||||
|
|
||||||
|
Have an idea for a new Skill?
|
||||||
|
|
||||||
|
1. Check [existing issues](https://github.com/yourusername/pm-claude-skills/issues?q=is%3Aissue+label%3Aenhancement) to avoid duplicates
|
||||||
|
2. Create a new issue using the Skill Request template
|
||||||
|
3. Describe:
|
||||||
|
- What PM task the Skill would help with
|
||||||
|
- How you currently do this task
|
||||||
|
- Time you spend on it
|
||||||
|
- Example outputs
|
||||||
|
|
||||||
|
### 3. Improve Documentation 📚
|
||||||
|
|
||||||
|
Documentation improvements are always welcome:
|
||||||
|
|
||||||
|
- Fix typos or unclear instructions
|
||||||
|
- Add examples
|
||||||
|
- Improve installation guides
|
||||||
|
- Share your use cases
|
||||||
|
|
||||||
|
### 4. Submit Skills 🎁
|
||||||
|
|
||||||
|
Want to contribute a Skill you've created?
|
||||||
|
|
||||||
|
**Requirements:**
|
||||||
|
- Skill must be PM-related
|
||||||
|
- Include complete SKILL.md with proper frontmatter
|
||||||
|
- Provide examples of outputs
|
||||||
|
- Must be tested and working
|
||||||
|
- Include documentation
|
||||||
|
|
||||||
|
**Process:**
|
||||||
|
1. Fork the repository
|
||||||
|
2. Create a new branch: `git checkout -b skill/your-skill-name`
|
||||||
|
3. Add your Skill to `skills/your-skill-name/`
|
||||||
|
4. Update main README.md to list your Skill
|
||||||
|
5. Submit a Pull Request
|
||||||
|
|
||||||
|
### 5. Improve Existing Skills 🔧
|
||||||
|
|
||||||
|
Found a way to make a Skill better?
|
||||||
|
|
||||||
|
1. Fork the repository
|
||||||
|
2. Make your improvements
|
||||||
|
3. Test thoroughly
|
||||||
|
4. Submit a Pull Request with:
|
||||||
|
- Clear description of changes
|
||||||
|
- Why the change improves the Skill
|
||||||
|
- Before/after examples if applicable
|
||||||
|
|
||||||
|
## Skill Contribution Guidelines
|
||||||
|
|
||||||
|
### Structure
|
||||||
|
|
||||||
|
Every Skill must follow this structure:
|
||||||
|
|
||||||
|
```
|
||||||
|
skill-name/
|
||||||
|
├── SKILL.md (required)
|
||||||
|
└── [other resources as needed]
|
||||||
|
```
|
||||||
|
|
||||||
|
### SKILL.md Format
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
name: skill-name
|
||||||
|
description: Clear description of what the skill does and when to use it. This is critical - Claude uses this to decide when to trigger the skill.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Skill Name
|
||||||
|
|
||||||
|
[Detailed instructions for using the skill]
|
||||||
|
|
||||||
|
## Structure/Template
|
||||||
|
|
||||||
|
[The format/structure the skill should follow]
|
||||||
|
|
||||||
|
## Guidelines
|
||||||
|
|
||||||
|
[Best practices and tips]
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
[Example outputs]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quality Standards
|
||||||
|
|
||||||
|
Skills should:
|
||||||
|
- ✅ Be well-documented and clear
|
||||||
|
- ✅ Include concrete examples
|
||||||
|
- ✅ Follow PM best practices
|
||||||
|
- ✅ Save meaningful time (not trivial tasks)
|
||||||
|
- ✅ Be tested and working
|
||||||
|
- ✅ Be general enough for others to use
|
||||||
|
- ❌ Not include proprietary company information
|
||||||
|
- ❌ Not require external tools (unless clearly documented)
|
||||||
|
|
||||||
|
## Pull Request Process
|
||||||
|
|
||||||
|
1. **Fork & Branch**
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/yourusername/pm-claude-skills.git
|
||||||
|
cd pm-claude-skills
|
||||||
|
git checkout -b feature/your-feature-name
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Make Changes**
|
||||||
|
- Follow existing code style
|
||||||
|
- Update documentation
|
||||||
|
- Add examples
|
||||||
|
|
||||||
|
3. **Test**
|
||||||
|
- Test the Skill in Claude
|
||||||
|
- Verify it works as expected
|
||||||
|
- Check for edge cases
|
||||||
|
|
||||||
|
4. **Commit**
|
||||||
|
```bash
|
||||||
|
git add .
|
||||||
|
git commit -m "Add: Brief description of changes"
|
||||||
|
```
|
||||||
|
|
||||||
|
5. **Push & Create PR**
|
||||||
|
```bash
|
||||||
|
git push origin feature/your-feature-name
|
||||||
|
```
|
||||||
|
Then create a Pull Request on GitHub
|
||||||
|
|
||||||
|
6. **PR Description Should Include:**
|
||||||
|
- What changes you made
|
||||||
|
- Why you made them
|
||||||
|
- How to test them
|
||||||
|
- Screenshots/examples (if applicable)
|
||||||
|
|
||||||
|
## Code of Conduct
|
||||||
|
|
||||||
|
### Our Standards
|
||||||
|
|
||||||
|
- Be respectful and inclusive
|
||||||
|
- Welcome newcomers
|
||||||
|
- Accept constructive criticism
|
||||||
|
- Focus on what's best for the community
|
||||||
|
- Show empathy towards others
|
||||||
|
|
||||||
|
### Unacceptable Behavior
|
||||||
|
|
||||||
|
- Harassment or discriminatory language
|
||||||
|
- Trolling or insulting comments
|
||||||
|
- Personal or political attacks
|
||||||
|
- Publishing private information
|
||||||
|
- Unprofessional conduct
|
||||||
|
|
||||||
|
### Enforcement
|
||||||
|
|
||||||
|
Violations may result in:
|
||||||
|
1. Warning
|
||||||
|
2. Temporary ban
|
||||||
|
3. Permanent ban
|
||||||
|
|
||||||
|
Report violations to: [your-email@example.com]
|
||||||
|
|
||||||
|
## Questions?
|
||||||
|
|
||||||
|
- 💬 Start a [Discussion](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
- ✉️ Email: [your-email@example.com]
|
||||||
|
- 🐦 Twitter: [@yourhandle]
|
||||||
|
|
||||||
|
## Recognition
|
||||||
|
|
||||||
|
Contributors will be:
|
||||||
|
- Listed in the project README
|
||||||
|
- Credited in the Skill they contributed
|
||||||
|
- Mentioned in release notes
|
||||||
|
|
||||||
|
Thank you for contributing! 🙏
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2026 Mohit Aggarwal
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
+101
@@ -0,0 +1,101 @@
|
|||||||
|
# Quick Start Guide
|
||||||
|
|
||||||
|
Get your first PM Skill working in 5 minutes.
|
||||||
|
|
||||||
|
## Before You Begin
|
||||||
|
|
||||||
|
✅ **Requirements**:
|
||||||
|
- Claude Pro, Team, or Enterprise account ([Upgrade](https://claude.ai/upgrade))
|
||||||
|
- 5 minutes of time
|
||||||
|
|
||||||
|
## Step 1: Enable Code Execution (1 minute)
|
||||||
|
|
||||||
|
1. Go to [claude.ai](https://claude.ai)
|
||||||
|
2. Click profile icon (bottom-left) → **Settings**
|
||||||
|
3. Click **Features**
|
||||||
|
4. Toggle ON **"Code Execution and File Creation"**
|
||||||
|
5. Click **Save**
|
||||||
|
|
||||||
|
## Step 2: Download a Skill (1 minute)
|
||||||
|
|
||||||
|
**Option A: Use Pre-Packaged (Easiest)**
|
||||||
|
1. Go to [Releases](https://github.com/yourusername/pm-claude-skills/releases)
|
||||||
|
2. Download `prd-template.skill`
|
||||||
|
3. Skip to Step 3
|
||||||
|
|
||||||
|
**Option B: Package Yourself**
|
||||||
|
1. Download [`skills/prd-template`](skills/prd-template) folder
|
||||||
|
2. Zip the contents (not the folder itself)
|
||||||
|
3. Rename from `.zip` to `.skill`
|
||||||
|
|
||||||
|
## Step 3: Upload to Claude (1 minute)
|
||||||
|
|
||||||
|
1. In claude.ai, click profile icon → **Settings**
|
||||||
|
2. Click **Skills** in sidebar
|
||||||
|
3. Click **Upload Skill**
|
||||||
|
4. Select your `.skill` file
|
||||||
|
5. Wait for "Skill uploaded successfully"
|
||||||
|
|
||||||
|
## Step 4: Test It (2 minutes)
|
||||||
|
|
||||||
|
Start a new conversation and try:
|
||||||
|
|
||||||
|
```
|
||||||
|
Help me write a PRD for a mobile app feature
|
||||||
|
that lets users save articles for later reading
|
||||||
|
```
|
||||||
|
|
||||||
|
Claude should automatically use the PRD Template Skill and create a structured PRD.
|
||||||
|
|
||||||
|
## What to Try Next
|
||||||
|
|
||||||
|
### Test Other Skills:
|
||||||
|
- **Meeting Notes**: "Create meeting notes from this discussion: [paste]"
|
||||||
|
- **Stakeholder Update**: "Create a weekly stakeholder update"
|
||||||
|
- **User Research**: "Synthesize these user interviews: [paste]"
|
||||||
|
|
||||||
|
### Customize a Skill:
|
||||||
|
1. Download the Skill folder
|
||||||
|
2. Edit `SKILL.md` to match your company's format
|
||||||
|
3. Re-package and upload
|
||||||
|
4. See [Customization Guide](docs/customization.md)
|
||||||
|
|
||||||
|
### Create Your Own:
|
||||||
|
- See [Creating Skills Guide](docs/creating-skills.md)
|
||||||
|
- Start with a simple template
|
||||||
|
- Test and iterate
|
||||||
|
|
||||||
|
## Common Issues
|
||||||
|
|
||||||
|
**"Code Execution must be enabled"**
|
||||||
|
→ Go to Settings → Features → Enable it
|
||||||
|
|
||||||
|
**Skill doesn't trigger**
|
||||||
|
→ Be more explicit: "Write a PRD for..."
|
||||||
|
|
||||||
|
**Upload fails**
|
||||||
|
→ Check file is `.skill` not `.zip`
|
||||||
|
|
||||||
|
**Still stuck?**
|
||||||
|
→ See [Troubleshooting Guide](docs/troubleshooting.md)
|
||||||
|
|
||||||
|
## Full Documentation
|
||||||
|
|
||||||
|
- [Installation Guide](docs/installation.md) - Detailed setup
|
||||||
|
- [Customization Guide](docs/customization.md) - Adapt to your workflow
|
||||||
|
- [Troubleshooting](docs/troubleshooting.md) - Fix common issues
|
||||||
|
|
||||||
|
## Need Help?
|
||||||
|
|
||||||
|
- 💬 [Discussions](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
- 🐛 [Report Bug](https://github.com/yourusername/pm-claude-skills/issues)
|
||||||
|
- 📧 Email: your-email@example.com
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Time Invested**: 5 minutes
|
||||||
|
**Time You'll Save**: 8-9 hours per week
|
||||||
|
|
||||||
|
Start with one Skill. See the results. Then add more.
|
||||||
|
|
||||||
|
⭐ [Star this repo](https://github.com/yourusername/pm-claude-skills) to get updates!
|
||||||
@@ -0,0 +1,207 @@
|
|||||||
|
# Product Management Claude Skills
|
||||||
|
|
||||||
|
**Transform your PM workflow with specialized Claude Skills for common product management tasks.**
|
||||||
|
|
||||||
|
[](https://opensource.org/licenses/MIT)
|
||||||
|
[](https://github.com/yourusername/pm-claude-skills/stargazers)
|
||||||
|
|
||||||
|
> 📖 **Background**: These Skills emerged from my widely-read Medium article ["Claude Skills: The AI Feature That's Quietly Changing How Product Managers Work"](your-medium-article-link), where I documented how Skills transformed my daily PM workflow, saving 3-4 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.
|
||||||
|
|
||||||
|
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
|
||||||
|
- **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`)
|
||||||
|
- Go to claude.ai → Settings → Skills → Upload Skill
|
||||||
|
- Try it: "Help me write a PRD for a mobile app onboarding feature"
|
||||||
|
|
||||||
|
That's it! Claude now knows your PRD format.
|
||||||
|
|
||||||
|
## 📦 Available Skills
|
||||||
|
|
||||||
|
### Free Essential Skills (Included)
|
||||||
|
|
||||||
|
| 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) |
|
||||||
|
|
||||||
|
### Coming Soon 🔜
|
||||||
|
|
||||||
|
- Data Analysis Standard
|
||||||
|
- Roadmap Presentation
|
||||||
|
- Quarterly Planning
|
||||||
|
- Product Launch Checklist
|
||||||
|
- Technical Specification Template
|
||||||
|
|
||||||
|
Want a specific Skill? [Request it here](https://github.com/yourusername/pm-claude-skills/issues/new?template=skill-request.md)
|
||||||
|
|
||||||
|
## 💡 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."
|
||||||
|
> — **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**
|
||||||
|
|
||||||
|
## 📚 Documentation
|
||||||
|
|
||||||
|
- [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`)
|
||||||
|
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
|
||||||
|
|
||||||
|
### Method 2: Clone the Repo
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Clone the repository
|
||||||
|
git clone https://github.com/yourusername/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
|
||||||
|
```
|
||||||
|
|
||||||
|
### Method 3: Direct Download (When Available)
|
||||||
|
|
||||||
|
Check the [Releases](https://github.com/yourusername/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
|
||||||
|
|
||||||
|
## 🔧 Customization
|
||||||
|
|
||||||
|
Every company has different formats and processes. These Skills are designed to be customized:
|
||||||
|
|
||||||
|
1. Download the Skill folder
|
||||||
|
2. Edit the `SKILL.md` file to match your standards
|
||||||
|
3. Add your company's examples to the instructions
|
||||||
|
4. Re-package and upload
|
||||||
|
|
||||||
|
See the [Customization Guide](docs/customization.md) for detailed instructions.
|
||||||
|
|
||||||
|
## 🤝 Contributing
|
||||||
|
|
||||||
|
Found a bug? Want to suggest an improvement? Contributions are welcome!
|
||||||
|
|
||||||
|
- 🐛 [Report an Issue](https://github.com/yourusername/pm-claude-skills/issues/new?template=bug-report.md)
|
||||||
|
- 💡 [Request a Skill](https://github.com/yourusername/pm-claude-skills/issues/new?template=skill-request.md)
|
||||||
|
- 🔀 [Submit a Pull Request](https://github.com/yourusername/pm-claude-skills/pulls)
|
||||||
|
- 💬 [Join Discussions](https://github.com/yourusername/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
|
||||||
|
|
||||||
|
**Q2 2026:**
|
||||||
|
- [ ] Domain-specific Skills (SaaS PM, B2B PM, Growth PM)
|
||||||
|
- [ ] Team collaboration Skills
|
||||||
|
- [ ] Notion/Confluence template packs
|
||||||
|
|
||||||
|
**Long-term:**
|
||||||
|
- [ ] Interactive Skill builder tool
|
||||||
|
- [ ] Integration examples with PM tools
|
||||||
|
- [ ] Community-contributed Skills library
|
||||||
|
|
||||||
|
## 📄 License
|
||||||
|
|
||||||
|
This project is licensed under the MIT License - see [LICENSE](LICENSE) for details.
|
||||||
|
|
||||||
|
You're free to use, modify, and distribute these Skills. Attribution appreciated but not required.
|
||||||
|
|
||||||
|
## 🙋 FAQ
|
||||||
|
|
||||||
|
**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: Do Skills work with the Claude API?**
|
||||||
|
A: Yes! Skills work in claude.ai, Claude Code, and via the API.
|
||||||
|
|
||||||
|
**Q: What if a Skill doesn't work?**
|
||||||
|
A: Check [Troubleshooting](docs/troubleshooting.md) or [open an issue](https://github.com/yourusername/pm-claude-skills/issues).
|
||||||
|
|
||||||
|
**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 license allows commercial use.
|
||||||
|
|
||||||
|
## 🔗 Links
|
||||||
|
|
||||||
|
- 📝 [Original Medium Article](your-medium-article-link)
|
||||||
|
- 🐦 [Follow me on Twitter](your-twitter-link)
|
||||||
|
- 💼 [Connect on LinkedIn](your-linkedin-link)
|
||||||
|
- ✉️ [Email me](mailto:your-email@example.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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Made with ☕ by [Mohit Aggarwal](your-website-link)**
|
||||||
|
|
||||||
|
*Helping product managers work smarter with AI*
|
||||||
|
|
||||||
|
⭐ **Star this repo to get updates as new Skills are added!**
|
||||||
@@ -0,0 +1,405 @@
|
|||||||
|
# Customization Guide
|
||||||
|
|
||||||
|
Learn how to adapt PM Claude Skills to match your company's specific processes and standards.
|
||||||
|
|
||||||
|
## Why Customize?
|
||||||
|
|
||||||
|
Every company has different:
|
||||||
|
- Document formats and templates
|
||||||
|
- Communication styles
|
||||||
|
- Approval processes
|
||||||
|
- Tools and systems
|
||||||
|
- Terminology and jargon
|
||||||
|
|
||||||
|
These Skills are designed as starting points. Customizing them ensures Claude produces outputs that match YOUR standards, not generic ones.
|
||||||
|
|
||||||
|
## What Can Be Customized
|
||||||
|
|
||||||
|
### 1. Document Structure
|
||||||
|
- Section order and naming
|
||||||
|
- Required vs. optional sections
|
||||||
|
- Level of detail
|
||||||
|
|
||||||
|
### 2. Formatting & Style
|
||||||
|
- Tone (formal vs. casual)
|
||||||
|
- Length preferences
|
||||||
|
- Visual elements (tables, bullets, etc.)
|
||||||
|
|
||||||
|
### 3. Process & Workflow
|
||||||
|
- Approval steps
|
||||||
|
- Stakeholder requirements
|
||||||
|
- Tool integrations
|
||||||
|
|
||||||
|
### 4. Terminology
|
||||||
|
- Company-specific terms
|
||||||
|
- Product names
|
||||||
|
- Team names and roles
|
||||||
|
|
||||||
|
### 5. Examples
|
||||||
|
- Your actual past documents (anonymized)
|
||||||
|
- Company-specific scenarios
|
||||||
|
- Real data formats
|
||||||
|
|
||||||
|
## How to Customize a Skill
|
||||||
|
|
||||||
|
### Step 1: Download the Skill
|
||||||
|
|
||||||
|
1. Navigate to the skill folder (e.g., `skills/prd-template`)
|
||||||
|
2. Download the `SKILL.md` file
|
||||||
|
3. Open in any text editor
|
||||||
|
|
||||||
|
### Step 2: Understand the Structure
|
||||||
|
|
||||||
|
Every `SKILL.md` has two parts:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
name: skill-name
|
||||||
|
description: When Claude should use this skill
|
||||||
|
---
|
||||||
|
|
||||||
|
# Skill Content
|
||||||
|
|
||||||
|
[Instructions for Claude]
|
||||||
|
```
|
||||||
|
|
||||||
|
**Frontmatter** (between `---`):
|
||||||
|
- `name`: The skill identifier (keep unchanged)
|
||||||
|
- `description`: When to trigger this skill (customize if needed)
|
||||||
|
|
||||||
|
**Body** (after `---`):
|
||||||
|
- Instructions Claude follows
|
||||||
|
- Templates and formats
|
||||||
|
- Examples
|
||||||
|
|
||||||
|
### Step 3: Make Your Changes
|
||||||
|
|
||||||
|
Edit the body to match your needs. Here are common customizations:
|
||||||
|
|
||||||
|
## Common Customizations
|
||||||
|
|
||||||
|
### Example 1: Customize PRD Template
|
||||||
|
|
||||||
|
**Change the section structure:**
|
||||||
|
|
||||||
|
Original:
|
||||||
|
```markdown
|
||||||
|
### 1. Overview
|
||||||
|
- Problem Statement
|
||||||
|
- Proposed Solution
|
||||||
|
- Success Metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
Your Company's Format:
|
||||||
|
```markdown
|
||||||
|
### 1. Executive Summary
|
||||||
|
- Business Objective
|
||||||
|
- Customer Problem
|
||||||
|
- Proposed Solution
|
||||||
|
- Success Criteria (OKRs)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Add company-specific requirements:**
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### Company-Specific Requirements
|
||||||
|
|
||||||
|
**Compliance:**
|
||||||
|
- GDPR compliance assessment
|
||||||
|
- Security review sign-off
|
||||||
|
- Legal approval required
|
||||||
|
|
||||||
|
**Stakeholders to Consult:**
|
||||||
|
- Engineering Lead (architecture)
|
||||||
|
- Design Director (UX)
|
||||||
|
- Security Team (if handling PII)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Add your actual template:**
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Your Company PRD Template
|
||||||
|
|
||||||
|
Use this exact structure:
|
||||||
|
|
||||||
|
# [Feature Name] - Product Requirements
|
||||||
|
|
||||||
|
## 1. Executive Summary (Max 1 page)
|
||||||
|
[Your specific requirements]
|
||||||
|
|
||||||
|
## 2. Customer Research
|
||||||
|
[Your specific requirements]
|
||||||
|
|
||||||
|
[Continue with your actual template]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 2: Customize Stakeholder Updates
|
||||||
|
|
||||||
|
**Match your metrics:**
|
||||||
|
|
||||||
|
Original:
|
||||||
|
```markdown
|
||||||
|
| Metric | Current | Target | Trend | Status |
|
||||||
|
```
|
||||||
|
|
||||||
|
Your Company:
|
||||||
|
```markdown
|
||||||
|
| OKR | Progress | Goal | Confidence | Owner |
|
||||||
|
```
|
||||||
|
|
||||||
|
**Add your status indicators:**
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
**Status Levels:**
|
||||||
|
- 🟢 On Track: >90% confidence in hitting goals
|
||||||
|
- 🟡 At Risk: 60-90% confidence, mitigation needed
|
||||||
|
- 🔴 Off Track: <60% confidence, escalation required
|
||||||
|
- ⚪ Not Started: Work hasn't begun
|
||||||
|
```
|
||||||
|
|
||||||
|
**Match your communication style:**
|
||||||
|
|
||||||
|
If your executives prefer different tone:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Communication Style
|
||||||
|
|
||||||
|
**Tone**: Data-driven and factual (no marketing language)
|
||||||
|
**Length**: Maximum 5 bullets per section
|
||||||
|
**Focus**: Always lead with customer impact, then business metrics
|
||||||
|
**Avoid**: Jargon, acronyms without explanation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 3: Customize Meeting Notes
|
||||||
|
|
||||||
|
**Add your tools:**
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### Action Item Format
|
||||||
|
|
||||||
|
Use our Jira/Asana/Monday format:
|
||||||
|
|
||||||
|
- [ ] **[JIRA-123] [Action item]** - @Owner - Due: [Date] - Priority: [High/Med/Low]
|
||||||
|
```
|
||||||
|
|
||||||
|
**Add your meeting types:**
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### Sprint Retrospective Notes
|
||||||
|
|
||||||
|
**What Went Well:**
|
||||||
|
- [List items]
|
||||||
|
|
||||||
|
**What Didn't Go Well:**
|
||||||
|
- [List items]
|
||||||
|
|
||||||
|
**Action Items:**
|
||||||
|
- [Improvements to implement]
|
||||||
|
|
||||||
|
**Team Morale:** [Score 1-10]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 4: Add Domain-Specific Context
|
||||||
|
|
||||||
|
For SaaS PM:
|
||||||
|
```markdown
|
||||||
|
## SaaS Metrics Context
|
||||||
|
|
||||||
|
When analyzing metrics, always include:
|
||||||
|
- MRR/ARR impact
|
||||||
|
- Churn rate implications
|
||||||
|
- CAC payback impact
|
||||||
|
- NRR (Net Revenue Retention) effect
|
||||||
|
```
|
||||||
|
|
||||||
|
For B2B PM:
|
||||||
|
```markdown
|
||||||
|
## Enterprise Sales Context
|
||||||
|
|
||||||
|
When writing features, consider:
|
||||||
|
- Enterprise security requirements
|
||||||
|
- Compliance needs (SOC2, GDPR, HIPAA)
|
||||||
|
- Multi-tenant implications
|
||||||
|
- Admin controls needed
|
||||||
|
```
|
||||||
|
|
||||||
|
## Advanced Customization
|
||||||
|
|
||||||
|
### Adding Examples from Your Company
|
||||||
|
|
||||||
|
The most powerful customization: add YOUR actual examples.
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Example PRD from Our Company
|
||||||
|
|
||||||
|
Here's how we documented our last major feature:
|
||||||
|
|
||||||
|
[Paste anonymized version of your actual PRD]
|
||||||
|
|
||||||
|
Key elements to notice:
|
||||||
|
- How we structured the problem statement
|
||||||
|
- Level of technical detail
|
||||||
|
- How we documented success metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
### Adding Your Tools & Systems
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Our Tech Stack References
|
||||||
|
|
||||||
|
When mentioning systems, use our actual names:
|
||||||
|
- Internal tool for analytics: "DataHub"
|
||||||
|
- Our design system: "Atlas"
|
||||||
|
- Our API gateway: "Gateway Pro"
|
||||||
|
|
||||||
|
Always link to relevant docs:
|
||||||
|
- PRD templates: [internal wiki link]
|
||||||
|
- User research database: [internal link]
|
||||||
|
- Product metrics dashboard: [internal link]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Adding Your Processes
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Our Approval Process
|
||||||
|
|
||||||
|
Every PRD must be reviewed by:
|
||||||
|
1. Engineering Lead (technical feasibility)
|
||||||
|
2. Design Lead (UX implications)
|
||||||
|
3. Product Director (strategic alignment)
|
||||||
|
4. Security (if handling sensitive data)
|
||||||
|
|
||||||
|
Include sign-off section:
|
||||||
|
|
||||||
|
### Approvals
|
||||||
|
- [ ] Engineering: [Name] - [Date]
|
||||||
|
- [ ] Design: [Name] - [Date]
|
||||||
|
- [ ] Product: [Name] - [Date]
|
||||||
|
- [ ] Security: [Name] - [Date] (if applicable)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Testing Your Customizations
|
||||||
|
|
||||||
|
After customizing:
|
||||||
|
|
||||||
|
1. **Package the updated Skill** (see [Installation Guide](installation.md))
|
||||||
|
2. **Remove the old version** from Claude
|
||||||
|
3. **Upload the new version**
|
||||||
|
4. **Test with real examples**
|
||||||
|
|
||||||
|
Test prompts:
|
||||||
|
- Use actual requests you'd make
|
||||||
|
- Try edge cases
|
||||||
|
- Verify outputs match your expectations
|
||||||
|
|
||||||
|
## Iteration Process
|
||||||
|
|
||||||
|
Skills improve through iteration:
|
||||||
|
|
||||||
|
1. **Use the Skill** in real work
|
||||||
|
2. **Notice issues** or improvements
|
||||||
|
3. **Update SKILL.md**
|
||||||
|
4. **Re-upload**
|
||||||
|
5. **Test again**
|
||||||
|
|
||||||
|
Keep a "changelog" in your Skill:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Changelog
|
||||||
|
|
||||||
|
### v1.2 (Jan 25, 2026)
|
||||||
|
- Added security review requirement
|
||||||
|
- Changed metric names to match company OKRs
|
||||||
|
- Added example from Q4 2025 project
|
||||||
|
|
||||||
|
### v1.1 (Jan 15, 2026)
|
||||||
|
- Updated to match new PRD template
|
||||||
|
- Added stakeholder approval section
|
||||||
|
|
||||||
|
### v1.0 (Jan 1, 2026)
|
||||||
|
- Initial version
|
||||||
|
```
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
|
||||||
|
### ✅ Do:
|
||||||
|
- Start with small changes
|
||||||
|
- Test thoroughly before sharing with team
|
||||||
|
- Use real examples from your company
|
||||||
|
- Document what you changed and why
|
||||||
|
- Version your Skills
|
||||||
|
|
||||||
|
### ❌ Don't:
|
||||||
|
- Make the Skill too prescriptive (keep some flexibility)
|
||||||
|
- Include sensitive/proprietary information
|
||||||
|
- Assume one format works for all scenarios
|
||||||
|
- Over-customize before testing the default
|
||||||
|
|
||||||
|
## Sharing Customized Skills
|
||||||
|
|
||||||
|
### Within Your Team
|
||||||
|
|
||||||
|
For Team/Enterprise plans:
|
||||||
|
1. Customize and test individually
|
||||||
|
2. Share with 2-3 teammates for feedback
|
||||||
|
3. Iterate based on feedback
|
||||||
|
4. Have admin upload to organization library
|
||||||
|
5. Document any team-specific conventions
|
||||||
|
|
||||||
|
### Contributing Back
|
||||||
|
|
||||||
|
If your customization would help others:
|
||||||
|
1. Remove company-specific details
|
||||||
|
2. Generalize the improvements
|
||||||
|
3. Submit a Pull Request
|
||||||
|
4. Include explanation of why the change helps
|
||||||
|
|
||||||
|
## Templates for Common Customizations
|
||||||
|
|
||||||
|
### Add Company Values
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Our Company Values
|
||||||
|
|
||||||
|
When writing any document, reflect these values:
|
||||||
|
- **Customer-First**: Always lead with customer impact
|
||||||
|
- **Data-Driven**: Include quantitative backing
|
||||||
|
- **Bias for Action**: Propose concrete next steps
|
||||||
|
- **Transparent**: Be honest about risks and unknowns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Add Regulatory Requirements
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Regulatory Considerations
|
||||||
|
|
||||||
|
For any feature involving [X], include:
|
||||||
|
- GDPR compliance assessment
|
||||||
|
- Data retention policy
|
||||||
|
- User consent requirements
|
||||||
|
- Right to deletion implementation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Add Workflow Integrations
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Integration with Our Tools
|
||||||
|
|
||||||
|
When creating action items:
|
||||||
|
- Format for Jira: [TEAM-###] Action
|
||||||
|
- Tag relevant Slack channels: #product, #engineering
|
||||||
|
- Link to relevant Notion pages
|
||||||
|
- Add to project board: [Board link]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Need Help?
|
||||||
|
|
||||||
|
- 💬 [Ask in Discussions](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
- 📧 Email: your-email@example.com
|
||||||
|
- 🐛 [Report issues](https://github.com/yourusername/pm-claude-skills/issues)
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
- [Create Your Own Skills](creating-skills.md)
|
||||||
|
- [Troubleshooting Guide](troubleshooting.md)
|
||||||
|
- [Back to Installation](installation.md)
|
||||||
@@ -0,0 +1,192 @@
|
|||||||
|
# Installation Guide
|
||||||
|
|
||||||
|
Complete guide to installing and using PM Claude Skills.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
### Required
|
||||||
|
- **Claude Account**: Pro, Team, or Enterprise plan
|
||||||
|
- **Code Execution**: Must be enabled (see below)
|
||||||
|
- **Access**: claude.ai, Claude Code, or API access
|
||||||
|
|
||||||
|
### Check Your Account Type
|
||||||
|
1. Go to [claude.ai](https://claude.ai)
|
||||||
|
2. Click your profile in bottom-left
|
||||||
|
3. See "Claude Pro" / "Claude Team" / "Claude Enterprise"
|
||||||
|
|
||||||
|
If you have Free plan: Skills are not available. [Upgrade here](https://claude.ai/upgrade)
|
||||||
|
|
||||||
|
## Step 1: Enable Code Execution
|
||||||
|
|
||||||
|
Skills require Code Execution to be enabled.
|
||||||
|
|
||||||
|
1. Go to claude.ai
|
||||||
|
2. Click profile icon (bottom-left)
|
||||||
|
3. Click **Settings**
|
||||||
|
4. Click **Features**
|
||||||
|
5. Toggle on **"Code Execution and File Creation"**
|
||||||
|
6. Click **Save**
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Step 2: Download Skills
|
||||||
|
|
||||||
|
### Option A: Download Individual Skills (Recommended)
|
||||||
|
|
||||||
|
1. Navigate to the skill you want (e.g., [`skills/prd-template`](../skills/prd-template))
|
||||||
|
2. Click the skill folder
|
||||||
|
3. Download the `SKILL.md` file
|
||||||
|
4. If there are other files in the folder, download those too
|
||||||
|
|
||||||
|
### Option B: Clone the Entire Repository
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/yourusername/pm-claude-skills.git
|
||||||
|
cd pm-claude-skills
|
||||||
|
```
|
||||||
|
|
||||||
|
### Option C: Download Pre-packaged Skills (When Available)
|
||||||
|
|
||||||
|
Check the [Releases](https://github.com/yourusername/pm-claude-skills/releases) page for `.skill` files ready to upload.
|
||||||
|
|
||||||
|
## Step 3: Package the Skill
|
||||||
|
|
||||||
|
Skills must be packaged as `.skill` files (which are just renamed .zip files).
|
||||||
|
|
||||||
|
### On Mac/Linux:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Navigate to the skill folder
|
||||||
|
cd pm-claude-skills/skills/prd-template
|
||||||
|
|
||||||
|
# Create a zip of the folder contents
|
||||||
|
zip -r prd-template.skill .
|
||||||
|
|
||||||
|
# Move it somewhere convenient
|
||||||
|
mv prd-template.skill ~/Downloads/
|
||||||
|
```
|
||||||
|
|
||||||
|
### On Windows:
|
||||||
|
|
||||||
|
1. Navigate to the skill folder (e.g., `skills/prd-template`)
|
||||||
|
2. Select all files inside the folder
|
||||||
|
3. Right-click → "Send to" → "Compressed (zipped) folder"
|
||||||
|
4. Rename from `.zip` to `.skill`
|
||||||
|
|
||||||
|
### Important Notes:
|
||||||
|
- ⚠️ The `.skill` file should contain the files directly, NOT a parent folder
|
||||||
|
- ✅ Correct: `prd-template.skill` contains `SKILL.md` at root
|
||||||
|
- ❌ Wrong: `prd-template.skill` contains `prd-template/SKILL.md`
|
||||||
|
|
||||||
|
## Step 4: Upload to Claude
|
||||||
|
|
||||||
|
1. Go to [claude.ai](https://claude.ai)
|
||||||
|
2. Click your profile icon (bottom-left)
|
||||||
|
3. Click **Settings**
|
||||||
|
4. Click **Skills** in the left sidebar
|
||||||
|
5. Click **Upload Skill** button
|
||||||
|
6. Select your `.skill` file
|
||||||
|
7. Wait for "Skill uploaded successfully"
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
That's it! The Skill is now available.
|
||||||
|
|
||||||
|
## Step 5: Test the Skill
|
||||||
|
|
||||||
|
Start a new conversation and test:
|
||||||
|
|
||||||
|
**For PRD Template:**
|
||||||
|
> "Help me write a PRD for a mobile app onboarding feature"
|
||||||
|
|
||||||
|
**For Meeting Notes:**
|
||||||
|
> "Create meeting notes from this discussion: [paste transcript]"
|
||||||
|
|
||||||
|
**For Stakeholder Update:**
|
||||||
|
> "Create a stakeholder update for our Q1 progress"
|
||||||
|
|
||||||
|
Claude should automatically recognize when to use the Skill and apply it.
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
To verify a Skill is installed:
|
||||||
|
|
||||||
|
1. Go to Settings → Skills
|
||||||
|
2. You should see your uploaded Skills listed
|
||||||
|
3. Each Skill shows:
|
||||||
|
- Name
|
||||||
|
- Description
|
||||||
|
- Date uploaded
|
||||||
|
|
||||||
|
## Managing Skills
|
||||||
|
|
||||||
|
### View Installed Skills
|
||||||
|
Settings → Skills → See all installed Skills
|
||||||
|
|
||||||
|
### Remove a Skill
|
||||||
|
Settings → Skills → Click skill → Click "Remove"
|
||||||
|
|
||||||
|
### Update a Skill
|
||||||
|
1. Remove the old version
|
||||||
|
2. Upload the new version
|
||||||
|
|
||||||
|
### Disable a Skill Temporarily
|
||||||
|
Currently not possible - you must remove and re-upload
|
||||||
|
|
||||||
|
## Troubleshooting
|
||||||
|
|
||||||
|
### "Code Execution must be enabled"
|
||||||
|
- Go to Settings → Features → Enable "Code Execution and File Creation"
|
||||||
|
|
||||||
|
### "Invalid skill file"
|
||||||
|
- Make sure you're uploading a `.skill` file (renamed .zip)
|
||||||
|
- Ensure SKILL.md has proper frontmatter (see [Creating Skills](creating-skills.md))
|
||||||
|
- Check that files are at root level, not in a subfolder
|
||||||
|
|
||||||
|
### "Skill uploaded but not working"
|
||||||
|
- Try starting a new conversation
|
||||||
|
- Make sure your request matches the Skill's description triggers
|
||||||
|
- Check that the Skill's frontmatter `description` field is clear
|
||||||
|
|
||||||
|
### Skill triggers at wrong times
|
||||||
|
- The `description` field controls when Skills trigger
|
||||||
|
- Edit SKILL.md to make triggers more specific
|
||||||
|
- Re-package and re-upload
|
||||||
|
|
||||||
|
### Cannot find uploaded Skill
|
||||||
|
- Check Settings → Skills
|
||||||
|
- Try refreshing the page
|
||||||
|
- Try logging out and back in
|
||||||
|
|
||||||
|
## For Team/Enterprise Plans
|
||||||
|
|
||||||
|
### Sharing Skills with Your Team
|
||||||
|
|
||||||
|
Team/Enterprise admins can provision Skills organization-wide:
|
||||||
|
|
||||||
|
1. Go to Admin Console
|
||||||
|
2. Navigate to Skills management
|
||||||
|
3. Upload Skills to organization library
|
||||||
|
4. All team members will have access
|
||||||
|
|
||||||
|
### Private vs. Shared Skills
|
||||||
|
|
||||||
|
- **Private Skills**: Only visible to you
|
||||||
|
- **Shared Skills**: Visible to entire organization
|
||||||
|
- Team admins can make Skills shared
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
- [Customize Skills](customization.md) to match your workflow
|
||||||
|
- [Create your own Skills](creating-skills.md)
|
||||||
|
- [Troubleshooting Guide](troubleshooting.md)
|
||||||
|
|
||||||
|
## Video Tutorial
|
||||||
|
|
||||||
|
[Coming Soon] Watch a 5-minute video walkthrough of the installation process.
|
||||||
|
|
||||||
|
## Need Help?
|
||||||
|
|
||||||
|
- 🐛 [Report an issue](https://github.com/yourusername/pm-claude-skills/issues)
|
||||||
|
- 💬 [Ask in Discussions](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
- ✉️ Email: your-email@example.com
|
||||||
@@ -0,0 +1,421 @@
|
|||||||
|
# Troubleshooting Guide
|
||||||
|
|
||||||
|
Common issues and solutions when using PM Claude Skills.
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
- [Installation Issues](#installation-issues)
|
||||||
|
- [Skill Not Triggering](#skill-not-triggering)
|
||||||
|
- [Skill Triggering at Wrong Times](#skill-triggering-at-wrong-times)
|
||||||
|
- [Output Quality Issues](#output-quality-issues)
|
||||||
|
- [Performance Issues](#performance-issues)
|
||||||
|
- [Team/Enterprise Issues](#teamenterprise-issues)
|
||||||
|
|
||||||
|
## Installation Issues
|
||||||
|
|
||||||
|
### "Code Execution must be enabled"
|
||||||
|
|
||||||
|
**Problem**: You get an error about Code Execution when trying to use Skills.
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Go to claude.ai
|
||||||
|
2. Click profile icon → Settings
|
||||||
|
3. Click "Features"
|
||||||
|
4. Toggle ON "Code Execution and File Creation"
|
||||||
|
5. Click Save
|
||||||
|
6. Refresh the page
|
||||||
|
|
||||||
|
### "Invalid skill file"
|
||||||
|
|
||||||
|
**Problem**: Upload fails with "Invalid skill file" error.
|
||||||
|
|
||||||
|
**Possible Causes & Solutions**:
|
||||||
|
|
||||||
|
1. **File extension is wrong**
|
||||||
|
- Must be `.skill` not `.zip`
|
||||||
|
- Rename: `prd-template.zip` → `prd-template.skill`
|
||||||
|
|
||||||
|
2. **Folder structure is wrong**
|
||||||
|
- ❌ Wrong: `skill.skill` contains `folder/SKILL.md`
|
||||||
|
- ✅ Correct: `skill.skill` contains `SKILL.md` at root
|
||||||
|
- Repackage with files at root level
|
||||||
|
|
||||||
|
3. **SKILL.md frontmatter is malformed**
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
name: skill-name
|
||||||
|
description: Clear description
|
||||||
|
---
|
||||||
|
```
|
||||||
|
- Must have both `name` and `description`
|
||||||
|
- Must be valid YAML
|
||||||
|
- Must have `---` before and after
|
||||||
|
|
||||||
|
4. **File is corrupted**
|
||||||
|
- Try redownloading
|
||||||
|
- Try different compression tool
|
||||||
|
- Check file size (shouldn't be 0 bytes)
|
||||||
|
|
||||||
|
### Cannot find upload button
|
||||||
|
|
||||||
|
**Problem**: Can't find where to upload Skills.
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Make sure you have Pro/Team/Enterprise (not Free)
|
||||||
|
2. Go to Settings (profile icon → Settings)
|
||||||
|
3. Look for "Skills" in left sidebar
|
||||||
|
4. If you don't see it, try:
|
||||||
|
- Refreshing the page
|
||||||
|
- Logging out and back in
|
||||||
|
- Contacting Anthropic support
|
||||||
|
|
||||||
|
### Skill uploaded but not visible
|
||||||
|
|
||||||
|
**Problem**: Upload succeeds but Skill doesn't appear in list.
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Refresh the page (Cmd+R or Ctrl+R)
|
||||||
|
2. Log out and log back in
|
||||||
|
3. Check Settings → Skills again
|
||||||
|
4. Try a different browser
|
||||||
|
5. Clear browser cache
|
||||||
|
|
||||||
|
## Skill Not Triggering
|
||||||
|
|
||||||
|
### Skill doesn't activate when expected
|
||||||
|
|
||||||
|
**Problem**: You ask for something that should trigger the Skill, but Claude doesn't use it.
|
||||||
|
|
||||||
|
**Diagnosis**:
|
||||||
|
1. Check the Skill's `description` field in frontmatter
|
||||||
|
2. Compare your request to the description
|
||||||
|
3. Claude only triggers Skills when request matches description
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
|
||||||
|
1. **Be more explicit in your request**
|
||||||
|
- Instead of: "Help me write a doc"
|
||||||
|
- Try: "Help me write a PRD for feature X"
|
||||||
|
|
||||||
|
2. **Update the Skill description**
|
||||||
|
- Edit SKILL.md frontmatter
|
||||||
|
- Make `description` more comprehensive
|
||||||
|
- Include all trigger scenarios
|
||||||
|
|
||||||
|
Example:
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
description: Use when user asks to create, write, draft, format, or help with a PRD, product requirements document, product spec, feature specification, feature doc, or product documentation for a new feature or product.
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
3. **Start a new conversation**
|
||||||
|
- Skills are loaded at conversation start
|
||||||
|
- Start fresh conversation after uploading Skill
|
||||||
|
|
||||||
|
4. **Mention the Skill type explicitly**
|
||||||
|
- "Using the PRD template, help me write..."
|
||||||
|
- "Create a stakeholder update following the standard format"
|
||||||
|
|
||||||
|
### Claude says it doesn't have access to Skills
|
||||||
|
|
||||||
|
**Problem**: Claude responds "I don't have access to that Skill" or similar.
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
1. Verify Skill is uploaded (Settings → Skills)
|
||||||
|
2. Start a new conversation
|
||||||
|
3. Check Code Execution is enabled
|
||||||
|
4. Re-upload the Skill
|
||||||
|
5. Try different phrasing in your request
|
||||||
|
|
||||||
|
## Skill Triggering at Wrong Times
|
||||||
|
|
||||||
|
### Skill activates when it shouldn't
|
||||||
|
|
||||||
|
**Problem**: Skill triggers for requests where it's not appropriate.
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Make the `description` more specific
|
||||||
|
2. Add negative conditions
|
||||||
|
|
||||||
|
Example:
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
description: Create meeting notes ONLY when user provides meeting transcript, discussion summary, or asks to document a meeting. Do NOT use for general note-taking or todo lists.
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
3. If problem persists, consider splitting into multiple more specific Skills
|
||||||
|
|
||||||
|
### Multiple Skills trigger simultaneously
|
||||||
|
|
||||||
|
**Problem**: Multiple Skills activate and create conflicts.
|
||||||
|
|
||||||
|
**This is expected behavior** - Claude can use multiple Skills together.
|
||||||
|
|
||||||
|
**If it's causing issues**:
|
||||||
|
1. Make Skill descriptions more mutually exclusive
|
||||||
|
2. Remove redundant Skills
|
||||||
|
3. Combine overlapping Skills into one
|
||||||
|
|
||||||
|
## Output Quality Issues
|
||||||
|
|
||||||
|
### Outputs are too generic
|
||||||
|
|
||||||
|
**Problem**: Skill produces generic content that doesn't match your needs.
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
|
||||||
|
1. **Add more specific examples to SKILL.md**
|
||||||
|
```markdown
|
||||||
|
## Example Output
|
||||||
|
|
||||||
|
[Paste your actual anonymized example]
|
||||||
|
|
||||||
|
Key elements:
|
||||||
|
- Specific tone we use
|
||||||
|
- Level of detail expected
|
||||||
|
- Format preferences
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Add company-specific context**
|
||||||
|
```markdown
|
||||||
|
## Our Standards
|
||||||
|
|
||||||
|
- Always include 3-5 metrics
|
||||||
|
- Use data from last 30 days
|
||||||
|
- Reference specific tools (Jira, Mixpanel)
|
||||||
|
```
|
||||||
|
|
||||||
|
3. **Provide more context in your request**
|
||||||
|
- Include relevant background
|
||||||
|
- Mention specific requirements
|
||||||
|
- Reference past examples
|
||||||
|
|
||||||
|
### Outputs are too long/short
|
||||||
|
|
||||||
|
**Problem**: Generated content doesn't match your preferred length.
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
|
||||||
|
1. **Add length guidelines to SKILL.md**
|
||||||
|
```markdown
|
||||||
|
## Length Guidelines
|
||||||
|
|
||||||
|
- PRD: 3-6 pages for features, 8-12 for products
|
||||||
|
- Stakeholder updates: 1 page maximum
|
||||||
|
- Meeting notes: 1-2 pages typical
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Specify in your request**
|
||||||
|
- "Create a brief stakeholder update (under 1 page)"
|
||||||
|
- "Write a detailed PRD (5-6 pages)"
|
||||||
|
|
||||||
|
### Skill missing key information
|
||||||
|
|
||||||
|
**Problem**: Outputs don't include sections you need.
|
||||||
|
|
||||||
|
**Solution**: Update SKILL.md to be more explicit:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Required Sections
|
||||||
|
|
||||||
|
EVERY output MUST include:
|
||||||
|
1. [Section name]
|
||||||
|
2. [Section name]
|
||||||
|
3. [Section name]
|
||||||
|
|
||||||
|
Optional sections (include when relevant):
|
||||||
|
- [Section name]
|
||||||
|
- [Section name]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Format is wrong
|
||||||
|
|
||||||
|
**Problem**: Skill uses wrong formatting, structure, or style.
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
|
||||||
|
1. **Add explicit formatting rules**
|
||||||
|
```markdown
|
||||||
|
## Formatting Rules
|
||||||
|
|
||||||
|
- Use markdown tables for comparisons
|
||||||
|
- Use bullet points for lists
|
||||||
|
- Use numbered lists for sequential steps
|
||||||
|
- Bold key terms and metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Include template in SKILL.md**
|
||||||
|
```markdown
|
||||||
|
## Exact Template
|
||||||
|
|
||||||
|
Use this structure exactly:
|
||||||
|
|
||||||
|
# [Title]
|
||||||
|
|
||||||
|
## Section 1
|
||||||
|
[Content guidelines]
|
||||||
|
|
||||||
|
## Section 2
|
||||||
|
[Content guidelines]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Performance Issues
|
||||||
|
|
||||||
|
### Skills make Claude slower
|
||||||
|
|
||||||
|
**Problem**: Responses take longer when Skills are active.
|
||||||
|
|
||||||
|
**This is normal** - Skills add context that Claude processes.
|
||||||
|
|
||||||
|
**Mitigation**:
|
||||||
|
1. Only upload Skills you actively use
|
||||||
|
2. Remove unused Skills
|
||||||
|
3. Keep SKILL.md files concise
|
||||||
|
4. Use Progressive Disclosure (reference files instead of putting everything in SKILL.md)
|
||||||
|
|
||||||
|
### Skill uses wrong/outdated information
|
||||||
|
|
||||||
|
**Problem**: Skill references old information or outdated examples.
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Update SKILL.md with current information
|
||||||
|
2. Remove outdated examples
|
||||||
|
3. Re-package and re-upload
|
||||||
|
4. Document update in changelog
|
||||||
|
|
||||||
|
## Team/Enterprise Issues
|
||||||
|
|
||||||
|
### Teammates can't see my Skill
|
||||||
|
|
||||||
|
**Problem**: You uploaded a Skill but teammates don't have it.
|
||||||
|
|
||||||
|
**Explanation**: Skills are user-specific by default.
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
|
||||||
|
For Team/Enterprise plans:
|
||||||
|
1. Have admin access Admin Console
|
||||||
|
2. Navigate to Skills management
|
||||||
|
3. Upload to organization library
|
||||||
|
4. Skill becomes available to all team members
|
||||||
|
|
||||||
|
For Pro plans:
|
||||||
|
- Skills are private only
|
||||||
|
- Share the .skill file with teammates
|
||||||
|
- They must upload individually
|
||||||
|
|
||||||
|
### Organization Skill conflicts with my custom version
|
||||||
|
|
||||||
|
**Problem**: Organization uploaded a Skill but you have customizations.
|
||||||
|
|
||||||
|
**Current Limitation**: No easy override mechanism.
|
||||||
|
|
||||||
|
**Workarounds**:
|
||||||
|
1. Request admin update organization Skill with your changes
|
||||||
|
2. Remove your custom version and use organization version
|
||||||
|
3. Give your custom version a different name to avoid conflicts
|
||||||
|
|
||||||
|
### Different team members get different outputs
|
||||||
|
|
||||||
|
**Problem**: Same Skill produces different results for different people.
|
||||||
|
|
||||||
|
**Possible Causes**:
|
||||||
|
|
||||||
|
1. **Different Skill versions**
|
||||||
|
- Solution: Standardize on organization Skill
|
||||||
|
|
||||||
|
2. **Different custom instructions**
|
||||||
|
- Solution: Check Settings → Custom Instructions
|
||||||
|
|
||||||
|
3. **Different prompting**
|
||||||
|
- Solution: Document standard prompts to use
|
||||||
|
|
||||||
|
4. **Skills updated at different times**
|
||||||
|
- Solution: Admin pushes updates to all simultaneously
|
||||||
|
|
||||||
|
## Still Having Issues?
|
||||||
|
|
||||||
|
### Before Asking for Help
|
||||||
|
|
||||||
|
1. **Try the basics**:
|
||||||
|
- Log out and back in
|
||||||
|
- Try different browser
|
||||||
|
- Clear cache
|
||||||
|
- Disable browser extensions
|
||||||
|
- Try incognito mode
|
||||||
|
|
||||||
|
2. **Gather information**:
|
||||||
|
- Which Skill is having issues?
|
||||||
|
- What exactly are you trying to do?
|
||||||
|
- What happens vs. what should happen?
|
||||||
|
- Your Claude plan (Pro/Team/Enterprise)
|
||||||
|
- Screenshots if applicable
|
||||||
|
|
||||||
|
3. **Check existing issues**:
|
||||||
|
- [GitHub Issues](https://github.com/yourusername/pm-claude-skills/issues)
|
||||||
|
- [Discussions](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
|
||||||
|
### Getting Help
|
||||||
|
|
||||||
|
1. **For Skill-specific issues**:
|
||||||
|
- [Open a GitHub Issue](https://github.com/yourusername/pm-claude-skills/issues/new)
|
||||||
|
- Include Skill name, what you expected, what happened
|
||||||
|
|
||||||
|
2. **For Claude platform issues**:
|
||||||
|
- Contact Anthropic support: support@anthropic.com
|
||||||
|
- Check [Anthropic documentation](https://docs.anthropic.com)
|
||||||
|
|
||||||
|
3. **For general questions**:
|
||||||
|
- [Start a Discussion](https://github.com/yourusername/pm-claude-skills/discussions)
|
||||||
|
- Email: your-email@example.com
|
||||||
|
|
||||||
|
### Reporting a Bug
|
||||||
|
|
||||||
|
Use this template when reporting issues:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
**Skill Name**: [which skill]
|
||||||
|
**Claude Plan**: [Pro/Team/Enterprise]
|
||||||
|
**Browser**: [Chrome/Firefox/Safari]
|
||||||
|
|
||||||
|
**Expected Behavior**:
|
||||||
|
[What should happen]
|
||||||
|
|
||||||
|
**Actual Behavior**:
|
||||||
|
[What actually happens]
|
||||||
|
|
||||||
|
**Steps to Reproduce**:
|
||||||
|
1. [Step 1]
|
||||||
|
2. [Step 2]
|
||||||
|
3. [Step 3]
|
||||||
|
|
||||||
|
**Screenshots** (if applicable):
|
||||||
|
[Attach images]
|
||||||
|
|
||||||
|
**Additional Context**:
|
||||||
|
[Any other relevant information]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Common Error Messages
|
||||||
|
|
||||||
|
### "Skill execution failed"
|
||||||
|
- Restart conversation
|
||||||
|
- Check Skill isn't corrupted
|
||||||
|
- Try re-uploading Skill
|
||||||
|
|
||||||
|
### "Unable to load Skill"
|
||||||
|
- Check Code Execution is enabled
|
||||||
|
- Verify Skill is in your Skills list
|
||||||
|
- Try uploading again
|
||||||
|
|
||||||
|
### "Invalid YAML frontmatter"
|
||||||
|
- Check frontmatter syntax in SKILL.md
|
||||||
|
- Ensure `---` markers are present
|
||||||
|
- Verify `name` and `description` fields exist
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
- [Back to Installation](installation.md)
|
||||||
|
- [Customization Guide](customization.md)
|
||||||
|
- [Creating Your Own Skills](creating-skills.md)
|
||||||
@@ -0,0 +1,334 @@
|
|||||||
|
# Example: PRD Created with PRD Template Skill
|
||||||
|
|
||||||
|
This is an example of what the PRD Template Skill produces.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# PRD: Smart Notification Prioritization
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
**Problem Statement**: Users currently receive an average of 47 notifications per day across email, Slack, and in-app channels, leading to notification fatigue and important updates being missed. 73% of users report having disabled notifications entirely, resulting in missed critical communications. Support tickets related to "missed important updates" have increased 45% quarter-over-quarter.
|
||||||
|
|
||||||
|
**Proposed Solution**: Implement an intelligent notification system that learns from user behavior to prioritize notifications based on importance, urgency, and personal relevance. The system will use ML to surface critical notifications while suppressing low-priority ones, reducing notification volume by 60-70% while ensuring no high-priority items are missed.
|
||||||
|
|
||||||
|
**Success Metrics**:
|
||||||
|
- Reduce average daily notifications from 47 to 15-20 (60-70% reduction)
|
||||||
|
- Increase notification click-through rate from 8% to 25%
|
||||||
|
- Decrease support tickets about missed updates by 50%
|
||||||
|
- Maintain or improve user NPS (currently 42)
|
||||||
|
- Achieve 60%+ adoption of smart notifications within 30 days of launch
|
||||||
|
|
||||||
|
## Context & Background
|
||||||
|
|
||||||
|
**Why Now**:
|
||||||
|
- User satisfaction with notifications has dropped from NPS 35 to NPS 12 over past 6 months
|
||||||
|
- Competitors (NotifyHub, SmartFlow) have launched similar features in Q4 2025
|
||||||
|
- Q1 2026 company objective is "Improve user engagement by 20%"
|
||||||
|
- Technical foundation (ML platform) is now mature enough to support this
|
||||||
|
|
||||||
|
**Strategic Alignment**:
|
||||||
|
- Aligns with company mission to "reduce digital noise"
|
||||||
|
- Supports Q1 OKR: Increase DAU by 15%
|
||||||
|
- Enables future personalization features planned for 2026
|
||||||
|
|
||||||
|
**User Research Summary**:
|
||||||
|
We conducted 15 user interviews and surveyed 2,400 users in December 2025. Key findings:
|
||||||
|
- 73% of users have disabled some or all notifications
|
||||||
|
- Users check app 4.2x per day (down from 8.1x 6 months ago)
|
||||||
|
- #1 requested feature is "smarter notifications" (mentioned by 82% of interviewees)
|
||||||
|
- Users want control but not complexity - prefer "works automatically" over manual rules
|
||||||
|
|
||||||
|
## User Stories & Use Cases
|
||||||
|
|
||||||
|
**US1: Intelligent Prioritization**
|
||||||
|
As a busy professional, I want to receive only truly important notifications so that I can focus on my work without constant interruptions.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- System learns from my behavior (which notifications I interact with)
|
||||||
|
- High-priority notifications are never suppressed
|
||||||
|
- Low-priority notifications are batched or suppressed
|
||||||
|
- I can override prioritization for specific channels/people
|
||||||
|
- System shows confidence level for prioritization decisions
|
||||||
|
|
||||||
|
**US2: Priority Override**
|
||||||
|
As a user, I want to mark certain people or channels as "always notify" so that I never miss updates from my manager or critical systems.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- Can mark users, channels, or keywords as high priority
|
||||||
|
- Can mark users, channels, or keywords as low priority
|
||||||
|
- Priority overrides ML decisions
|
||||||
|
- Can manage overrides in settings
|
||||||
|
- Changes take effect immediately
|
||||||
|
|
||||||
|
**US3: Digest Mode**
|
||||||
|
As a user, I want to receive low-priority notifications in a daily digest so that I stay informed without being interrupted throughout the day.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- Digest delivered at time I specify (default 8am)
|
||||||
|
- Contains all non-urgent notifications from previous 24 hours
|
||||||
|
- Grouped by source and topic
|
||||||
|
- Can click through to original context
|
||||||
|
- Can adjust digest frequency (daily, weekly, never)
|
||||||
|
|
||||||
|
**US4: Notification Explanation**
|
||||||
|
As a user, I want to understand why I received (or didn't receive) a notification so that I can trust and adjust the system.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- Each notification shows why it was prioritized high/low
|
||||||
|
- Can view suppressed notifications in notification center
|
||||||
|
- Can provide feedback ("should have been high priority")
|
||||||
|
- System learns from feedback
|
||||||
|
- Transparency builds trust
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
### Functional Requirements
|
||||||
|
|
||||||
|
**P0 (Must-Have for MVP)**:
|
||||||
|
- ML model that learns from user behavior (open rate, click rate, dwell time)
|
||||||
|
- Notification priority classification (High/Medium/Low)
|
||||||
|
- User-configurable priority overrides (people, channels, keywords)
|
||||||
|
- Digest mode for low-priority notifications
|
||||||
|
- Settings page for notification preferences
|
||||||
|
- Ability to see suppressed notifications
|
||||||
|
|
||||||
|
**P1 (Should-Have for V1.1)**:
|
||||||
|
- Notification explanation/reasoning
|
||||||
|
- Smart frequency capping (no more than X high-priority per hour)
|
||||||
|
- Do Not Disturb mode with smart exceptions
|
||||||
|
- Notification scheduling (delay until specific time)
|
||||||
|
- Cross-device consistency
|
||||||
|
|
||||||
|
**P2 (Nice-to-Have for Future)**:
|
||||||
|
- Contextual notifications (based on what I'm doing)
|
||||||
|
- Team notification preferences (manager can set defaults)
|
||||||
|
- Integration with calendar (suppress during meetings)
|
||||||
|
- Natural language configuration ("notify me about urgent customer issues")
|
||||||
|
|
||||||
|
### Non-Functional Requirements
|
||||||
|
|
||||||
|
**Performance**:
|
||||||
|
- Prioritization decision in <100ms
|
||||||
|
- No impact on notification delivery speed
|
||||||
|
- Model inference <50ms
|
||||||
|
|
||||||
|
**Privacy**:
|
||||||
|
- All ML training happens on-device or with anonymized data
|
||||||
|
- User can opt out of ML training
|
||||||
|
- Clear privacy policy about data usage
|
||||||
|
- GDPR compliant
|
||||||
|
|
||||||
|
**Scalability**:
|
||||||
|
- Support 100k users in MVP
|
||||||
|
- Scale to 1M users by end of Q2
|
||||||
|
- Handle 10M+ notifications per day
|
||||||
|
|
||||||
|
**Accuracy**:
|
||||||
|
- 90%+ accuracy on priority classification
|
||||||
|
- <1% false negative rate on high-priority items
|
||||||
|
- Users can correct mistakes easily
|
||||||
|
|
||||||
|
**Accessibility**:
|
||||||
|
- Notification priority indicated via text, not just color
|
||||||
|
- Screen reader compatible
|
||||||
|
- Keyboard navigation support
|
||||||
|
- Respects system-level accessibility settings
|
||||||
|
|
||||||
|
## Design & User Experience
|
||||||
|
|
||||||
|
**Key Flows**:
|
||||||
|
|
||||||
|
1. **First-Time Setup** (30 seconds)
|
||||||
|
- Welcome modal explains smart notifications
|
||||||
|
- User chooses: Auto mode vs Manual configuration
|
||||||
|
- If manual: Configure 2-3 high-priority sources
|
||||||
|
- One-click enable
|
||||||
|
|
||||||
|
2. **Receiving Smart Notification**
|
||||||
|
- High-priority: Immediate delivery (same as today)
|
||||||
|
- Medium-priority: Delivered but not pushed to phone
|
||||||
|
- Low-priority: Added to digest
|
||||||
|
- Visual indicator of priority level
|
||||||
|
|
||||||
|
3. **Reviewing Digest**
|
||||||
|
- Daily email/in-app digest
|
||||||
|
- Grouped by topic
|
||||||
|
- Quick actions (archive, star, open)
|
||||||
|
- One-click feedback
|
||||||
|
|
||||||
|
4. **Adjusting Priorities**
|
||||||
|
- Right-click any notification → "Always/Never notify from this source"
|
||||||
|
- Settings page with list of overrides
|
||||||
|
- Smart suggestions based on behavior
|
||||||
|
|
||||||
|
**Wireframes**: [Link to Figma - designs/smart-notifications-v2]
|
||||||
|
|
||||||
|
**Edge Cases**:
|
||||||
|
- User has never interacted with notifications (no training data)
|
||||||
|
- Solution: Use heuristics for first 2 weeks, then switch to ML
|
||||||
|
- User marks everything high priority
|
||||||
|
- Solution: Show warning, explain defeats purpose
|
||||||
|
- System makes obvious mistake
|
||||||
|
- Solution: Prominent feedback option, apologize, learn
|
||||||
|
|
||||||
|
## Technical Considerations
|
||||||
|
|
||||||
|
**Architecture**:
|
||||||
|
- ML model: TensorFlow Lite for on-device inference
|
||||||
|
- Backend: Python service for model training
|
||||||
|
- Storage: User preferences in PostgreSQL, training data in BigQuery
|
||||||
|
- Real-time: Kafka for notification event stream
|
||||||
|
|
||||||
|
**Dependencies**:
|
||||||
|
- ML platform team (model training infrastructure)
|
||||||
|
- Notification service (existing system to extend)
|
||||||
|
- Mobile team (push notification handling)
|
||||||
|
- Data team (training data pipeline)
|
||||||
|
|
||||||
|
**Technical Risks**:
|
||||||
|
1. **ML model accuracy may be insufficient**
|
||||||
|
- Mitigation: A/B test with 10% of users, fall back to rule-based if accuracy <85%
|
||||||
|
- Backup: Manual rule configuration always available
|
||||||
|
|
||||||
|
2. **On-device inference may be too slow**
|
||||||
|
- Mitigation: Benchmark on low-end devices early
|
||||||
|
- Backup: Server-side inference with caching
|
||||||
|
|
||||||
|
3. **Cold start problem (new users)**
|
||||||
|
- Mitigation: Use heuristic rules for first 2 weeks
|
||||||
|
- Backup: Offer quick setup wizard with common patterns
|
||||||
|
|
||||||
|
**Data Requirements**:
|
||||||
|
- Need 4-6 weeks of notification interaction data for training
|
||||||
|
- Minimum 1000 notification interactions per user for good accuracy
|
||||||
|
- Will use existing data from past 6 months
|
||||||
|
|
||||||
|
## Implementation Plan
|
||||||
|
|
||||||
|
### Phase 1: MVP (8 weeks)
|
||||||
|
**Goal**: Smart prioritization working for 10% of users
|
||||||
|
|
||||||
|
- Week 1-2: ML model development and training
|
||||||
|
- Week 3-4: Backend service implementation
|
||||||
|
- Week 5-6: Frontend and mobile integration
|
||||||
|
- Week 7: Internal testing
|
||||||
|
- Week 8: Beta launch to 10% of users
|
||||||
|
|
||||||
|
**Deliverables**:
|
||||||
|
- ML model with 85%+ accuracy
|
||||||
|
- Priority classification (High/Low only, no digest)
|
||||||
|
- Basic user overrides
|
||||||
|
- Settings page
|
||||||
|
- Analytics instrumentation
|
||||||
|
|
||||||
|
### Phase 2: V1.0 (4 weeks)
|
||||||
|
**Goal**: Polish and scale to 100% of users
|
||||||
|
|
||||||
|
- Week 9-10: Add Medium priority and digest mode
|
||||||
|
- Week 11: Performance optimization and bug fixes
|
||||||
|
- Week 12: Ramp to 100% of users
|
||||||
|
|
||||||
|
**Deliverables**:
|
||||||
|
- Three-tier priority (High/Medium/Low)
|
||||||
|
- Digest mode
|
||||||
|
- Notification explanations
|
||||||
|
- Documentation and support materials
|
||||||
|
|
||||||
|
### Phase 3: V1.1 (6 weeks)
|
||||||
|
**Goal**: Advanced features and refinement
|
||||||
|
|
||||||
|
- Week 13-14: Frequency capping
|
||||||
|
- Week 15-16: DND mode with exceptions
|
||||||
|
- Week 17-18: Cross-device consistency
|
||||||
|
|
||||||
|
**Deliverables**:
|
||||||
|
- Smart frequency capping
|
||||||
|
- DND mode
|
||||||
|
- Refined ML model based on production data
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
**Product Questions**:
|
||||||
|
1. Should we allow notification prioritization for external emails, or only in-app?
|
||||||
|
- **Owner**: Tom (PM) to research email provider APIs
|
||||||
|
- **Due**: Feb 1
|
||||||
|
|
||||||
|
2. What's the right default digest frequency? Daily or weekly?
|
||||||
|
- **Owner**: Jennifer (Design) to user test both options
|
||||||
|
- **Due**: Jan 28
|
||||||
|
|
||||||
|
3. Do we need a "learning period" message while model trains?
|
||||||
|
- **Owner**: Tom (PM) to draft messaging options
|
||||||
|
- **Due**: Jan 25
|
||||||
|
|
||||||
|
**Technical Questions**:
|
||||||
|
1. Can we achieve <100ms inference on older devices?
|
||||||
|
- **Owner**: Mike (Eng) to benchmark on 5 device types
|
||||||
|
- **Due**: Jan 27
|
||||||
|
|
||||||
|
2. What's our data retention policy for training data?
|
||||||
|
- **Owner**: Sarah (CPO) to consult Legal team
|
||||||
|
- **Due**: Feb 3
|
||||||
|
|
||||||
|
**Business Questions**:
|
||||||
|
1. Should this be a paid feature or included in free tier?
|
||||||
|
- **Owner**: Sarah (CPO) to consult with Product Marketing
|
||||||
|
- **Due**: Feb 10
|
||||||
|
|
||||||
|
## Success Criteria
|
||||||
|
|
||||||
|
### Launch Criteria (Before 100% Rollout)
|
||||||
|
- [ ] 85%+ ML accuracy in beta
|
||||||
|
- [ ] <1% false negative rate on high-priority
|
||||||
|
- [ ] User NPS score of 7+ (out of 10) in beta
|
||||||
|
- [ ] Zero critical bugs
|
||||||
|
- [ ] Performance <100ms 95th percentile
|
||||||
|
- [ ] Legal and privacy review complete
|
||||||
|
- [ ] Support team trained
|
||||||
|
- [ ] Docs and help center updated
|
||||||
|
|
||||||
|
### Post-Launch Success (30 days)
|
||||||
|
- Notification volume reduced 60-70%
|
||||||
|
- Click-through rate increased to 25%+
|
||||||
|
- Support tickets about missed updates down 50%
|
||||||
|
- User NPS maintained or improved (>42)
|
||||||
|
- 60%+ of users have smart notifications enabled
|
||||||
|
- <5% of users disable feature
|
||||||
|
|
||||||
|
### Long-Term Success (90 days)
|
||||||
|
- DAU increased 15%
|
||||||
|
- User engagement (sessions per day) up 25%
|
||||||
|
- NPS improvement to 50+
|
||||||
|
- Feature becomes top 3 in user satisfaction surveys
|
||||||
|
|
||||||
|
## Appendix
|
||||||
|
|
||||||
|
### Research & Resources
|
||||||
|
- User research synthesis: [Link to Notion doc]
|
||||||
|
- Competitive analysis: [Link to competitive landscape]
|
||||||
|
- ML model documentation: [Link to technical spec]
|
||||||
|
- Design system: [Link to Figma component library]
|
||||||
|
|
||||||
|
### Competitive Analysis
|
||||||
|
- **NotifyHub**: Launched similar feature in Nov 2025, 72% user adoption
|
||||||
|
- **SmartFlow**: Basic priority rules (manual only), no ML
|
||||||
|
- **Opportunity**: Neither has on-device ML or explanation features
|
||||||
|
|
||||||
|
### Related Documents
|
||||||
|
- Q1 2026 Roadmap: [Link]
|
||||||
|
- Notification service architecture: [Link]
|
||||||
|
- Privacy policy updates: [Link]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Document History**
|
||||||
|
- v1.0 - Jan 15, 2026 - Initial draft (Tom)
|
||||||
|
- v1.1 - Jan 18, 2026 - Added technical risks, updated timeline (Tom + Mike)
|
||||||
|
- v1.2 - Jan 20, 2026 - Final review comments incorporated (Sarah)
|
||||||
|
|
||||||
|
**Approvals**
|
||||||
|
- [x] Engineering: Mike Chen - Jan 20, 2026
|
||||||
|
- [x] Design: Jennifer Lee - Jan 20, 2026
|
||||||
|
- [x] Product: Sarah Johnson - Jan 20, 2026
|
||||||
|
- [ ] Security: Pending review - Due Jan 24, 2026
|
||||||
@@ -0,0 +1,251 @@
|
|||||||
|
---
|
||||||
|
name: competitive-analysis
|
||||||
|
description: Analyze competitors and create competitive landscape documentation. Use when the user asks to analyze competitors, create competitive analysis, compare features with competitors, track competitive landscape, or understand competitive positioning.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Competitive Analysis Skill
|
||||||
|
|
||||||
|
This skill creates structured competitive analyses for product decision-making.
|
||||||
|
|
||||||
|
## Analysis Framework
|
||||||
|
|
||||||
|
### 1. Executive Summary
|
||||||
|
- **Market Position**: Where we stand relative to competitors
|
||||||
|
- **Key Findings**: Top 3-5 insights from analysis
|
||||||
|
- **Strategic Implications**: What this means for our roadmap
|
||||||
|
|
||||||
|
### 2. Competitor Profiles
|
||||||
|
|
||||||
|
For each major competitor:
|
||||||
|
|
||||||
|
**[Competitor Name]**
|
||||||
|
- **Company Overview**: Size, funding, market position
|
||||||
|
- **Target Customer**: Who they serve
|
||||||
|
- **Value Proposition**: Their core positioning
|
||||||
|
- **Business Model**: How they make money
|
||||||
|
- **Strengths**: What they do well
|
||||||
|
- **Weaknesses**: Where they fall short
|
||||||
|
- **Recent Activity**: Major updates, funding, announcements
|
||||||
|
|
||||||
|
### 3. Feature Comparison Matrix
|
||||||
|
|
||||||
|
| Feature | Us | Competitor A | Competitor B | Competitor C |
|
||||||
|
|---------|-----|--------------|--------------|--------------|
|
||||||
|
| Core Feature 1 | ✅ Full | ✅ Full | ⚠️ Limited | ❌ None |
|
||||||
|
| Core Feature 2 | ✅ Full | ⚠️ Limited | ✅ Full | ✅ Full |
|
||||||
|
| Advanced Feature 1 | ⚠️ Beta | ❌ None | ✅ Full | ❌ None |
|
||||||
|
|
||||||
|
Legend:
|
||||||
|
- ✅ Full: Complete, production-ready feature
|
||||||
|
- ⚠️ Limited/Beta: Partial or in-development
|
||||||
|
- ❌ None: Feature not available
|
||||||
|
|
||||||
|
Include notes on quality/implementation differences where significant.
|
||||||
|
|
||||||
|
### 4. Pricing Comparison
|
||||||
|
|
||||||
|
| Plan Type | Us | Competitor A | Competitor B | Competitor C |
|
||||||
|
|-----------|-----|--------------|--------------|--------------|
|
||||||
|
| Free/Trial | $0 | $0 | $0 | N/A |
|
||||||
|
| Starter | $29/mo | $25/mo | $39/mo | $49/mo |
|
||||||
|
| Professional | $79/mo | $89/mo | $79/mo | $99/mo |
|
||||||
|
| Enterprise | Custom | Custom | $299/mo | Custom |
|
||||||
|
|
||||||
|
**Pricing Strategy Notes**:
|
||||||
|
- How our pricing compares
|
||||||
|
- Value perception
|
||||||
|
- Packaging differences
|
||||||
|
|
||||||
|
### 5. Strengths & Weaknesses Analysis
|
||||||
|
|
||||||
|
**Our Competitive Advantages:**
|
||||||
|
1. [Strength] - [Why it matters]
|
||||||
|
2. [Strength] - [Why it matters]
|
||||||
|
3. [Strength] - [Why it matters]
|
||||||
|
|
||||||
|
**Our Gaps vs. Competition:**
|
||||||
|
1. [Gap] - [Impact on customers]
|
||||||
|
2. [Gap] - [Impact on customers]
|
||||||
|
3. [Gap] - [Impact on customers]
|
||||||
|
|
||||||
|
### 6. Customer Perception Analysis
|
||||||
|
|
||||||
|
**What Customers Say About Competitors** (from reviews, G2, social media):
|
||||||
|
|
||||||
|
**Competitor A:**
|
||||||
|
- Most Praised: [Common positive feedback]
|
||||||
|
- Most Criticized: [Common complaints]
|
||||||
|
- Typical User: [Who uses them]
|
||||||
|
|
||||||
|
**Competitor B:**
|
||||||
|
- Most Praised: [Common positive feedback]
|
||||||
|
- Most Criticized: [Common complaints]
|
||||||
|
- Typical User: [Who uses them]
|
||||||
|
|
||||||
|
### 7. Market Positioning Map
|
||||||
|
|
||||||
|
Describe or diagram positioning on key dimensions:
|
||||||
|
- Y-Axis: [e.g., Enterprise vs. SMB]
|
||||||
|
- X-Axis: [e.g., Simple vs. Comprehensive]
|
||||||
|
|
||||||
|
**Our Position**: [Where we sit and why]
|
||||||
|
**Whitespace Opportunities**: [Underserved segments]
|
||||||
|
|
||||||
|
### 8. Win/Loss Analysis
|
||||||
|
|
||||||
|
**Why We Win Against Competitors:**
|
||||||
|
- Better at: [Specific capabilities]
|
||||||
|
- Target customers that value: [What matters]
|
||||||
|
|
||||||
|
**Why We Lose to Competitors:**
|
||||||
|
- When customers need: [Specific requirements]
|
||||||
|
- When they prioritize: [What they value]
|
||||||
|
|
||||||
|
### 9. Strategic Implications & Recommendations
|
||||||
|
|
||||||
|
**Immediate Actions** (0-3 months):
|
||||||
|
1. [Action] - [Rationale]
|
||||||
|
2. [Action] - [Rationale]
|
||||||
|
|
||||||
|
**Medium-term Strategy** (3-12 months):
|
||||||
|
1. [Action] - [Rationale]
|
||||||
|
2. [Action] - [Rationale]
|
||||||
|
|
||||||
|
**Long-term Positioning** (12+ months):
|
||||||
|
1. [Strategic direction] - [Rationale]
|
||||||
|
|
||||||
|
## Analysis Best Practices
|
||||||
|
|
||||||
|
**Data Sources:**
|
||||||
|
- Competitor websites and documentation
|
||||||
|
- G2, Capterra, TrustRadius reviews
|
||||||
|
- Customer interviews (especially win/loss)
|
||||||
|
- Sales team feedback
|
||||||
|
- Social media and community discussions
|
||||||
|
- Industry analysts and reports
|
||||||
|
- Competitor job postings (reveal strategy)
|
||||||
|
|
||||||
|
**Quality Standards:**
|
||||||
|
✅ Use recent data (within 3-6 months)
|
||||||
|
✅ Include sources for claims
|
||||||
|
✅ Focus on verifiable facts over assumptions
|
||||||
|
✅ Consider different customer segments
|
||||||
|
✅ Update regularly (at least quarterly)
|
||||||
|
|
||||||
|
❌ Don't rely solely on competitor marketing
|
||||||
|
❌ Don't ignore smaller/emerging competitors
|
||||||
|
❌ Don't assume features work well just because they exist
|
||||||
|
❌ Don't forget about indirect/substitute competitors
|
||||||
|
|
||||||
|
**Ethical Guidelines:**
|
||||||
|
- Use only publicly available information
|
||||||
|
- Don't misrepresent competitor capabilities
|
||||||
|
- Be honest about their strengths
|
||||||
|
- Don't disparage competitors personally
|
||||||
|
|
||||||
|
## Monitoring Cadence
|
||||||
|
|
||||||
|
**Weekly**: Check for major announcements, funding, leadership changes
|
||||||
|
**Monthly**: Review feature releases, pricing changes, marketing campaigns
|
||||||
|
**Quarterly**: Comprehensive feature comparison, strategic assessment
|
||||||
|
**Annually**: Market position analysis, long-term trend evaluation
|
||||||
|
|
||||||
|
## Example Analysis Section
|
||||||
|
|
||||||
|
```
|
||||||
|
## Competitor Profile: DataSync Pro
|
||||||
|
|
||||||
|
**Company Overview**
|
||||||
|
- Founded 2019, 85 employees, $12M Series A (2023)
|
||||||
|
- Fast-growing in mid-market segment
|
||||||
|
- Strong presence in Europe
|
||||||
|
|
||||||
|
**Target Customer**
|
||||||
|
- Mid-market companies (100-1000 employees)
|
||||||
|
- Technical users comfortable with APIs
|
||||||
|
- Data-intensive operations
|
||||||
|
|
||||||
|
**Value Proposition**
|
||||||
|
"The fastest way to sync data across your entire stack"
|
||||||
|
- Focus on speed and reliability
|
||||||
|
- Developer-first approach
|
||||||
|
|
||||||
|
**Business Model**
|
||||||
|
- Freemium with generous free tier
|
||||||
|
- Usage-based pricing above free limits
|
||||||
|
- Professional services for enterprise
|
||||||
|
|
||||||
|
**Strengths**
|
||||||
|
- Superior sync speed (2-3x faster than alternatives)
|
||||||
|
- Best-in-class developer documentation
|
||||||
|
- Strong developer community (5k+ GitHub stars)
|
||||||
|
- Excellent uptime (99.97% vs industry 99.5%)
|
||||||
|
- Modern, intuitive API design
|
||||||
|
|
||||||
|
**Weaknesses**
|
||||||
|
- Limited no-code options (requires technical knowledge)
|
||||||
|
- Smaller integration library (45 vs our 120)
|
||||||
|
- No dedicated enterprise features
|
||||||
|
- Limited customization options
|
||||||
|
- Support can be slow (avg 8hr response time)
|
||||||
|
|
||||||
|
**Recent Activity**
|
||||||
|
- Jan 2026: Released real-time sync capabilities
|
||||||
|
- Dec 2025: Raised $12M Series A
|
||||||
|
- Nov 2025: Added webhooks and event streaming
|
||||||
|
- Hired ex-Stripe engineering lead as CTO
|
||||||
|
|
||||||
|
**Strategic Implications**
|
||||||
|
- Their focus on speed creates pressure on our performance
|
||||||
|
- Developer-first approach winning technical buyers
|
||||||
|
- Gaps in no-code and enterprise create opportunities
|
||||||
|
- Need to monitor their enterprise moves closely
|
||||||
|
```
|
||||||
|
|
||||||
|
## Feature Comparison Best Practices
|
||||||
|
|
||||||
|
When comparing features:
|
||||||
|
|
||||||
|
1. **Group by Category**
|
||||||
|
- Core functionality
|
||||||
|
- Integration capabilities
|
||||||
|
- Analytics/reporting
|
||||||
|
- Security/compliance
|
||||||
|
- Collaboration features
|
||||||
|
|
||||||
|
2. **Note Quality Differences**
|
||||||
|
- Not all implementations are equal
|
||||||
|
- Speed, reliability, UX matter
|
||||||
|
- Example: "Both have API, but theirs has rate limits"
|
||||||
|
|
||||||
|
3. **Consider the Complete Experience**
|
||||||
|
- Onboarding process
|
||||||
|
- Documentation quality
|
||||||
|
- Support responsiveness
|
||||||
|
- Mobile experience
|
||||||
|
|
||||||
|
4. **Identify Gaps That Matter**
|
||||||
|
- What customers actually care about
|
||||||
|
- Not just feature count
|
||||||
|
- Focus on differentiators
|
||||||
|
|
||||||
|
## Win/Loss Analysis Template
|
||||||
|
|
||||||
|
When analyzing why you win or lose deals:
|
||||||
|
|
||||||
|
**Win Against [Competitor]**
|
||||||
|
- **Scenarios**: When do we win?
|
||||||
|
- **Key Differentiators**: What tips the decision?
|
||||||
|
- **Customer Quotes**: What they tell us
|
||||||
|
- **Typical Profile**: Who chooses us?
|
||||||
|
|
||||||
|
**Loss Against [Competitor]**
|
||||||
|
- **Scenarios**: When do we lose?
|
||||||
|
- **Their Advantages**: What tips the decision?
|
||||||
|
- **Customer Quotes**: What they tell us
|
||||||
|
- **Typical Profile**: Who chooses them?
|
||||||
|
|
||||||
|
**Lessons Learned**
|
||||||
|
- What we need to improve
|
||||||
|
- What we need to communicate better
|
||||||
|
- Where we should compete differently
|
||||||
@@ -0,0 +1,260 @@
|
|||||||
|
---
|
||||||
|
name: meeting-notes
|
||||||
|
description: Structure and format meeting notes following PM best practices. Use when the user needs to create, format, or organize meeting notes, capture action items from meetings, or document discussions and decisions.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Meeting Notes Skill
|
||||||
|
|
||||||
|
This skill structures meeting notes to maximize value and ensure follow-through.
|
||||||
|
|
||||||
|
## Standard Meeting Notes Template
|
||||||
|
|
||||||
|
### Meeting Header
|
||||||
|
**Meeting**: [Meeting Title]
|
||||||
|
**Date**: [Date]
|
||||||
|
**Attendees**: [Names/Roles]
|
||||||
|
**Note Taker**: [Name]
|
||||||
|
**Duration**: [Actual duration]
|
||||||
|
|
||||||
|
### Agenda
|
||||||
|
- [ ] Topic 1
|
||||||
|
- [ ] Topic 2
|
||||||
|
- [ ] Topic 3
|
||||||
|
|
||||||
|
*(Check off items as discussed)*
|
||||||
|
|
||||||
|
### Decisions Made
|
||||||
|
Clear documentation of decisions:
|
||||||
|
|
||||||
|
**Decision**: [What was decided]
|
||||||
|
**Context**: [Why this decision]
|
||||||
|
**Owner**: [Who's responsible for executing]
|
||||||
|
**Deadline**: [When if applicable]
|
||||||
|
|
||||||
|
Use this format for each decision made.
|
||||||
|
|
||||||
|
### Action Items
|
||||||
|
All action items should be:
|
||||||
|
- [ ] **[Action item]** - @Owner - Due: [Date]
|
||||||
|
- [ ] **[Action item]** - @Owner - Due: [Date]
|
||||||
|
|
||||||
|
Format:
|
||||||
|
- Clear, specific action
|
||||||
|
- Single owner (no "team" ownership)
|
||||||
|
- Concrete deadline
|
||||||
|
- Checkbox for tracking
|
||||||
|
|
||||||
|
### Discussion Notes
|
||||||
|
Key points discussed organized by topic:
|
||||||
|
|
||||||
|
**Topic 1: [Name]**
|
||||||
|
- Key point or discussion highlight
|
||||||
|
- Important context or concern raised
|
||||||
|
- Any data or information shared
|
||||||
|
|
||||||
|
**Topic 2: [Name]**
|
||||||
|
- Key discussion points
|
||||||
|
- Decisions or conclusions reached
|
||||||
|
|
||||||
|
### Open Questions / Follow-Up
|
||||||
|
Questions that couldn't be answered:
|
||||||
|
- **Question**: [What we need to know]
|
||||||
|
- **Owner**: [Who will find out]
|
||||||
|
- **By When**: [Deadline]
|
||||||
|
|
||||||
|
### Next Steps
|
||||||
|
Clear summary of what happens next:
|
||||||
|
1. [Immediate next action]
|
||||||
|
2. [Follow-up meeting if needed]
|
||||||
|
3. [Any broader process to start]
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
|
||||||
|
**During the meeting:**
|
||||||
|
- Focus on decisions and action items over dialogue
|
||||||
|
- Capture specific commitments, not general discussion
|
||||||
|
- Note dissenting opinions on important decisions
|
||||||
|
- Ask for clarity on vague commitments ("I'll look into it" → "I'll analyze the data and share findings by Friday")
|
||||||
|
|
||||||
|
**After the meeting:**
|
||||||
|
- Send notes within 2 hours while fresh
|
||||||
|
- Tag action item owners (@mention them)
|
||||||
|
- Include links to relevant documents
|
||||||
|
- Follow up on overdue action items
|
||||||
|
|
||||||
|
**What to capture:**
|
||||||
|
✅ Decisions made
|
||||||
|
✅ Action items with owners and deadlines
|
||||||
|
✅ Key points of discussion
|
||||||
|
✅ Open questions
|
||||||
|
✅ Next steps
|
||||||
|
|
||||||
|
**What to skip:**
|
||||||
|
❌ Verbatim transcripts
|
||||||
|
❌ Off-topic tangents
|
||||||
|
❌ Preliminary discussion before decisions
|
||||||
|
❌ Redundant information
|
||||||
|
|
||||||
|
## Meeting Types & Adaptations
|
||||||
|
|
||||||
|
### 1:1 Meetings
|
||||||
|
Focus on:
|
||||||
|
- Career development discussions
|
||||||
|
- Feedback (both directions)
|
||||||
|
- Current challenges
|
||||||
|
- Action items for both parties
|
||||||
|
|
||||||
|
Template additions:
|
||||||
|
- **Recent Wins**: What's going well
|
||||||
|
- **Challenges**: What's not going well
|
||||||
|
- **Career Discussion**: Development topics
|
||||||
|
- **Feedback**: For both parties
|
||||||
|
|
||||||
|
### Sprint Planning
|
||||||
|
Focus on:
|
||||||
|
- Story acceptance criteria
|
||||||
|
- Sizing/estimation decisions
|
||||||
|
- Dependency identification
|
||||||
|
- Sprint commitment
|
||||||
|
|
||||||
|
Template additions:
|
||||||
|
- **Sprint Goal**: What we're committing to
|
||||||
|
- **Story Points**: Capacity and estimates
|
||||||
|
- **Dependencies**: External blockers
|
||||||
|
- **Definition of Done**: Acceptance criteria
|
||||||
|
|
||||||
|
### Product Reviews
|
||||||
|
Focus on:
|
||||||
|
- Design decisions
|
||||||
|
- User feedback discussed
|
||||||
|
- Changes requested
|
||||||
|
- Launch readiness assessment
|
||||||
|
|
||||||
|
Template additions:
|
||||||
|
- **Design Decisions**: What was approved/rejected
|
||||||
|
- **User Feedback**: Key insights discussed
|
||||||
|
- **Open Design Questions**: What needs iteration
|
||||||
|
- **Launch Criteria**: Remaining requirements
|
||||||
|
|
||||||
|
### Stakeholder Sync
|
||||||
|
Focus on:
|
||||||
|
- Status updates delivered
|
||||||
|
- Concerns raised
|
||||||
|
- Approvals given
|
||||||
|
- Escalation needs
|
||||||
|
|
||||||
|
Template additions:
|
||||||
|
- **Status Overview**: High-level progress
|
||||||
|
- **Approvals Obtained**: Sign-offs received
|
||||||
|
- **Escalations**: Issues raised to stakeholders
|
||||||
|
- **Next Sync**: When and what to cover
|
||||||
|
|
||||||
|
## Example Meeting Notes
|
||||||
|
|
||||||
|
```
|
||||||
|
# Product Roadmap Review - Q1 2026
|
||||||
|
**Date**: January 20, 2026
|
||||||
|
**Attendees**: Sarah (CPO), Mike (Eng Lead), Jennifer (Design), Tom (PM)
|
||||||
|
**Note Taker**: Tom
|
||||||
|
**Duration**: 45 minutes
|
||||||
|
|
||||||
|
## Agenda
|
||||||
|
- [x] Review Q1 planned features
|
||||||
|
- [x] Discuss resource constraints
|
||||||
|
- [x] Prioritization discussion
|
||||||
|
- [x] Timeline alignment
|
||||||
|
|
||||||
|
## Decisions Made
|
||||||
|
|
||||||
|
**Decision**: Move multi-channel dashboard to Q2, prioritize mobile app improvements for Q1
|
||||||
|
**Context**: Customer feedback shows mobile experience is significantly impacting retention (65% of users primarily mobile). Engineering team can only tackle one major initiative this quarter.
|
||||||
|
**Owner**: Tom (PM) to communicate to stakeholders
|
||||||
|
**Deadline**: January 22
|
||||||
|
|
||||||
|
**Decision**: Allocate 20% of engineering time to technical debt
|
||||||
|
**Context**: Accumulated tech debt is slowing feature development. Team velocity dropped 30% last quarter.
|
||||||
|
**Owner**: Mike (Eng Lead) to create tech debt backlog
|
||||||
|
**Deadline**: January 27
|
||||||
|
|
||||||
|
**Decision**: Run mobile beta with 100 users before full launch
|
||||||
|
**Context**: Need to validate improvements on diverse devices
|
||||||
|
**Owner**: Jennifer (Design) to coordinate with QA
|
||||||
|
**Deadline**: February 10
|
||||||
|
|
||||||
|
## Action Items
|
||||||
|
- [ ] **Update Q1 roadmap deck with new prioritization** - @Tom - Due: Jan 22
|
||||||
|
- [ ] **Schedule alignment meeting with support team about dashboard delay** - @Tom - Due: Jan 24
|
||||||
|
- [ ] **Create tech debt prioritization rubric** - @Mike - Due: Jan 27
|
||||||
|
- [ ] **Run user testing on mobile designs** - @Jennifer - Due: Feb 3
|
||||||
|
- [ ] **Document decision rationale for executives** - @Sarah - Due: Jan 23
|
||||||
|
- [ ] **Identify 100 beta users for mobile** - @Tom - Due: Feb 1
|
||||||
|
|
||||||
|
## Discussion Notes
|
||||||
|
|
||||||
|
**Q1 Feature Prioritization**
|
||||||
|
- Customer retention is #1 company priority this quarter
|
||||||
|
- Mobile app NPS score is 6.2 (vs 8.1 for web)
|
||||||
|
- Mobile accounts for 65% of daily active users
|
||||||
|
- Multi-channel dashboard would take 8 engineering weeks
|
||||||
|
- Mobile improvements estimated at 6 engineering weeks with higher ROI
|
||||||
|
- Sales has 3 enterprise deals waiting on dashboard feature
|
||||||
|
|
||||||
|
**Resource Constraints**
|
||||||
|
- Currently 4 engineers available (down from 6 last quarter due to attrition)
|
||||||
|
- Design team can support both initiatives but at reduced capacity
|
||||||
|
- QA team needs 2 weeks for thorough testing on mobile
|
||||||
|
- One engineer on loan to security team through February
|
||||||
|
|
||||||
|
**Risk Discussion**
|
||||||
|
- Delaying dashboard may impact enterprise sales (3 deals waiting)
|
||||||
|
- Sarah noted: "We can position mobile improvements as foundation for enterprise features"
|
||||||
|
- Mike raised concern about mobile tech stack stability - addressed through tech debt allocation
|
||||||
|
- Need to communicate clearly with Sales about timeline change
|
||||||
|
|
||||||
|
**Mobile Implementation Plan**
|
||||||
|
- Week 1-2: Design refinements based on user feedback
|
||||||
|
- Week 3-4: Engineering implementation
|
||||||
|
- Week 5: Internal testing
|
||||||
|
- Week 6: Beta with 100 users
|
||||||
|
- Week 7: Full rollout
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
- **Question**: What's the impact on enterprise pipeline if we delay dashboard?
|
||||||
|
**Owner**: Sarah will check with Sales leadership
|
||||||
|
**By When**: January 23
|
||||||
|
|
||||||
|
- **Question**: Can we do a limited beta of dashboard for enterprise customers?
|
||||||
|
**Owner**: Tom will explore MVP scope with Mike
|
||||||
|
**By When**: January 25
|
||||||
|
|
||||||
|
- **Question**: What's our plan if mobile improvements don't hit target metrics?
|
||||||
|
**Owner**: Tom will create contingency plan
|
||||||
|
**By When**: January 27
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
1. Tom to send updated roadmap to leadership by EOD Wednesday (Jan 22)
|
||||||
|
2. Team to begin sprint planning for mobile improvements next Monday (Jan 27)
|
||||||
|
3. Follow-up meeting on Feb 1 to review progress and validate prioritization
|
||||||
|
4. Sarah to present decision rationale to executive team on Jan 24
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Next Meeting**: February 1, 2026 - Progress Check-in
|
||||||
|
**Notes Sent**: January 20, 2026 5:30 PM
|
||||||
|
```
|
||||||
|
|
||||||
|
## Notes Distribution
|
||||||
|
|
||||||
|
**Subject Line Format**: "[Meeting Type] Notes - [Date] - [Key Topic]"
|
||||||
|
|
||||||
|
Example: "Product Roadmap Review Notes - Jan 20 - Q1 Prioritization"
|
||||||
|
|
||||||
|
**Recipients**:
|
||||||
|
- All attendees
|
||||||
|
- Anyone mentioned in action items
|
||||||
|
- Anyone who requested notes
|
||||||
|
|
||||||
|
**Follow-Up**:
|
||||||
|
- Send reminder 3 days before action item due dates
|
||||||
|
- Weekly summary of all open action items
|
||||||
|
- Mark action items as complete and share updates
|
||||||
@@ -0,0 +1,144 @@
|
|||||||
|
---
|
||||||
|
name: prd-template
|
||||||
|
description: Product Requirements Document creation following proven PM template structure. Use when the user asks to create, write, draft, or help with a PRD, product requirements document, product spec, feature specification, or product documentation for a new feature or product.
|
||||||
|
---
|
||||||
|
|
||||||
|
# PRD Template Skill
|
||||||
|
|
||||||
|
This skill helps create professional Product Requirements Documents following industry best practices.
|
||||||
|
|
||||||
|
## Template Structure
|
||||||
|
|
||||||
|
Every PRD should include these sections in order:
|
||||||
|
|
||||||
|
### 1. Overview
|
||||||
|
- **Problem Statement**: What problem are we solving? (2-3 sentences)
|
||||||
|
- **Proposed Solution**: High-level description of what we're building (2-3 sentences)
|
||||||
|
- **Success Metrics**: How we'll measure success (3-5 key metrics)
|
||||||
|
|
||||||
|
### 2. Context & Background
|
||||||
|
- **Why Now**: Why is this the right time?
|
||||||
|
- **Strategic Alignment**: How does this align with company objectives?
|
||||||
|
- **User Research Summary**: Key insights from research (if applicable)
|
||||||
|
|
||||||
|
### 3. User Stories & Use Cases
|
||||||
|
Format: "As a [user type], I want to [action] so that [benefit]"
|
||||||
|
- Include 3-7 primary user stories
|
||||||
|
- Add acceptance criteria for each
|
||||||
|
|
||||||
|
### 4. Requirements
|
||||||
|
**Functional Requirements:**
|
||||||
|
- Must-have features (P0)
|
||||||
|
- Should-have features (P1)
|
||||||
|
- Nice-to-have features (P2)
|
||||||
|
|
||||||
|
**Non-Functional Requirements:**
|
||||||
|
- Performance expectations
|
||||||
|
- Security considerations
|
||||||
|
- Accessibility requirements
|
||||||
|
|
||||||
|
### 5. Design & User Experience
|
||||||
|
- Link to design mocks or wireframes
|
||||||
|
- Key user flows
|
||||||
|
- Edge cases and error states
|
||||||
|
|
||||||
|
### 6. Technical Considerations
|
||||||
|
- Architecture implications
|
||||||
|
- Dependencies on other systems
|
||||||
|
- Technical risks and mitigations
|
||||||
|
|
||||||
|
### 7. Implementation Plan
|
||||||
|
- **Phase 1 (MVP)**: What goes in first version
|
||||||
|
- **Phase 2**: What comes next
|
||||||
|
- **Phase 3**: Future enhancements
|
||||||
|
|
||||||
|
### 8. Open Questions
|
||||||
|
- Decisions that still need to be made
|
||||||
|
- Stakeholders to consult
|
||||||
|
- Research needed
|
||||||
|
|
||||||
|
### 9. Appendix
|
||||||
|
- Research links
|
||||||
|
- Related documents
|
||||||
|
- Competitive analysis
|
||||||
|
|
||||||
|
## Writing Guidelines
|
||||||
|
|
||||||
|
**Tone**: Clear, concise, actionable
|
||||||
|
**Audience**: Engineers, designers, stakeholders
|
||||||
|
**Length**: Aim for 3-6 pages for features, 8-12 for products
|
||||||
|
|
||||||
|
**Best Practices:**
|
||||||
|
- Use concrete examples over abstractions
|
||||||
|
- Include "why" not just "what"
|
||||||
|
- Make requirements testable
|
||||||
|
- Link to supporting materials
|
||||||
|
- Update as decisions are made
|
||||||
|
|
||||||
|
## What Makes a Good PRD
|
||||||
|
|
||||||
|
✅ **Do:**
|
||||||
|
- Write from the user's perspective
|
||||||
|
- Include specific success metrics
|
||||||
|
- Address edge cases
|
||||||
|
- Link to research and data
|
||||||
|
- Make trade-offs explicit
|
||||||
|
|
||||||
|
❌ **Don't:**
|
||||||
|
- Write implementation details (that's tech spec)
|
||||||
|
- Assume everyone has context
|
||||||
|
- Leave requirements ambiguous
|
||||||
|
- Skip the "why"
|
||||||
|
- Forget about accessibility
|
||||||
|
|
||||||
|
## Example PRD Opening
|
||||||
|
|
||||||
|
```
|
||||||
|
# PRD: Multi-Channel Customer Support Dashboard
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
**Problem Statement**: Support teams are currently managing customer inquiries across email, chat, and social media using three separate tools, leading to delayed responses, duplicated work, and inconsistent customer experiences. On average, support agents waste 2.3 hours per day switching between tools and manually tracking conversation history.
|
||||||
|
|
||||||
|
**Proposed Solution**: Build a unified dashboard that aggregates customer inquiries from all channels into a single interface, maintains conversation history across channels, and provides intelligent routing based on agent expertise and availability.
|
||||||
|
|
||||||
|
**Success Metrics**:
|
||||||
|
- Reduce average response time from 4 hours to 1 hour
|
||||||
|
- Decrease tool-switching time by 80% (from 2.3 to <0.5 hours)
|
||||||
|
- Improve customer satisfaction score from 3.8 to 4.5 (out of 5)
|
||||||
|
- Increase support agent productivity by 35%
|
||||||
|
|
||||||
|
## Context & Background
|
||||||
|
|
||||||
|
**Why Now**: Customer satisfaction has declined 15% over the past 6 months, primarily due to slow response times. Our top competitor launched a unified support dashboard last quarter, and we're hearing about it in sales calls. Support team turnover is at 45% annually, with "tool complexity" cited as a top frustration.
|
||||||
|
|
||||||
|
**Strategic Alignment**: This aligns with our Q1 company objective to "Improve customer retention by 10%" and our support team's OKR to "Reduce average handle time by 25%."
|
||||||
|
|
||||||
|
**User Research Summary**: We conducted interviews with 12 support agents and observed 20 hours of support sessions. Key findings:
|
||||||
|
- Agents spend 35% of their time finding context from previous interactions
|
||||||
|
- 65% of escalations are due to lack of conversation history
|
||||||
|
- Agents rated tool-switching as their #1 daily frustration (9.2/10 pain)
|
||||||
|
- Current NPS for support experience is -12
|
||||||
|
|
||||||
|
## User Stories & Use Cases
|
||||||
|
|
||||||
|
**US1: Unified Inbox**
|
||||||
|
As a support agent, I want to see all customer inquiries in one place so that I don't miss urgent requests and can prioritize effectively.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- Inbox shows inquiries from email, chat, and social media
|
||||||
|
- Inquiries are sorted by priority (urgent, high, normal, low)
|
||||||
|
- Agent can filter by channel, customer, or status
|
||||||
|
- Real-time updates when new inquiries arrive
|
||||||
|
|
||||||
|
**US2: Cross-Channel Context**
|
||||||
|
As a support agent, I want to see the full conversation history regardless of channel so that I can provide consistent, informed responses without asking customers to repeat themselves.
|
||||||
|
|
||||||
|
Acceptance Criteria:
|
||||||
|
- Timeline view shows all interactions chronologically
|
||||||
|
- Each interaction displays channel, timestamp, and content
|
||||||
|
- Customer profile shows demographics and account information
|
||||||
|
- Previous issues and resolutions are accessible
|
||||||
|
|
||||||
|
[Continue with 5-7 total user stories...]
|
||||||
|
```
|
||||||
@@ -0,0 +1,219 @@
|
|||||||
|
---
|
||||||
|
name: stakeholder-update
|
||||||
|
description: Create executive stakeholder updates following proven communication frameworks. Use when the user needs to create a status update, progress report, executive summary, or communication for leadership, stakeholders, or executives.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Stakeholder Update Skill
|
||||||
|
|
||||||
|
This skill creates effective status updates for executives and stakeholders following the BLUF (Bottom Line Up Front) principle.
|
||||||
|
|
||||||
|
## Update Structure
|
||||||
|
|
||||||
|
### 1. BLUF (Bottom Line Up Front)
|
||||||
|
Start with the most important information:
|
||||||
|
- **Status**: 🟢 On track / 🟡 At risk / 🔴 Blocked / ✅ Complete
|
||||||
|
- **Key Takeaway**: One sentence summary of current state
|
||||||
|
- **Action Needed**: What you need from stakeholders (if anything)
|
||||||
|
|
||||||
|
### 2. Progress Summary
|
||||||
|
Brief overview of accomplishments:
|
||||||
|
- What shipped this period
|
||||||
|
- Milestones achieved
|
||||||
|
- Key metrics movement
|
||||||
|
|
||||||
|
Keep to 3-5 bullet points maximum.
|
||||||
|
|
||||||
|
### 3. Metrics Dashboard
|
||||||
|
|
||||||
|
**Key Metrics**
|
||||||
|
| Metric | Current | Target | Trend | Status |
|
||||||
|
|--------|---------|--------|-------|--------|
|
||||||
|
| [Metric name] | [Value] | [Target] | ↑/→/↓ | 🟢/🟡/🔴 |
|
||||||
|
|
||||||
|
Include 3-5 most important metrics only.
|
||||||
|
|
||||||
|
### 4. Risks & Blockers
|
||||||
|
|
||||||
|
**High Priority Issues:**
|
||||||
|
- **Issue**: Brief description
|
||||||
|
- **Impact**: What's at stake
|
||||||
|
- **Mitigation**: What you're doing about it
|
||||||
|
- **Help Needed**: What stakeholders can do (if applicable)
|
||||||
|
|
||||||
|
Only include issues that matter at executive level.
|
||||||
|
|
||||||
|
### 5. Upcoming Milestones
|
||||||
|
|
||||||
|
**Next 30 Days:**
|
||||||
|
- Milestone (expected date)
|
||||||
|
- Milestone (expected date)
|
||||||
|
|
||||||
|
**Next 90 Days:**
|
||||||
|
- Major milestone (month)
|
||||||
|
- Major milestone (month)
|
||||||
|
|
||||||
|
### 6. Decisions Needed (if applicable)
|
||||||
|
- **Decision**: Clear description
|
||||||
|
- **Options**: 2-3 options with pros/cons
|
||||||
|
- **Recommendation**: What you recommend and why
|
||||||
|
- **Timeline**: When decision is needed
|
||||||
|
|
||||||
|
## Writing Guidelines
|
||||||
|
|
||||||
|
**Tone**: Professional, concise, action-oriented
|
||||||
|
**Length**: Keep under 1 page (or 2 minutes reading time)
|
||||||
|
**Frequency**: Weekly for active projects, bi-weekly for maintenance
|
||||||
|
|
||||||
|
**Executive Communication Principles:**
|
||||||
|
|
||||||
|
1. **Lead with conclusions, not process**
|
||||||
|
- ❌ "We ran 5 experiments this week and analyzed the data..."
|
||||||
|
- ✅ "Conversion rate increased 15% from optimization work"
|
||||||
|
|
||||||
|
2. **Focus on impact, not activities**
|
||||||
|
- ❌ "Held 12 customer interviews"
|
||||||
|
- ✅ "Identified #1 barrier to adoption (complexity of setup)"
|
||||||
|
|
||||||
|
3. **Make problems visible early**
|
||||||
|
- Don't sugarcoat risks
|
||||||
|
- Propose solutions, not just problems
|
||||||
|
- Be specific about help needed
|
||||||
|
|
||||||
|
4. **Use data to tell story**
|
||||||
|
- Quantify whenever possible
|
||||||
|
- Show trends, not just snapshots
|
||||||
|
- Connect metrics to business outcomes
|
||||||
|
|
||||||
|
5. **Make it scannable**
|
||||||
|
- Use headers and bullet points
|
||||||
|
- Bold key information
|
||||||
|
- Use visual indicators (🟢🟡🔴, ↑→↓)
|
||||||
|
|
||||||
|
## Status Guidelines
|
||||||
|
|
||||||
|
**🟢 On Track**: Meeting all targets, no significant risks
|
||||||
|
**🟡 At Risk**: Potential issues that could impact delivery
|
||||||
|
**🔴 Blocked**: Critical issues preventing progress, needs intervention
|
||||||
|
|
||||||
|
## Example Update
|
||||||
|
|
||||||
|
```
|
||||||
|
# Product Update: Customer Onboarding Redesign
|
||||||
|
**Week of Jan 20, 2026**
|
||||||
|
|
||||||
|
## BLUF
|
||||||
|
**Status**: 🟡 At Risk
|
||||||
|
**Key Takeaway**: New onboarding flow is performing well in tests (+35% completion), but launch delayed one week due to integration issues with billing system.
|
||||||
|
**Action Needed**: Decision needed on whether to launch onboarding separately or wait for billing integration fix.
|
||||||
|
|
||||||
|
## Progress Summary
|
||||||
|
- Completed user testing with 24 participants (94% positive feedback)
|
||||||
|
- Implemented first-time user experience improvements
|
||||||
|
- Resolved 12 of 15 bugs identified in QA
|
||||||
|
- Engineering allocated resources to billing integration fix
|
||||||
|
|
||||||
|
## Key Metrics
|
||||||
|
| Metric | Current | Target | Trend | Status |
|
||||||
|
|--------|---------|--------|-------|--------|
|
||||||
|
| Onboarding Completion | 45% | 60% | → | 🟡 |
|
||||||
|
| Time to First Value | 4.2 min | 3.0 min | ↓ | 🟢 |
|
||||||
|
| Setup Support Tickets | 45/week | <30/week | ↓ | 🟢 |
|
||||||
|
| User Activation Rate | 52% | 65% | → | 🟡 |
|
||||||
|
|
||||||
|
## Risks & Blockers
|
||||||
|
|
||||||
|
**HIGH: Billing System Integration Delay**
|
||||||
|
- **Impact**: Prevents users from completing onboarding flow; delays launch by 1-2 weeks
|
||||||
|
- **Root Cause**: API deprecation by payment processor, requires code rewrite
|
||||||
|
- **Mitigation**: Engineering team reallocated resources, fix ETA Feb 3
|
||||||
|
- **Decision Needed**: Launch onboarding without payment integration or wait for fix? (See below)
|
||||||
|
|
||||||
|
**MEDIUM: Mobile Testing Coverage**
|
||||||
|
- **Impact**: Some edge cases on older Android devices not tested
|
||||||
|
- **Mitigation**: Partnering with QA to expand test matrix; running beta with internal users on diverse devices
|
||||||
|
|
||||||
|
## Upcoming Milestones
|
||||||
|
|
||||||
|
**Next 30 Days:**
|
||||||
|
- Resolve billing integration (Feb 3)
|
||||||
|
- Launch onboarding redesign (Feb 5 or Feb 12 depending on decision)
|
||||||
|
- Begin measuring impact on conversion (Feb 12)
|
||||||
|
|
||||||
|
**Next 90 Days:**
|
||||||
|
- Iterate based on production data (March)
|
||||||
|
- Extend to mobile app (April)
|
||||||
|
- Launch advanced features (May)
|
||||||
|
|
||||||
|
## Decision Needed
|
||||||
|
|
||||||
|
**Should we launch onboarding separately from billing integration?**
|
||||||
|
|
||||||
|
**Option A: Launch Now (Recommended)**
|
||||||
|
- Pros: Get 35% completion rate improvement to users immediately, gather production data, maintain momentum
|
||||||
|
- Cons: Users need to complete payment in old flow, slightly disjointed experience
|
||||||
|
- Timeline: Launch Feb 5
|
||||||
|
|
||||||
|
**Option B: Wait for Billing Fix**
|
||||||
|
- Pros: Fully integrated experience from day one, no technical debt
|
||||||
|
- Cons: Delays benefits by 2 weeks, Q1 metric targets at risk, team momentum lost
|
||||||
|
- Timeline: Launch Feb 12
|
||||||
|
|
||||||
|
**Recommendation**: Option A. The onboarding improvements are valuable independently, and the old payment flow works fine. Waiting risks missing Q1 targets and delays validated improvements from reaching users.
|
||||||
|
|
||||||
|
**Timeline**: Need decision by Jan 22 for Feb 5 launch.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Questions?** Reply to this email or ping me on Slack.
|
||||||
|
```
|
||||||
|
|
||||||
|
## Frequency Guidance
|
||||||
|
|
||||||
|
**Daily standups**:
|
||||||
|
- Ultra-brief (3 bullets)
|
||||||
|
- What shipped yesterday
|
||||||
|
- What's shipping today
|
||||||
|
- Blockers
|
||||||
|
|
||||||
|
**Weekly updates**:
|
||||||
|
- Use full template above
|
||||||
|
- Focus on progress and risks
|
||||||
|
- Keep to 1 page
|
||||||
|
|
||||||
|
**Monthly reviews**:
|
||||||
|
- Deeper metrics analysis
|
||||||
|
- Strategic reflections
|
||||||
|
- Quarterly goal progress
|
||||||
|
- Longer format (2-3 pages) acceptable
|
||||||
|
|
||||||
|
**Quarterly business reviews**:
|
||||||
|
- Comprehensive analysis
|
||||||
|
- Trends over time
|
||||||
|
- Strategic recommendations
|
||||||
|
- Presentation format
|
||||||
|
|
||||||
|
## Adaptation by Audience
|
||||||
|
|
||||||
|
### For C-Suite
|
||||||
|
- Lead with business impact
|
||||||
|
- Connect to company OKRs
|
||||||
|
- Focus on strategy and outcomes
|
||||||
|
- Minimize technical details
|
||||||
|
|
||||||
|
### For Product/Engineering Leadership
|
||||||
|
- Include technical context
|
||||||
|
- Show sprint/milestone progress
|
||||||
|
- Discuss architecture implications
|
||||||
|
- Reference technical debt
|
||||||
|
|
||||||
|
### For Cross-Functional Teams
|
||||||
|
- Balance technical and business context
|
||||||
|
- Highlight dependencies
|
||||||
|
- Call out collaboration needs
|
||||||
|
- Make asks explicit
|
||||||
|
|
||||||
|
### For Board/Investors
|
||||||
|
- Focus on metrics and traction
|
||||||
|
- Competitive positioning
|
||||||
|
- Market opportunities
|
||||||
|
- Financial implications
|
||||||
@@ -0,0 +1,229 @@
|
|||||||
|
---
|
||||||
|
name: user-research-synthesis
|
||||||
|
description: Analyze and synthesize user research findings following PM best practices. Use when the user provides user research data, interview transcripts, survey results, or user feedback that needs to be analyzed, synthesized, or summarized into insights and recommendations.
|
||||||
|
---
|
||||||
|
|
||||||
|
# User Research Synthesis Skill
|
||||||
|
|
||||||
|
This skill helps analyze user research data and transform it into actionable insights following a structured methodology.
|
||||||
|
|
||||||
|
## Synthesis Framework
|
||||||
|
|
||||||
|
### 1. Data Collection Overview
|
||||||
|
- **Research Type**: Interviews, surveys, usability tests, etc.
|
||||||
|
- **Participant Profile**: Demographics, segments, sample size
|
||||||
|
- **Research Questions**: What we sought to learn
|
||||||
|
- **Methodology**: How data was collected
|
||||||
|
|
||||||
|
### 2. Key Themes Identification
|
||||||
|
|
||||||
|
Organize findings into themes using this structure:
|
||||||
|
|
||||||
|
**Theme Name**
|
||||||
|
- **Description**: What this theme represents
|
||||||
|
- **Prevalence**: How many participants mentioned this (e.g., "8 out of 12 participants")
|
||||||
|
- **Supporting Quotes**: 2-3 representative quotes
|
||||||
|
- **Implication**: What this means for our product
|
||||||
|
|
||||||
|
Aim for 4-8 major themes per research effort.
|
||||||
|
|
||||||
|
### 3. Pain Points Analysis
|
||||||
|
|
||||||
|
For each identified pain point:
|
||||||
|
- **Pain Point**: Clear description
|
||||||
|
- **Severity**: High/Medium/Low (based on impact and frequency)
|
||||||
|
- **Current Workaround**: How users deal with it today
|
||||||
|
- **Evidence**: Specific examples from research
|
||||||
|
|
||||||
|
### 4. Feature Requests
|
||||||
|
|
||||||
|
Categorize requests:
|
||||||
|
- **Must-Have**: Critical needs blocking user success
|
||||||
|
- **High Value**: Would significantly improve experience
|
||||||
|
- **Nice-to-Have**: Incremental improvements
|
||||||
|
|
||||||
|
For each request:
|
||||||
|
- **Request**: What users asked for
|
||||||
|
- **Frequency**: How often it came up
|
||||||
|
- **User Quote**: Representative example
|
||||||
|
- **Underlying Need**: Why they want this (dig deeper than surface request)
|
||||||
|
|
||||||
|
### 5. User Workflow Insights
|
||||||
|
|
||||||
|
Document actual workflows observed:
|
||||||
|
- **Current State**: How users accomplish tasks today
|
||||||
|
- **Pain Points**: Where they struggle
|
||||||
|
- **Ideal State**: What they wish they could do
|
||||||
|
- **Opportunities**: Where we can add value
|
||||||
|
|
||||||
|
### 6. Segmentation Insights
|
||||||
|
|
||||||
|
If research reveals distinct user segments:
|
||||||
|
- **Segment Name**: Descriptive label
|
||||||
|
- **Characteristics**: What defines this segment
|
||||||
|
- **Unique Needs**: How their needs differ
|
||||||
|
- **Size/Importance**: Relative weight for prioritization
|
||||||
|
|
||||||
|
### 7. Competitive Insights
|
||||||
|
|
||||||
|
If users mentioned competitors or alternatives:
|
||||||
|
- **Competitor/Alternative**: What they use
|
||||||
|
- **Why They Use It**: What it does well
|
||||||
|
- **Gaps**: What it doesn't do
|
||||||
|
- **Switching Barriers**: Why they don't switch fully
|
||||||
|
|
||||||
|
### 8. Recommendations
|
||||||
|
|
||||||
|
Prioritized recommendations based on insights:
|
||||||
|
|
||||||
|
**High Priority**
|
||||||
|
- Recommendation with supporting evidence
|
||||||
|
- Expected impact
|
||||||
|
|
||||||
|
**Medium Priority**
|
||||||
|
- Recommendation with supporting evidence
|
||||||
|
- Expected impact
|
||||||
|
|
||||||
|
**Low Priority / Future Consideration**
|
||||||
|
- Recommendation with supporting evidence
|
||||||
|
- Expected impact
|
||||||
|
|
||||||
|
### 9. Open Questions
|
||||||
|
|
||||||
|
Research gaps identified:
|
||||||
|
- What we still need to understand
|
||||||
|
- Suggested follow-up research
|
||||||
|
- Uncertainties requiring validation
|
||||||
|
|
||||||
|
## Analysis Guidelines
|
||||||
|
|
||||||
|
**When synthesizing interviews:**
|
||||||
|
- Look for patterns across multiple participants
|
||||||
|
- Note both what users say AND what they do
|
||||||
|
- Pay attention to emotional reactions
|
||||||
|
- Identify jobs-to-be-done, not just feature requests
|
||||||
|
|
||||||
|
**When analyzing quotes:**
|
||||||
|
- Use verbatim quotes in "quotation marks"
|
||||||
|
- Attribute quotes: [Participant ID, Role, Context]
|
||||||
|
- Select quotes that illustrate patterns, not outliers
|
||||||
|
- Include both positive and negative feedback
|
||||||
|
|
||||||
|
**When identifying themes:**
|
||||||
|
- Use descriptive names, not generic labels
|
||||||
|
- Provide evidence for each theme
|
||||||
|
- Quantify when possible ("7 out of 10 users...")
|
||||||
|
- Connect themes to business objectives
|
||||||
|
|
||||||
|
## Quality Standards
|
||||||
|
|
||||||
|
✅ **Good Synthesis:**
|
||||||
|
- Identifies patterns, not just individual responses
|
||||||
|
- Connects insights to product decisions
|
||||||
|
- Includes supporting evidence for each claim
|
||||||
|
- Separates observations from interpretations
|
||||||
|
- Prioritizes findings by impact
|
||||||
|
|
||||||
|
❌ **Poor Synthesis:**
|
||||||
|
- Lists every individual comment
|
||||||
|
- Lacks evidence or examples
|
||||||
|
- Makes unsupported leaps
|
||||||
|
- Focuses on solutions before understanding problems
|
||||||
|
- Ignores contradictory data
|
||||||
|
|
||||||
|
## Example Theme
|
||||||
|
|
||||||
|
```
|
||||||
|
**Theme: Information Overload During Onboarding**
|
||||||
|
|
||||||
|
**Description**: Users consistently expressed feeling overwhelmed by the amount of information presented during initial setup, leading to incomplete onboarding and delayed time-to-value.
|
||||||
|
|
||||||
|
**Prevalence**: 9 out of 12 participants mentioned this issue unprompted
|
||||||
|
|
||||||
|
**Supporting Quotes**:
|
||||||
|
- "I just wanted to get started, but it felt like I needed to read a manual first" [P3, Marketing Manager]
|
||||||
|
- "By the third screen of instructions, I started clicking 'Next' without reading" [P7, Sales Rep]
|
||||||
|
- "I wish there was a 'quick start' option for people like me who just want to try it" [P11, Product Designer]
|
||||||
|
|
||||||
|
**Implication**: Our current onboarding flow prioritizes completeness over engagement. We should consider a progressive disclosure approach where users can start using the product quickly and learn advanced features contextually.
|
||||||
|
|
||||||
|
**Recommended Action**:
|
||||||
|
- Design a "Quick Start" path that gets users to first value in <3 minutes
|
||||||
|
- Move advanced configuration to contextual help within the app
|
||||||
|
- Test with 5-10 new users before full rollout
|
||||||
|
- Expected impact: +20-30% activation rate improvement
|
||||||
|
```
|
||||||
|
|
||||||
|
## Template Output Structure
|
||||||
|
|
||||||
|
When synthesizing research, use this structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# User Research Synthesis: [Research Topic]
|
||||||
|
|
||||||
|
## Research Overview
|
||||||
|
- **Date**: [Date range]
|
||||||
|
- **Methodology**: [Interview/Survey/Testing]
|
||||||
|
- **Participants**: [Number] [User types]
|
||||||
|
- **Research Questions**:
|
||||||
|
1. [Question 1]
|
||||||
|
2. [Question 2]
|
||||||
|
3. [Question 3]
|
||||||
|
|
||||||
|
## Executive Summary
|
||||||
|
[2-3 sentence overview of key findings and implications]
|
||||||
|
|
||||||
|
## Key Themes
|
||||||
|
|
||||||
|
### Theme 1: [Theme Name]
|
||||||
|
[Full theme documentation as shown in example above]
|
||||||
|
|
||||||
|
### Theme 2: [Theme Name]
|
||||||
|
[Full theme documentation]
|
||||||
|
|
||||||
|
[Continue with 4-8 themes]
|
||||||
|
|
||||||
|
## Pain Points Summary
|
||||||
|
|
||||||
|
| Pain Point | Severity | Frequency | Current Workaround |
|
||||||
|
|------------|----------|-----------|-------------------|
|
||||||
|
| [Pain 1] | High | 10/12 users | [How they cope] |
|
||||||
|
| [Pain 2] | Medium | 7/12 users | [How they cope] |
|
||||||
|
|
||||||
|
## Feature Requests
|
||||||
|
|
||||||
|
### Must-Have
|
||||||
|
1. **[Request]** - Mentioned by [X] participants
|
||||||
|
- Quote: "[Representative quote]"
|
||||||
|
- Underlying need: [Why they want this]
|
||||||
|
|
||||||
|
### High Value
|
||||||
|
[Similar structure]
|
||||||
|
|
||||||
|
### Nice-to-Have
|
||||||
|
[Similar structure]
|
||||||
|
|
||||||
|
## Recommendations
|
||||||
|
|
||||||
|
### High Priority (0-3 months)
|
||||||
|
1. **[Recommendation]**
|
||||||
|
- Supporting evidence: [Data from research]
|
||||||
|
- Expected impact: [What will improve]
|
||||||
|
- Effort estimate: [Rough sizing]
|
||||||
|
|
||||||
|
### Medium Priority (3-6 months)
|
||||||
|
[Similar structure]
|
||||||
|
|
||||||
|
### Future Consideration (6+ months)
|
||||||
|
[Similar structure]
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
1. [Question requiring more research]
|
||||||
|
2. [Uncertainty to validate]
|
||||||
|
3. [Follow-up study needed]
|
||||||
|
|
||||||
|
## Appendix
|
||||||
|
- Interview guide used
|
||||||
|
- Full participant demographics
|
||||||
|
- Raw notes/transcripts (link)
|
||||||
|
```
|
||||||
Reference in New Issue
Block a user