PRD Workflow

The PRD → Plan → Todo workflow is a game-changing methodology that transforms how you approach feature development. This 15-minute guide will teach you to break down complex requirements into manageable, AI-assisted implementation steps.

Note

For a comprehensive deep-dive into this methodology, including advanced patterns and team collaboration strategies, see our Complete PRD→Plan→Todo Guide.

Why PRD → Plan → Todo Works

Tip

Traditional approach: Jump straight into coding, figure it out as you go

PRD approach: Define → Design → Decompose → Deliver

The Power of Documentation-First Development

Clarity Before Code

Writing requirements forces you to think through edge cases before implementation

AI Understanding

Clear PRDs help AI generate better code by providing complete context

Parallel Work

Team members can start different parts simultaneously with clear specifications

Measurable Progress

Todo lists provide concrete progress tracking and prevent scope creep

Phase 1: Product Requirements Document (PRD)

Creating Effective PRDs

1. Start with User Story

   # User Authentication System
   
   ## User Story
   As a user, I want to securely log into the application
   so that I can access my personalized content and features.

2. Define Success Criteria

   ## Success Criteria
   - Users can register with email/password
   - Email verification is required
   - Login persists for 30 days
   - Password reset via email
   - OAuth integration (Google, GitHub)
   - Session management across devices

3. Specify Technical Requirements

   ## Technical Requirements
   - JWT-based authentication
   - Bcrypt password hashing (12 rounds)
   - Rate limiting on auth endpoints
   - CSRF protection
   - Secure cookie handling
   - Audit logging for auth events

4. Document Edge Cases

   ## Edge Cases
   - Simultaneous login attempts
   - Email already registered
   - Invalid token handling
   - Account lockout after failed attempts
   - Email service downtime
   - Cross-origin authentication

PRD Template

Feature PRD

# Feature: [Name]

## Overview
Brief description of what we're building and why.

## User Stories
- As a [role], I want [feature] so that [benefit]
- Additional stories...

## Functional Requirements
1. Core functionality
2. User interactions
3. Business rules

## Non-Functional Requirements
- Performance: Response time < 200ms
- Security: OWASP compliance
- Scalability: Support 10k concurrent users
- Accessibility: WCAG 2.1 AA

## Success Metrics
- User adoption rate
- Performance benchmarks
- Error rates

## Out of Scope
- What we're NOT building
- Future considerations

## Dependencies
- External services
- Internal systems
- Third-party libraries

API PRD

# API: [Endpoint Name]

## Endpoint Design
POST /api/v1/users/register
Content-Type: application/json

Request:
{
  "email": "user@example.com",
  "password": "SecurePass123!",
  "name": "John Doe"
}

Response (201):
{
  "id": "usr_123",
  "email": "user@example.com",
  "name": "John Doe",
  "emailVerified": false,
  "createdAt": "2024-01-01T00:00:00Z"
}

## Error Responses
- 400: Invalid input
- 409: Email already exists
- 429: Rate limit exceeded
- 500: Server error

## Validation Rules
- Email: Valid format, unique
- Password: 8+ chars, complexity rules
- Name: 2-50 characters

## Rate Limiting
- 5 requests per minute per IP
- 20 requests per hour per email

Integration PRD

# Integration: [Service Name]

## Integration Overview
Connecting our system with [Service] for [purpose].

## Authentication
- Method: OAuth 2.0
- Scopes: read:user, write:data
- Token refresh strategy

## Data Flow
1. User initiates action
2. System requests token
3. Call external API
4. Process response
5. Update local state

## Error Handling
- Retry logic (3 attempts)
- Fallback behavior
- Error reporting

## Data Mapping
| Their Field | Our Field | Transform |
|-------------|-----------|-----------|
| user_id | userId | Direct |
| created_date | createdAt | ISO 8601 |

## Testing Strategy
- Mock responses
- Integration tests
- Load testing

Using AI to Generate PRDs

1. Provide Context:

   "Help me create a PRD for a user notification system.
   We need email, SMS, and push notifications with user
   preferences and delivery tracking."

2. Use @Docs for Research:

   @docs "Review our existing messaging system documentation
   and create a PRD that extends it with notification preferences"

3. Iterate with AI:

   "Add rate limiting requirements and webhook callbacks
   for delivery status to the PRD"

Phase 2: Planning with AI

Transform PRD into Technical Plan

Switch to Ask Mode

Use Ask mode for planning - it won’t make changes, just helps you think through the implementation.

1. Analyze Requirements:

   "Review this PRD and identify the main technical
   components we need to build @notification-prd.md"

2. Architecture Design:

   "Propose an architecture for this notification system.
   Consider scalability, reliability, and maintainability."

3. Break Down Components:

   "Break this down into specific services/modules:
   - What database schema do we need?
   - What API endpoints?
   - What background jobs?
   - What frontend components?"

4. Identify Dependencies:

   "What are the dependencies and integration points?
   What should we build first?"

Planning Output Example

# Notification System - Technical Plan

## Architecture Overview
- API Gateway → Notification Service
- Message Queue (Redis/RabbitMQ)
- Worker Processes for delivery
- Delivery Status Webhooks

## Components

### 1. Database Schema
- users_preferences table
- notifications table
- delivery_status table
- notification_templates table

### 2. API Endpoints
- POST /api/notifications/send
- GET/PUT /api/users/{id}/preferences
- GET /api/notifications/{id}/status
- POST /api/webhooks/delivery

### 3. Background Services
- EmailWorker
- SMSWorker
- PushWorker
- StatusUpdateWorker

### 4. Frontend Components
- NotificationPreferences
- NotificationHistory
- NotificationComposer

## Implementation Order
1. Database schema
2. Preference management API
3. Basic email sending
4. Add SMS and push
5. Status tracking
6. Frontend components

Planning Best Practices

Think in Layers

Plan from data layer up: Database → API → Business Logic → UI

Consider Scale

Design for 10x current load - it’s easier to plan for scale than retrofit

Plan for Failure

Include error handling, retries, and fallbacks in your plan

Security First

Plan authentication, authorization, and data protection from the start

Phase 3: Todo List Implementation

Convert Plan to Actionable Todos

Tip

The magic happens here - your thoughtful planning becomes a systematic implementation roadmap.

1. Generate Initial Todo List:

   "Based on our notification system plan, create a detailed
   todo list with specific implementation tasks. Group by
   component and include estimates."

2. Refine with Details:

   "Add acceptance criteria to each todo item. Include
   testing requirements and documentation tasks."

3. Prioritize Tasks:

   "Reorder these todos by dependency and priority.
   What's the critical path?"

Todo List Example

# Notification System - Implementation Todos

## Phase 1: Foundation (Day 1-2)
- [ ] Create database migration for notification tables
  - [ ] users_preferences table with email/sms/push flags
  - [ ] notifications table with status tracking
  - [ ] notification_templates with variable support
  - [ ] Add indexes for query performance

- [ ] Set up message queue infrastructure
  - [ ] Install Redis/RabbitMQ
  - [ ] Create queue configuration
  - [ ] Set up dead letter queues
  - [ ] Implement connection pooling

## Phase 2: Core API (Day 3-4)
- [ ] Implement preference management
  - [ ] GET /api/users/{id}/preferences endpoint
  - [ ] PUT /api/users/{id}/preferences endpoint
  - [ ] Input validation with Zod
  - [ ] Unit tests with 90%+ coverage

- [ ] Create notification sending API
  - [ ] POST /api/notifications/send endpoint
  - [ ] Template variable substitution
  - [ ] Queue message for delivery
  - [ ] Return tracking ID

## Phase 3: Delivery Workers (Day 5-6)
- [ ] Implement EmailWorker
  - [ ] SendGrid/AWS SES integration
  - [ ] Template rendering
  - [ ] Retry logic (3 attempts)
  - [ ] Error handling and logging

- [ ] Implement SMSWorker
  - [ ] Twilio integration
  - [ ] Phone number validation
  - [ ] Cost tracking
  - [ ] Delivery confirmation

## Phase 4: Status Tracking (Day 7)
- [ ] Delivery status webhooks
  - [ ] POST /api/webhooks/delivery endpoint
  - [ ] Signature verification
  - [ ] Status update processing
  - [ ] Event emission for real-time updates

Using Agent Mode for Implementation

Switch to Agent Mode

Now that you have a clear plan and todos, switch to Agent mode for implementation.

Systematic Implementation

1. Start with First Todo:

   "Let's implement the first todo: Create database migration
   for notification tables. Use our standard migration pattern."

2. Verify Completion:

   "Run the migration and show me the resulting schema"

3. Move to Next Todo:

   "Great! Now let's implement the preferences API endpoints.
   Start with GET /api/users/{id}/preferences"

4. Test as You Go:

   "Write comprehensive tests for the preferences endpoints
   including edge cases"

Todo Management Strategies

Linear Approach

Work through todos sequentially:

1. Complete each todo fully
2. Test before moving on
3. Document as you go
4. Review before next phase

Best for: Clear dependencies, learning projects

Parallel Approach

Multiple developers/AI instances:

1. Assign independent todos
2. Work simultaneously
3. Integrate at milestones
4. Resolve conflicts early

Best for: Tight deadlines, experienced teams

Iterative Approach

Build in layers:

1. Basic implementation first
2. Add features progressively
3. Refactor as needed
4. Polish at the end

Best for: Uncertain requirements, MVPs

Tracking Progress

Visual Progress Tracking

# Progress Dashboard

## Overall: 45% Complete ████████░░░░░░░░

### Phase 1: Foundation ✅ 100%
- [x] Database migrations
- [x] Message queue setup

### Phase 2: Core API 🏗️ 60%
- [x] Preference management
- [ ] Notification sending API
- [ ] Template system

### Phase 3: Workers ⏳ 0%
- [ ] EmailWorker
- [ ] SMSWorker
- [ ] PushWorker

### Phase 4: Tracking 📋 0%
- [ ] Status webhooks
- [ ] Real-time updates

Using Checkpoints

Tip

Create checkpoints after each major phase - this allows safe experimentation and easy rollback.

1. Create Checkpoint:

   "Create a checkpoint: Phase 1 Foundation Complete"

2. Continue Development: Work on next phase

3. Rollback if Needed:

   "Rollback to checkpoint: Phase 1 Foundation Complete"

Common Patterns and Anti-Patterns

Patterns for Success ✅

Clear Scope

Each todo should be completable in 1-4 hours

Testable Outcomes

Every todo has clear acceptance criteria

Dependency Awareness

Order todos by dependencies, not preference

Regular Integration

Integrate work frequently to avoid conflicts

Anti-Patterns to Avoid ❌

Vague Todos

“Implement authentication” - too broad!

Skip Planning

Jumping to todos without PRD/Plan

Ignore Dependencies

Starting UI before API is ready

No Progress Tracking

Losing track of what’s complete

Real-World Example

From PRD to Deployment

Project: E-commerce Cart System
Time: 3 days
Team: 1 developer + Cursor AI

Day 1:
- Morning: Write PRD (2 hours)
- Afternoon: Planning with AI (1 hour)
- Afternoon: Generate todos (30 min)
- Late PM: Implement database schema

Day 2:
- Morning: Cart API endpoints
- Afternoon: Add to cart logic
- Late PM: Testing suite

Day 3:
- Morning: Frontend components
- Afternoon: Integration testing
- Late PM: Documentation & deployment

Result: Feature complete with 95% test coverage

Advanced PRD Techniques

Using Templates

Create reusable PRD templates:

.cursor/templates/
├── feature-prd.md
├── api-prd.md
├── integration-prd.md
└── bugfix-prd.md

AI-Assisted Refinement

"Review this PRD and identify any missing requirements,
edge cases, or potential security concerns"

Collaborative PRDs

"Based on our discussion in @past-chat, create a
comprehensive PRD incorporating all the feedback"

Next Steps

Continue to MCP Setup

Now let’s set up MCP servers to supercharge your development workflow with external integrations.

MCP Setup →

Time: 10 minutes

Tip

Transformation Complete: You now have a systematic approach to feature development that scales from simple bugs to complex systems. This methodology will save hours of rework and confusion.