# product-documentation

> Comprehensive product documentation creation including PRDs, user stories, roadmaps, stakeholder updates, and backlog management. Use when writing any product specification, requirements document, user story, product roadmap, status update, or managing product backlogs. Combines templates for all core product documentation needs with consistent formatting and best practices.

- Author: Nir
- Repository: Nirkoso/Nir-Claude
- Version: 20260126102449
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/Nirkoso/Nir-Claude
- Web: https://mule.run/skillshub/@@Nirkoso/Nir-Claude~product-documentation:20260126102449

---

---
name: product-documentation
description: Comprehensive product documentation creation including PRDs, user stories, roadmaps, stakeholder updates, and backlog management. Use when writing any product specification, requirements document, user story, product roadmap, status update, or managing product backlogs. Combines templates for all core product documentation needs with consistent formatting and best practices.
---

# Product Documentation

Create all types of product documentation with consistent templates and quality standards.

## Documentation Types Supported

### Product Requirements Documents (PRDs)
- Problem statement and background
- User personas and use cases
- Functional and non-functional requirements
- Success metrics and acceptance criteria
- Technical considerations and constraints
- Dependencies and risks

### User Stories
- User story format: "As a [persona], I want [action] so that [benefit]"
- Acceptance criteria (Given-When-Then format)
- Story points estimation guidance
- Definition of done checklist
- Priority and dependencies

### Product Roadmaps
- Now-Next-Later format or quarterly planning
- Theme-based organization
- Feature prioritization rationale
- Dependencies and milestones
- Resource allocation considerations

### Stakeholder Communication
- Status updates (Progress, Plans, Problems - 3Ps format)
- Decision documents (DACI framework)
- Launch announcements
- Feature change notifications
- Weekly/monthly reports

### Backlog Management
- Epic breakdown structure
- Story refinement templates
- Backlog prioritization criteria
- Sprint planning documentation
- Release notes

## Instructions

### For PRDs

1. Start with problem definition and context
2. Define target users with specific personas
3. List functional requirements clearly numbered
4. Include acceptance criteria for each requirement
5. Define success metrics (quantitative and qualitative)
6. Document technical constraints and assumptions
7. Identify risks and mitigation strategies
8. Add appendices for mockups, research, competitive analysis

**PRD Template Structure:**
```
# [Feature Name] PRD

## 1. Problem Statement
[What problem are we solving?]

## 2. Background & Context
[Why now? What's the strategic importance?]

## 3. Target Users
[Who is this for? Include personas]

## 4. Goals & Success Metrics
[What does success look like?]

## 5. Functional Requirements
[Numbered list of what the feature must do]

## 6. Non-Functional Requirements
[Performance, security, scalability needs]

## 7. User Flow
[Step-by-step user journey]

## 8. Acceptance Criteria
[How we'll know it's done correctly]

## 9. Dependencies & Risks
[What might block us or go wrong?]

## 10. Open Questions
[What needs to be decided?]
```

### For User Stories

1. Write in standard format: "As a [persona], I want [action] so that [benefit]"
2. Keep stories small and achievable in one sprint
3. Include 3-5 acceptance criteria using Given-When-Then format
4. Add technical notes if implementation complexity exists
5. Tag with priority (P0, P1, P2) and estimate story points

**User Story Template:**
```
Title: [Concise action description]

As a [specific user persona]
I want [specific action/capability]
So that [clear benefit/outcome]

Acceptance Criteria:
1. Given [context], when [action], then [expected result]
2. Given [context], when [action], then [expected result]
3. Given [context], when [action], then [expected result]

Technical Notes:
[Any implementation considerations]

Priority: [P0/P1/P2]
Story Points: [1, 2, 3, 5, 8, 13]
Dependencies: [Related stories or prerequisites]
```

### For Roadmaps

1. Organize by timeframe (Now/Next/Later or Q1/Q2/Q3/Q4)
2. Group features by theme or strategic initiative
3. Include confidence levels for future items
4. Show dependencies between items
5. Align with company OKRs or strategic goals

**Roadmap Format:**
```
# Product Roadmap - [Time Period]

## Strategic Themes
1. [Theme 1] - [Description]
2. [Theme 2] - [Description]

## Now (Current Quarter)
- ✓ [Feature] - [Status] - [Theme]
- → [Feature] - [Status] - [Theme]

## Next (Next Quarter)
- [Feature] - High confidence - [Theme]
- [Feature] - Medium confidence - [Theme]

## Later (Future)
- [Feature] - Exploratory - [Theme]
- [Feature] - Under research - [Theme]

## Dependencies Map
[Feature A] → [Feature B] → [Feature C]
```

### For Stakeholder Updates

1. Use 3Ps format: Progress, Plans, Problems
2. Be concise - one page maximum
3. Highlight key metrics and decisions needed
4. Include action items with owners and dates
5. Link to detailed docs for deep dives

**Update Template:**
```
# [Project/Feature] Update - [Date]

## Progress (What we accomplished)
- [Achievement 1] - [Impact]
- [Achievement 2] - [Impact]

## Plans (What's next)
- [Next milestone 1] - [Date]
- [Next milestone 2] - [Date]

## Problems (What needs attention)
- [Issue 1] - [Severity] - [Owner]
- [Issue 2] - [Severity] - [Owner]

## Key Metrics
- [Metric 1]: [Value] ([Change from last period])
- [Metric 2]: [Value] ([Change from last period])

## Decisions Needed
- [Decision 1] - By [Date] - [Stakeholder]

## Action Items
- [ ] [Action] - [Owner] - [Due Date]
```

## Quality Standards

- **Clarity**: Use simple language, avoid jargon unless necessary
- **Completeness**: Include all sections relevant to the document type
- **Consistency**: Follow the same format across similar documents
- **Actionability**: Every document should drive clear next steps
- **Traceability**: Link to related docs, research, and decisions

## Best Practices

1. **Start with Why**: Always explain the problem before the solution
2. **Be Specific**: Use numbers, dates, and concrete examples
3. **Show Trade-offs**: Acknowledge what you're NOT doing and why
4. **Include Visuals**: Diagrams, mockups, or flow charts where helpful
5. **Version Control**: Note document version and last updated date
6. **Get Feedback**: Share drafts early and iterate based on input
7. **Keep Updated**: Living documents should reflect current state