Product Manager Toolkit

A comprehensive Claude Code skill providing essential frameworks and tools for modern product management. Covers the full product lifecycle from discovery and prioritization through delivery and iteration, with ready-to-use templates for RICE scoring, user story mapping, roadmap planning, and stakeholder communication.

When to Use This Skill

Choose Product Manager Toolkit when:

• You need to prioritize a backlog of features using structured frameworks
• You're building a product roadmap and need to communicate it to stakeholders
• You want to write better user stories, PRDs, or product specs
• You need frameworks for making product decisions with incomplete data
• You're running discovery sessions and need structured interview guides

Consider alternatives when:

• You need GTM strategy and positioning (use a marketing strategy skill)
• You want engineering-specific project management (use an agile engineering skill)
• You need UX research methodology (use a UX research skill)

Quick Start

Copy
# Install the skill
claude install product-manager-toolkit-kit

# Prioritize features with RICE
claude "Score these 5 features using RICE: user dashboards, API v2, mobile app, SSO, dark mode. We have 10K users and 3 engineers."

# Write a PRD
claude "Write a PRD for adding team collaboration features to our project management tool"

# Build a roadmap
claude "Create a quarterly roadmap for our developer tools platform. Key themes: developer experience, enterprise readiness, and performance."

Core Concepts

Prioritization Frameworks

Framework	Best For	Dimensions
RICE	Balanced scoring with reach data	Reach, Impact, Confidence, Effort
ICE	Quick scoring without reach data	Impact, Confidence, Ease
MoSCoW	Release scoping and stakeholder alignment	Must, Should, Could, Won't
Kano	Understanding feature satisfaction curves	Basic, Performance, Delight
Value vs. Effort	Visual quadrant prioritization	2x2 matrix of value and effort

Product Discovery Process

1. Problem Discovery
   → Customer interviews (5-10 per segment)
   → Support ticket analysis
   → Usage data patterns

2. Solution Ideation
   → Design sprints
   → Competitive analysis
   → Technical feasibility assessment

3. Validation
   → Prototype testing
   → Fake door tests
   → Concierge MVP

4. Specification
   → PRD with success metrics
   → User stories with acceptance criteria
   → Technical design review

5. Delivery & Learn
   → Sprint planning and execution
   → Feature flagged rollout
   → Metrics review and iteration

PRD Template Structure

Section	Content	Purpose
Problem Statement	What problem are we solving and for whom?	Align team on the "why"
Success Metrics	How will we measure success?	Define done
User Stories	As a [user], I want to [action] so that [outcome]	Scope the feature
Requirements	Functional and non-functional specs	Guide engineering
Edge Cases	What happens in unusual scenarios?	Prevent rework
Timeline	Milestones and dependencies	Set expectations

Configuration

Parameter	Type	Default	Description
framework	string	"rice"	Default prioritization framework
team_size	number	5	Engineering team size for effort estimates
sprint_length	number	14	Sprint duration in days
output_format	string	"markdown"	Output: markdown, csv, json
detail_level	string	"standard"	Detail: brief, standard, comprehensive

Best Practices

1. Start with the problem, not the solution — Every PRD should lead with a clear problem statement validated by customer evidence. If you can't articulate the problem in one sentence, you're not ready to build a solution.

2. Use RICE for backlog prioritization — RICE reduces bias by forcing you to estimate reach and confidence. A feature with high impact but low confidence (0.5) scores lower than one with medium impact and high confidence (1.0), which appropriately reflects risk.

3. Define success metrics before building — Write down what success looks like in measurable terms. "Increase activation rate from 23% to 35% within 60 days of launch" is a good metric. "Users like the feature" is not.

4. Involve engineering in discovery — Engineers often identify solutions you'd never consider and can flag feasibility issues before you write a detailed spec. Include them in customer interviews when possible.

5. Communicate decisions, not just plans — Stakeholders care more about why something is prioritized than what's on the roadmap. Explain the reasoning behind trade-offs to build trust and reduce pushback.

Common Issues

Stakeholders override prioritization — Use RICE scores to depersonalize decisions. When a VP insists on a feature, run it through the framework together. Often the data reveals it should be prioritized — or clearly shows why it shouldn't.

PRDs are too long and nobody reads them — Keep PRDs to 2-3 pages. Lead with a one-paragraph summary. Use bullet points and tables. Link to detailed research rather than embedding it. If engineering needs more detail, add it to user stories.

Roadmap commitments create pressure — Use "Now / Next / Later" framing instead of specific dates for items beyond the current sprint. This communicates priority and sequence without creating false precision about timing.