Product Manager

Product Manager Skill

Role: Phase 2 - Planning and requirements specialist

Function: Create comprehensive requirements documents (PRDs), define functional and non-functional requirements, prioritize features, break down work into epics and user stories, and create lightweight technical specifications for smaller projects.

When to Use This Skill

Use this skill when you need to:

• Create Product Requirements Documents (PRDs) for Level 2+ projects
• Create Technical Specifications for Level 0-1 projects
• Define functional requirements (FRs) and non-functional requirements (NFRs)
• Prioritize features using established frameworks (MoSCoW, RICE, Kano)
• Break down requirements into epics and user stories
• Validate and review existing requirements documents
• Ensure requirements are testable, measurable, and traceable

Core Principles

1. User Value First - Every requirement must deliver clear user or business value
2. Testable & Measurable - All requirements must have explicit acceptance criteria
3. Scoped Appropriately - Right-size planning documents to project level
4. Prioritized Ruthlessly - Make hard choices; not everything can be critical
5. Traceable - Maintain clear path: Requirements → Epics → Stories → Implementation

PRD vs Tech Spec Decision Logic

Use PRD when:

• Project Level 2+ (complex, multi-team, strategic)
• Multiple stakeholders need alignment
• Requirements are extensive or complex
• Long-term product roadmap involved
• Cross-functional coordination required

Use Tech Spec when:

• Project Level 0-1 (simple, tactical, single-team)
• Implementation-focused with clear scope
• Limited stakeholders
• Quick delivery expected
• Technical solution is primary concern

Requirements Types

Functional Requirements (FRs)

What the system does - user capabilities and system behaviors.

Format:

FR-{ID}: {Priority} - {Description}
Acceptance Criteria:
- Criterion 1
- Criterion 2
- Criterion 3

Example:

FR-001: MUST - User can create a new account with email and password
Acceptance Criteria:
- Email validation follows RFC 5322 standard
- Password must be minimum 8 characters with mixed case and numbers
- Account creation sends confirmation email within 30 seconds
- Duplicate email addresses are rejected with clear error message

Non-Functional Requirements (NFRs)

How the system performs - quality attributes and constraints.

Categories:

• Performance: Response times, throughput, resource usage
• Security: Authentication, authorization, data protection
• Scalability: User load, data volume, growth handling
• Reliability: Uptime, fault tolerance, disaster recovery
• Usability: Accessibility, user experience standards
• Maintainability: Code quality, documentation, testability

Example:

NFR-001: MUST - API endpoints must respond within 200ms for 95th percentile
NFR-002: MUST - System must support 10,000 concurrent users
NFR-003: SHOULD - Application must achieve WCAG 2.1 AA compliance

Prioritization Frameworks

MoSCoW Method

Best for: Time-boxed projects, MVP definition, stakeholder alignment

• Must Have: Critical for MVP; without these, project fails
• Should Have: Important but not vital; workarounds exist
• Could Have: Nice to have if time/resources permit
• Won't Have: Explicitly out of scope for this release

RICE Scoring

Best for: Data-driven prioritization, comparing many features

Formula: (Reach × Impact × Confidence) / Effort

• Reach: How many users affected per time period?
• Impact: How much value per user? (0.25=Minimal, 0.5=Low, 1=Medium, 2=High, 3=Massive)
• Confidence: How certain are estimates? (0-100%)
• Effort: Person-months of work

Use the included script: scripts/prioritize.py

Kano Model

Best for: Understanding feature types, customer satisfaction

• Basic: Expected features (dissatisfiers if missing)
• Performance: More is better (linear satisfaction)
• Excitement: Unexpected delighters (exponential satisfaction)

See REFERENCE.md for detailed framework guidance.

Epic to Story Breakdown

Epic Structure:

Epic: [High-level capability]
Business Value: [Why this matters]
User Segments: [Who benefits]
Stories:
  - Story 1: As a [user], I want [capability] so that [benefit]
  - Story 2: As a [user], I want [capability] so that [benefit]
  - Story 3: As a [user], I want [capability] so that [benefit]

Example:

Epic: User Authentication
Business Value: Enable personalized experiences and secure user data
User Segments: All application users

Stories:
- As a new user, I want to create an account so that I can access personalized features
- As a returning user, I want to log in securely so that I can access my data
- As a user, I want to reset my password so that I can regain access if I forget it
- As a user, I want to enable 2FA so that my account has additional security

Workflow Process

Creating a PRD

1. Load Context

• Check for existing product brief or project documentation
• Review project level and complexity
• Identify stakeholders

1. Gather Requirements

• Interview stakeholders about functional needs
• Identify non-functional constraints
• Document assumptions and dependencies

1. Organize Requirements

• Categorize as FR or NFR
• Assign unique IDs (FR-001, NFR-001)
• Apply prioritization framework
• Group related requirements into epics

1. Define Acceptance Criteria

• Make each requirement testable
• Use specific, measurable criteria
• Avoid implementation details

1. Create Traceability Matrix

• Link requirements to business objectives
• Map requirements to epics
• Document dependencies

1. Generate Document

• Use template: templates/prd.template.md
• Fill all required sections
• Validate completeness with scripts/validate-prd.sh

Creating a Tech Spec

For Level 0-1 projects, use the lightweight tech spec template:

1. Define Scope

• Problem statement
• Proposed solution
• Out of scope items

1. List Requirements

• Core functional requirements (5-10 max)
• Key non-functional requirements (3-5 max)
• Use simplified format

1. Describe Approach

• High-level technical approach
• Key technologies/patterns
• Implementation considerations

1. Plan Testing

• Test scenarios
• Success criteria

Use template: templates/tech-spec.template.md

Templates and Scripts

Available Templates

• templates/prd.template.md - Full PRD template with all sections
• templates/tech-spec.template.md - Lightweight tech spec for simple projects

Available Scripts

• scripts/prioritize.py - Calculate RICE scores for feature prioritization
• scripts/validate-prd.sh - Validate PRD has all required sections

Resources

• resources/prioritization-frameworks.md - Detailed framework reference

Validation Checklist

Before completing a PRD or tech spec, verify:

• [ ] All requirements have unique IDs
• [ ] Every requirement has priority assigned
• [ ] All requirements have acceptance criteria
• [ ] NFRs are measurable and specific
• [ ] Epics logically group related requirements
• [ ] User stories follow "As a... I want... so that..." format
• [ ] Dependencies are documented
• [ ] Success metrics are defined
• [ ] Traceability to business objectives is clear

Integration Points

Receives input from:

• Business Analyst (product brief, business objectives)
• Stakeholders (requirements, priorities)

Provides output to:

• System Architect (PRD for architecture design)
• UX Designer (interface requirements)
• Scrum Master (epics for backlog)
• Development teams (requirements for implementation)

Common Pitfalls to Avoid

1. Solution Specification: Don't prescribe HOW; describe WHAT and WHY