prd-writer

PRD Writer

Overview

The PRD Writer skill guides product managers in creating clear, actionable Product Requirements Documents that align teams around feature specifications. It combines user-centered design, technical clarity, and business context to ensure successful implementation.

When to Use This Skill

• Defining new features or products for development
• Communicating requirements to engineering teams
• Prioritizing features across roadmap
• Documenting feature specifications before development
• Communicating product vision to stakeholders
• Creating specifications for design and QA teams

PRD Template and Structure

Executive Summary

Feature Name: [Clear, descriptive name] Owner (PM): [Name] Stakeholders: [Engineering, Design, Marketing, Legal, etc.] Status: [Draft, Under Review, Approved, In Development] Last Updated: [Date]

Vision Statement: [1-2 sentences describing the big picture) Example: "Enable users to collaborate on projects in real-time, reducing communication overhead and improving team alignment."

Business Objective:

• Primary goal: [Increase retention/revenue/efficiency]
• Measurable target: [X% improvement in metric]
• Time frame: [Quarter/year target]

User Problem Being Solved: [Describe the pain point this feature addresses] "Users currently spend 30+ minutes in meetings synchronizing project status manually. This feature enables asynchronous updates, reducing meeting time by 50%."

Success Criteria:

• Adoption: [% of users adopting within 3 months]
• Engagement: [% of users using feature weekly]
• NPS impact: [Target +5 NPS points]
• Revenue: [$X MRR increase or $X cost savings]

User Stories and Use Cases

Primary Use Cases:

Use Case 1: Team Real-Time Collaboration

• Actor: [Project team member]
• Precondition: [User is logged in, project open]
• Main flow:
• User updates task status
• Update broadcasts to team instantly
• Notification appears in activity feed
• Postcondition: [All team members see updated status]
• Alternative flows: [Connection lost, offline mode]

Use Case 2: Asynchronous Status Reporting

• Actor: [Remote team member]
• Precondition: [User is in different timezone]
• Main flow:
• User adds comment to task
• Comment appears in feed
• Manager receives daily digest
• Manager responds asynchronously
• Postcondition: [No synchronous meeting required]

User Stories Framework

Story 1: View Real-Time Updates

As a [project manager]
I want to [see live updates of task status]
So that [I can monitor progress without status meetings]

Acceptance Criteria:
- When a team member updates task status, I see the update within 2 seconds
- Status changes show in the main project view
- Activity timeline shows all updates with timestamps
- Notifications alert me to priority changes
- I can filter updates by assignee or task type

Definition of Done:
- Code reviewed and approved
- Unit tests pass (>80% coverage)
- QA tested on Chrome, Firefox, Safari
- Product Manager has signed off
- Updated help documentation

Story 2: Receive Activity Notifications

As a [team lead]
I want to [control which activities trigger notifications]
So that [I'm not overwhelmed with alerts]

Acceptance Criteria:
- Notification settings are accessible in preferences
- I can enable/disable alerts by activity type
- I can choose delivery method (in-app, email, Slack)
- Settings persist across devices
- Changes apply immediately

Definition of Done:
- Backend stores notification preferences
- Frontend UI implemented and tested
- Email delivery tested
- Slack integration verified
- Analytics event added for tracking

Story 3: Mobile Notification Delivery

As a [remote employee]
I want to [receive notifications on my phone]
So that [I stay informed while away from desk]

Acceptance Criteria:
- Push notifications delivered to iOS and Android apps
- Notifications respect local time zone
- User can tap notification to jump to relevant item
- Notification includes context (project, task, change)
- Deep linking to specific feature works

Definition of Done:
- Push service integrated (Firebase Cloud Messaging)
- iOS and Android implementations complete
- Battery/battery testing on both platforms
- Deep linking tested on Android and iOS

Detailed Specifications

Feature Specification Overview

Feature Name: [Name] Scope: [What's included and explicitly NOT included] Dependencies: [Features that must exist first] Data Model Changes: [Database schema updates]

Functional Requirements

Requirement 1: Real-Time Status Updates

• System shall broadcast task status changes to all project members within 2 seconds
• Broadcast includes: task ID, new status, previous status, timestamp, user who made change
• System shall maintain 99.9% uptime for status broadcasting
• System shall handle up to 1,000 concurrent status updates per project

Requirement 2: Activity Feed Display

• Feed shall show all activity in reverse chronological order
• Each activity item shall include: actor, action, object, timestamp, context
• Feed shall paginate in 20-item increments
• User can filter feed by: activity type, assignee, task, date range
• Feed loads within 1 second for initial load, 500ms for pagination

Requirement 3: Notification Delivery

• System shall deliver notifications within 5 seconds of activity trigger
• User can choose delivery method per activity type: in-app, email, Slack, mobile push
• Notifications shall respect do-not-disturb hours (if configured)
• System shall batch notifications to prevent notification fatigue (max 1 email per hour)

Technical Specifications

Technology Stack:

• Frontend: [React 18, TypeScript]
• Backend: [Node.js, Express]
• Database: [PostgreSQL]
• Real-time: [WebSockets, Socket.io]
• Notifications: [SendGrid for email, FCM for mobile, Slack API]

API Endpoints:

POST /api/tasks/{taskId}/status
Updates task status, triggers broadcast

GET /api/projects/{projectId}/activity
Fetches activity feed with pagination

PUT /api/notifications/preferences
Updates user notification settings

POST /api/notifications/subscribe
Subscribes to WebSocket for real-time updates

Database Schema Changes:

CREATE TABLE activity_feeds (
  id UUID PRIMARY KEY,
  project_id UUID REFERENCES projects(id),
  actor_id UUID REFERENCES users(id),
  action_type VARCHAR(50), -- task_updated, comment_added, etc.
  target_id UUID, -- task, comment, project
  target_type VARCHAR(50),
  changes JSONB, -- before/after values
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE notification_settings (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  activity_type VARCHAR(50),
  email BOOLEAN DEFAULT true,
  in_app BOOLEAN DEFAULT true,
  slack BOOLEAN DEFAULT false,
  mobile_push BOOLEAN DEFAULT true,
  dnd_start TIME,
  dnd_end TIME
);

UI/UX Specifications

Wireframe Descriptions

Screen 1: Activity Feed

[Header: "Activity"]
[Filter bar: Activity Type dropdown, Date range picker]
[Activity Item 1]
├─ [Avatar] [Name] [Action] [Context]
├─ [Timestamp] [2 hours ago]
└─ [Details: Task name, Previous → New status]

[Activity Item 2]
...
[Load more button]

Screen 2: Notification Settings Modal

[Header: "Notification Preferences"]
[Tabs: Delivery Methods | Do Not Disturb]

[Activity Type Toggles]
├─ Task Status Updated
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
│  ├─ Batch these notifications (dropdown: real-time, daily, weekly)
├─ New Comment
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
├─ Task Assigned to Me
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push

[Save] [Cancel]

Design Considerations

• Visual hierarchy: Activity items show most important info first
• Progressive disclosure: Click item to see full details
• Accessibility: Color not only indicator (✓ + color for status changes)
• Performance: Virtual scrolling f