Prd Writer Skill for Claude

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 for large feeds (1000+ items)
• Mobile: Single-column layout, touch-friendly tap targets (44px min)

Prioritization Framework: RICE

RICE Scoring Formula: (Reach × Impact × Confidence) / Effort

Reach (How many users affected in 3-month period)

• Example: 80% of active users = 8,000 users
• Scale: 0-10,000+

Impact (How much does this change user outcome)

• Massive (3x): Huge improvement in workflow
• High (2x): Significant improvement in efficiency
• Medium (1x): Noticeable improvement
• Low (0.5x): Minor improvement

Confidence (How confident are we in this estimate)

• High (100%): Based on customer data/usage patterns
• Medium (75%): Some user feedback, some assumptions
• Low (50%): Speculative, needs validation

Effort (How many person-weeks to implement)

• Small: 1-2 weeks
• Medium: 3-4 weeks
• Large: 5-8 weeks
• XL: 8+ weeks

RICE Calculation Example:

• Reach: 8,000 users
• Impact: 2x (high)
• Confidence: 75%
• Effort: 4 weeks

Rice Score = (8000 × 2 × 0.75) / 4 = 3,000

Alternative Prioritization: MoSCoW

Must Have (Feature shipping incomplete without)

• Real-time status updates
• Activity notification system
• Notification delivery via email

Should Have (Important, ships in first iteration)

• Mobile push notifications
• Notification settings/preferences
• Activity feed filtering
• Do-not-disturb scheduling

Could Have (Nice to have, future iteration)

• Slack integration
• Custom notification batching
• Advanced activity analytics
• Activity timeline visualization

Won't Have (Explicitly out of scope)

• SMS notifications
• Voice notifications
• Calendar integration for notifications

Timeline and Release Planning

Phase 1: MVP (4 weeks)

• Real-time status broadcasting (WebSocket)
• Activity feed (basic display)
• Email notifications
• Core notification settings
• Release: Target Quarter end

Phase 2: Enhancement (3 weeks)

• Mobile push notifications
• Advanced filtering and search
• Do-not-disturb scheduling
• Activity analytics
• Release: 2 weeks into next quarter

Phase 3: Integration (4 weeks)

• Slack integration
• Calendar sync
• Notification customization UI improvements
• Release: Mid-quarter

Success Metrics

Adoption:

• Feature discoverability: 60% of users discover feature within 30 days
• Initial activation: 40% of users send at least one notification within week 1
• Weekly active users: 70% of users using feature weekly by month 3

Engagement:

• Daily active users: 50% of active users daily
• Activity feed views: Average 8 views per user per day
• Notification opens: 35% of delivered notifications opened

Business Impact:

• Time savings: Users report 30% reduction in status-checking time
• Meeting reduction: Average meeting duration reduced by 15 minutes/week
• Retention: Feature users have 10% higher 12-month retention

Quality Metrics:

• Notification delivery: 99.9% successful delivery rate
• Latency: 95% of updates delivered within 2 seconds
• Error rate: <0.1% of operations result in error

Risks and Mitigation

| Risk | Impact | Probability | Mitigation |

|------|--------|-------------|-----------|

| WebSocket scalability issues | High | Medium | Load test with 10K concurrent users before launch |

| Notification fatigue causing opt-outs | High | Medium | Implement smart batching and do-not-disturb by default |

| Mobile app notification permissions | Medium | High | Provide clear education on benefits before permission request |

| Slack integration delays | Low | Medium | Build without Slack first, add as phase 2 |

PRD Approval Checklist

• [ ] User stories clear and testable
• [ ] Acceptance criteria comprehensive
• [ ] Technical feasibility confirmed by engineering
• [ ] Design mockups reviewed and approved
• [ ] Success metrics defined and measurable
• [ ] Timeline realistic and estimated
• [ ] Risks identified and mitigation planned
• [ ] Dependencies documented
• [ ] Stakeholder sign-offs obtained
• [ ] PRD reviewed by design, engineering, QA, marketing
• [ ] Open questions resolved
• [ ] Ready for development kick-off

Output Deliverables

• Full PRD Document - All sections above, 15-20 pages
• Design Mockups/Wireframes - High-fidelity or detailed wireframes
• Technical Specification - API contracts, data models, schemas
• User Stories & Acceptance Criteria - JIRA-ready format
• Success Metrics Dashboard - Definition of all KPIs
• Timeline/Roadmap - Phased release plan
• Risk Register - Risks and mitigation strategies