Product Requirements Document (PRD)

Quick facts

Phase: Deliver | Version: 2.1.0 | Category: specification | License: Apache-2.0

Try it: /pm-skills:deliver-prd "Your context here"

A Product Requirements Document is the primary specification artifact that communicates what to build and why. It bridges the gap between problem understanding and engineering implementation by providing clear requirements, success criteria, and scope boundaries. A good PRD enables engineering to build the right thing while maintaining flexibility on implementation details.

When to Use

• After problem and solution alignment, before engineering work begins
• When specifying features, epics, or product initiatives for handoff
• When multiple teams need to coordinate on a shared deliverable
• When stakeholders need to approve scope before investment
• As reference documentation during development and QA

When NOT to Use

• The problem is still unframed or contested -> use define-problem-statement first; a PRD assumes an agreed problem
• You need a one-page pitch to align stakeholders on an approach -> use develop-solution-brief; the PRD comes after that alignment
• You only need the work broken into tickets for a sprint -> use deliver-user-stories
• You are recording a technical or architectural decision -> use develop-adr

How to Use

Invoke the skill by name (/pm-skills:deliver-prd on Claude Code, $deliver-prd on Codex):

/pm-skills:deliver-prd "Your context here"

Or reference the skill file directly: skills/deliver-prd/SKILL.md

Instructions

When asked to create a PRD, follow these steps:

1. Summarize the Problem Start with a brief recap of the problem being solved. Link to the problem statement if available. Ensure readers understand why this work matters before diving into what to build.

2. Define Goals and Success Metrics Articulate what success looks like. Include specific, measurable metrics with baselines and targets. These metrics should connect directly to the problem being solved.

3. Outline the Solution Describe the proposed solution at a high level. Focus on user-facing functionality and key capabilities. Include enough detail for stakeholders to evaluate the approach without over-specifying implementation.

4. Detail Functional Requirements Break down what the system must do. Use user stories or requirement statements. Each requirement should be testable - someone should be able to verify if it’s met.

5. Define Scope Boundaries Explicitly state what’s in scope, out of scope, and deferred to future iterations. Clear scope prevents scope creep and sets realistic expectations.

6. Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don’t design the system, but surface considerations engineering needs to know.

7. Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.

8. Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.

Output Format

Use the template in references/TEMPLATE.md to structure the output. A complete PRD fills every template section: Overview; Goals & Success Metrics; User Stories; Scope; Solution Design; Technical Considerations; Dependencies & Risks; Timeline & Milestones; Open Questions; and the Appendix when supporting material exists.

Examples

See references/EXAMPLE.md for a completed example.

Output Template

PRD: [Feature/Initiative Name]

Overview

Problem Statement

[Problem summary]

Solution Summary

[Solution summary]

Target Users

[Target user description]

Goals & Success Metrics

Goals

1. [Primary goal]
2. [Secondary goal]
3. [Secondary goal]

Success Metrics

Metric	Current Baseline	Target	Timeline
[Primary metric]	[Value]	[Value]	[Date]
[Secondary metric]	[Value]	[Value]	[Date]

Non-Goals

• [Non-goal 1]
• [Non-goal 2]

User Stories

ID	User Story	Priority
US-1	As a [user], I want [action] so that [benefit]	P0
US-2	As a [user], I want [action] so that [benefit]	P0
US-3	As a [user], I want [action] so that [benefit]	P1

See [link to detailed user stories] for full acceptance criteria.

Scope

In Scope

• [Feature/capability 1]
• [Feature/capability 2]
• [Feature/capability 3]

Out of Scope

• [Excluded item 1]
• [Excluded item 2]

Future Considerations

• [Future item 1] - [Rationale for deferral]
• [Future item 2] - [Rationale for deferral]

Solution Design

Functional Requirements

[Requirement Area 1]

• FR-1: [Requirement statement]
• FR-2: [Requirement statement]

[Requirement Area 2]

• FR-3: [Requirement statement]
• FR-4: [Requirement statement]

User Experience

[UX notes or link to designs]

Edge Cases

Scenario	Expected Behavior
[Edge case 1]	[Behavior]
[Edge case 2]	[Behavior]

Technical Considerations

Constraints

• [Constraint 1]
• [Constraint 2]

Integration Points

• [System/API 1]: [Integration notes]
• [System/API 2]: [Integration notes]

Data Requirements

[Data notes]

Dependencies & Risks

Dependencies

Dependency	Owner	Status	Impact if Delayed
[Dependency 1]	[Team/Person]	[Status]	[Impact]
[Dependency 2]	[Team/Person]	[Status]	[Impact]

Risks

Risk	Likelihood	Impact	Mitigation
[Risk 1]	[H/M/L]	[H/M/L]	[Mitigation strategy]
[Risk 2]	[H/M/L]	[H/M/L]	[Mitigation strategy]

Timeline & Milestones

Milestone	Description	Target Date
[Milestone 1]	[Description]	[Date]
[Milestone 2]	[Description]	[Date]
[Launch]	[Description]	[Date]

Open Questions

• [Question 1] - Owner: [Name]
• [Question 2] - Owner: [Name]

Appendix

Related Documents

• Problem Statement - add link or path
• User Research - add link or path
• Design Specs - add link or path
• Technical Design - add link or path

Revision History

Version	Date	Author	Changes
1.0	[Date]	[Author]	Initial draft

Example Output

PRD: Recurring Tasks

PRD: Recurring Tasks

Overview

Problem Statement

Users of TaskFlow spend significant time manually recreating repetitive tasks that occur on predictable schedules. Our research shows that 34% of all tasks created are duplicates of previous tasks, and power users report spending 2+ hours per week on this manual work. This friction reduces productivity and causes users to miss recurring deadlines when they forget to recreate tasks.

Solution Summary

Add recurring task functionality that allows users to create tasks that automatically regenerate on defined schedules. Users can set weekly, monthly, or custom recurrence patterns, and the system will create new task instances automatically while preserving the connection to the original recurring series.

Target Users

• Primary: Team leads and project managers who manage ongoing operational tasks (weekly reports, monthly reviews, recurring meetings)
• Secondary: Individual contributors who have personal recurring responsibilities (timesheets, 1:1 prep, status updates)

Goals & Success Metrics

Goals

1. Reduce time spent on manual task recreation by 80%
2. Decrease missed recurring deadlines by 50%
3. Increase weekly active usage among power users

Success Metrics

Metric	Current Baseline	Target	Timeline
Duplicate task creation rate	34%	15%	90 days post-launch
Missed recurring deadlines	12 per user/month	6 per user/month	90 days post-launch
Power user WAU	67%	75%	90 days post-launch
Feature adoption (% using recurring)	0%	40%	90 days post-launch

Non-Goals

• Task dependencies or predecessor relationships
• Automated task assignment rotation (e.g., round-robin)
• Integration with external calendar systems (deferred to v2)

User Stories

ID	User Story	Priority
US-1	As a team lead, I want to create a task that repeats weekly so that I don’t have to manually recreate it	P0
US-2	As a user, I want to edit a single instance without affecting the series so that I can handle exceptions	P0
US-3	As a user, I want to see upcoming instances of recurring tasks so that I can plan my workload	P0
US-4	As a user, I want to pause and resume a recurring series so that I can handle temporary schedule changes	P1
US-5	As a team lead, I want to edit the entire series at once so that I can make bulk changes efficiently	P1
US-6	As a user, I want to set an end date for recurrence so that temporary projects don’t create tasks forever	P1

See User Stories Document for full acceptance criteria.

Scope

In Scope

• Create recurring tasks with daily, weekly, monthly patterns
• Edit single instance vs. entire series
• View upcoming instances (next 4 weeks)
• Pause/resume recurring series
• Set recurrence end date or occurrence count
• Delete single instance vs. entire series
• Recurring tasks visible in list view, calendar view, and board view

Out of Scope

• Custom recurrence patterns (e.g., “every 3rd Tuesday”) - v2
• Calendar sync (Google Calendar, Outlook) - v2
• Task assignment rotation - future consideration
• Recurring subtasks - future consideration
• Bulk operations on multiple recurring series

Future Considerations

• Custom patterns (v2): Complex scheduling like “first Monday of each month” or “every 2 weeks” - deferred due to UI complexity; standard patterns cover 85% of use cases
• Calendar sync (v2): Two-way sync with external calendars - deferred due to integration complexity and scope
• Assignment rotation: Auto-rotate assignee for team tasks - requires additional UX research to understand use cases

Solution Design

Functional Requirements

Task Creation

• FR-1: Users can mark any new task as recurring during creation
• FR-2: Recurrence options include: Daily, Weekly (select days), Monthly (select date or day-of-week)
• FR-3: Users can set recurrence to end after X occurrences or on a specific date
• FR-4: Default recurrence end is “never” with system limit of 52 weeks forward generation

Instance Management

• FR-5: Each recurring task generates instances up to 4 weeks in advance
• FR-6: Completing an instance marks only that instance complete and triggers next instance generation
• FR-7: Editing an instance shows option: “Edit this instance only” or “Edit all future instances”
• FR-8: Deleting an instance shows option: “Delete this instance only” or “Delete entire series”

Series Management

• FR-9: Users can pause a recurring series, stopping new instance generation
• FR-10: Paused series display visual indicator and can be resumed
• FR-11: Users can view and edit the recurrence pattern from any instance

User Experience

Creation Flow:

1. User clicks “Add Task”
2. User enters task details
3. User clicks “Make Recurring” toggle
4. Recurrence panel expands with pattern options
5. User selects pattern and confirms
6. First instance created immediately, future instances generated

Visual Indicators:

• Recurring tasks show refresh icon in list/board views
• Instance number displayed (e.g., “#3 of series”)
• Paused series show pause indicator with muted styling

See Figma Design Specs for detailed mockups.

Edge Cases

Scenario	Expected Behavior
User deletes instance that’s in progress	Prompt: “This task has logged time. Delete anyway?”
Series created with past start date	Create instance for next valid date, not retroactively
Monthly recurrence on 31st	Use last day of month for shorter months
User changes recurrence pattern	Apply to future instances only, preserve completed instances
User completes instance early	Next instance still generates on schedule

Technical Considerations

Constraints

• Maximum 52 weeks of forward instance generation (prevent database bloat)
• Recurrence calculations must handle timezone correctly (user’s local time)
• Instance generation must be idempotent (safe to re-run)

Integration Points

• Notification Service: Recurring task reminders use existing notification infrastructure
• Activity Feed: Instance completion logs to activity feed as normal task completion
• Reporting: Recurring tasks aggregate into existing productivity reports

Data Requirements

• New recurring_series table linking instances to parent series
• recurrence_pattern stored as RRULE-compatible format for future calendar sync
• Soft delete for series to preserve historical data
• Migration: No data migration required (new feature)

Dependencies & Risks

Dependencies

Dependency	Owner	Status	Impact if Delayed
Calendar view refactor	Frontend Team	In Progress	Cannot show recurring instances in calendar
Background job infrastructure	Platform Team	Complete	None
Design specs finalized	Design Team	In Review	Delays development start

Risks

Risk	Likelihood	Impact	Mitigation
User confusion about instance vs. series editing	Medium	Medium	Clear UI copy, confirmation dialogs, user testing
Performance impact of instance generation	Low	High	Lazy generation, batch processing, monitoring
Feature complexity delays launch	Medium	Medium	MVP scope locked, defer edge cases to v1.1
Low adoption if UX isn’t intuitive	Medium	High	User testing before launch, in-app education

Timeline & Milestones

Milestone	Description	Target Date
Design Complete	Final mockups approved	Jan 24, 2026
Backend Complete	API and data model ready	Feb 7, 2026
Frontend Complete	UI implementation done	Feb 21, 2026
QA Complete	Testing and bug fixes	Feb 28, 2026
Beta Launch	10% rollout	Mar 3, 2026
GA Launch	100% rollout	Mar 10, 2026

Open Questions

• Should we support “business days only” recurrence? - Decision: No, defer to v2
• How do we handle recurring tasks when user loses access to project? - Owner: Product
• Should paused series auto-resume after X time? - Owner: Product
• What’s the right default reminder time for recurring tasks? - Owner: Design

Appendix

Related Documents

• Problem Statement: Task Recreation Friction
• User Research: Recurring Task Needs
• Figma: Recurring Tasks Design
• Technical Design: Recurrence Engine

Revision History

Version	Date	Author	Changes
0.1	Jan 10, 2026	Sarah Chen	Initial draft
0.2	Jan 12, 2026	Sarah Chen	Added edge cases, updated scope
1.0	Jan 14, 2026	Sarah Chen	Final review, approved by stakeholders

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . Campaigns (built-in email marketing)

Prompt:

deliver-prd

Feature: Campaigns . native email marketing for Storevine merchants

Context: Storevine all-in-one ecommerce + web builder, ~18k active merchants
[fictional]. See: competitive-analysis (filed last week), problem-statement
(Q4 discovery doc).

Discovery: Email marketing is a top-3 churn driver. Exit survey: 22% of churned
accounts in Q4 cited "had to use a separate email tool" as a primary reason
[fictional]. Power merchants patch with Klaviyo or Mailchimp; smaller merchants
skip email entirely because setup friction is too high.

Validated solution: Built-in Campaigns . broadcast email + basic audience
segmentation. Phase 1 email only, SMS deferred. Pre-built templates, audience
builder using order/tag data we already have. No custom HTML editor v1.

Success targets:
- 40% of active merchants send ≥1 campaign in first 90 days post-launch [fictional]
- Reduce email-churn contribution by 30% at 6 months [fictional]
- Campaigns becomes a net-new revenue line (paid tier above free send limit)

Scope locked with eng: v1 = broadcast email + 3 automations (abandoned cart,
welcome, re-engagement). No SMS, no A/B testing, no multi-step sequences.

Technical decisions already made:
- Sending via SendGrid (existing account)
- Audience builder queries existing customer/order tables . no new pipeline
- Legal review on CAN-SPAM + GDPR required before launch (not yet started)

Stakeholders: Growth PM (owner), Eng Lead (aligned), Design (in progress),
Legal (needs to review compliance section), Marketing (will dog-food).

---

Output:

PRD: Storevine Campaigns

Brainshelf (Consumer): Brainshelf consumer PKM app . Resurface feature PRD for Sprint 8 build

Prompt:

deliver-prd

resurface prd for sprint 8. pulling everything together: solution brief,
adr (resend), design rationale (text layout), spike (tfidf).

building the daily email digest that surfaces 3-5 saved items matched
to recent reading. opt-in required. 7:30 AM local time. tfidf for
topic matching. resend for email. text-only layout.

target users: active savers (10+ items, active in last 30 days) .
about 9,800 users [fictional].

metrics: 7-day return rate 18%→25% [fictional], email CTR ≥15% [fictional],
unsub ≤2%/week [fictional].

scope: digest email, topic matching, opt-in flow, cadence setting,
one-click read, analytics events. NOT doing: in-app resurfacing,
push notifications, smart collections.

timeline: sprint 8 build (feb 3-16), setup week (mar 2-8),
a/b test (mar 9 - apr 5), decision (apr 11).

---

Output:

PRD: Resurface . Morning Email Digest

Workbench (Enterprise): Workbench enterprise collaboration platform - Blueprints v1 PRD for required-section enforcement and approval gates

Prompt:

deliver-prd

Here is the structured brief for the Blueprints v1 PRD.

**Product context:**
- Workbench collaboration platform, ~500 enterprise customers [fictional], Series B
- Blueprints = reusable document templates with required sections and approval gates
- Core problem: 38% of Blueprints reach approval with ≥1 empty section [fictional]; median time to first approval is 4.0 days [fictional]; 60% of enterprise projects lack an approved kickoff doc at handoff [fictional]

**Prior decisions to incorporate:**
- ADR-012: Yjs CRDTs selected for real-time co-editing (45ms merge latency at 20 concurrent editors [fictional], +38KB gzipped [fictional])
- Design rationale: Hybrid wizard/canvas -- guided wizard for first-time authors, blank canvas for returning authors
- Opportunity tree: Priority path is documentation governance gap → required-section enforcement
- Hypothesis: Required sections reduce time-to-approved from 4.0 days to ≤2.5 days [fictional]; validation via A/B test (Mar 9 -- Apr 5, 2026)

**Target users:** Enterprise ops managers (creators), department heads (approvers), IT security leads (admin/provisioning)

**Key features for v1:**
1. Required-section enforcement (submit button disabled until all required sections complete)
2. Native approval gates (role-based routing, sequential and parallel approval)
3. Yjs real-time co-editing (offline-first, sub-document-level sync)
4. Hybrid wizard/canvas creation flow
5. Enterprise security suite (SAML SSO, audit logs, role-based access)

**Timeline:** Closed beta running now with 80 accounts [fictional]; A/B test Mar 9 -- Apr 5; GA target April 2026

**Success metrics:** Time-to-approved ≤2.5 days [fictional], empty-section rate ≤10% [fictional], enterprise account growth from 500 to 650 in 12 months [fictional]

Please generate a complete PRD following the standard template.

Output:

PRD: Workbench Blueprints v1

Quality Checklist

Before finalizing, verify:

• Problem and “why now” are clearly articulated
• Success metrics are specific and measurable
• Scope boundaries are explicit (in/out/future)
• Requirements are testable and unambiguous
• Technical considerations are surfaced without over-specifying
• Dependencies and risks are documented with owners
• Document is readable in under 15 minutes