¶
Quick facts
Phase: Deliver | Version: 2.0.0 | Category: specification | License: Apache-2.0
Product Requirements Document (PRD)¶
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
How to Use¶
Use the /prd slash command:
Or reference the skill file directly: skills/deliver-prd/SKILL.md
Instructions¶
When asked to create a PRD, follow these steps:
-
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.
-
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.
-
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.
-
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.
-
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.
-
Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don't design the system, but surface considerations engineering needs to know.
-
Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.
-
Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.
Output Template¶
PRD: [Feature/Initiative Name]¶
Overview¶
Problem Statement¶
[Problem summary]
Solution Summary¶
[Solution summary]
Target Users¶
[Target user description]
Goals & Success Metrics¶
Goals¶
- [Primary goal]
- [Secondary goal]
- [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¶
- Reduce time spent on manual task recreation by 80%
- Decrease missed recurring deadlines by 50%
- 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_seriestable linking instances to parent series recurrence_patternstored 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:
/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:
/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:
/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
Output Format¶
Use the template in references/TEMPLATE.md to structure the output.