BMAD-METHOD/src/modules/wds/docs/method/phase-6-prd-finalization-guide.md

Phase 6: PRD Finalization (Complete PRD)

Agent: Freyja the PM
Output: Complete PRD in C-Requirements/ + Handoff materials in E-UI-Roadmap/

---

What This Phase Does

PRD Finalization compiles all the functional requirements discovered during Phase 4 into a complete, development-ready Product Requirements Document.

The key insight: Your PRD started in Phase 3 with platform/infrastructure. During Phase 4, each page added functional requirements (via step 4E). Now you organize, prioritize, and finalize everything for development handoff.

By the end, developers have a complete PRD covering both technical foundation and all UI-driven features.

---

What You'll Create

Updated PRD (C-Requirements/) includes:

From Phase 3 (Technical Foundation):

• Platform architecture
• Data model
• Integration map
• Technical proofs of concept
• Experimental endpoints
• Security framework

Added from Phase 4 (Functional Requirements):

• All features discovered during page design
• Page-to-feature traceability
• Priority rankings
• Feature dependencies
• Implementation notes

New in Phase 6:

• Feature organization by epic/area
• Development sequence
• MVP scope definition
• Technical dependencies mapped

Handoff Package (E-UI-Roadmap/):

• Priority sequence document
• Scenario-to-development mapping
• Component inventory (if Design System enabled)
• Open questions for dev team

---

How It Works

Stage 1: Review Collected Requirements (30-45 minutes)

Gather all functional requirements added during Phase 4:

Go through each scenario specification and extract the requirements added in step 4E:

From 1.1-Start-Page:
- User authentication system
- Session management
- Password reset flow

From 1.2-Sign-Up:
- Email validation (format, domain check, duplicate prevention)
- Phone number validation with country code
- Account activation via email

From 2.1-Dog-Calendar:
- Availability calendar API
- Real-time updates via WebSocket
- Date/time localization

Compile into master feature list with page references preserved.

Stage 2: Organize by Epic/Feature Area (30-45 minutes)

Group related features together:

## Epic 1: User Authentication & Account Management

### Features

**User Registration**
- Required by: 1.2-Sign-Up
- Email validation (format, domain, duplicates)
- Phone validation with country codes
- Account activation flow

**User Login**
- Required by: 1.1-Start-Page, multiple pages
- Email/password authentication
- Session management (30-day persistence)
- "Remember me" functionality

**Password Management**
- Required by: 1.1-Start-Page (reset link)
- Password reset via email
- Password strength validation
- Secure token generation

Stage 3: Define Priorities & Sequence (45-60 minutes)

Based on your Phase 2 Feature Impact Analysis:

Reference the scoring you did in Phase 2 to inform priorities:

## Development Sequence

### Priority 1: MVP - Core User Flow
**Target:** Weeks 1-4

Features from Epic 1 (Authentication) + Epic 2 (Core Booking):
- User registration (Impact Score: 14)
- User login (Impact Score: 16)
- Availability calendar (Impact Score: 16)
- Basic booking flow (Impact Score: 18)

**Why this order:**
Serves Priority 1 target group, addresses highest-impact drivers.

### Priority 2: Enhanced Features
**Target:** Weeks 5-8

Features from Epic 3 (Payments) + Epic 4 (Notifications):
- Payment processing (Impact Score: 12)
- Booking confirmations (Impact Score: 11)
- Calendar sync (Impact Score: 8)

Stage 4: Map Dependencies (20-30 minutes)

Technical dependencies between features:

## Feature Dependencies

**Booking Flow** depends on:
- ✓ User authentication (must be logged in)
- ✓ Availability calendar (must see open slots)
- ⚠️ Payment system (can launch with "pay in person" temporarily)
- ⚠️ Notifications (can launch without, add later)

**Recommendation:** Launch MVP with auth + calendar, add payments in Sprint 2.

Stage 5: Create Handoff Package (30-45 minutes)

Organize for development team:

In E-UI-Roadmap/ folder, create:

1. priority-sequence.md - What to build when and why
2. scenario-to-epic-mapping.md - How WDS scenarios map to dev epics
3. component-inventory.md (if Design System enabled) - All components needed
4. open-questions.md - Decisions for dev team to make

---

The Complete PRD Structure

Your finalized PRD in C-Requirements/ combines all phases:

# Product Requirements Document

## 1. Technical Foundation (from Phase 3)

### Platform Architecture
- Technology stack decisions
- Infrastructure approach  
- Hosting and deployment

### Data Model
- Core entities and relationships
- Database schema
- Data flow diagrams

### Integrations
- External services (Google Maps, Stripe, etc.)
- API specifications
- Authentication providers

### Security & Performance
- Authentication/authorization approach
- Data protection
- Performance requirements
- Proofs of concept results

## 2. Functional Requirements (from Phase 4)

### Epic 1: User Authentication & Account Management
**Features:**
- User registration (Required by: 1.2-Sign-Up)
- User login (Required by: 1.1-Start-Page, multiple)
- Password management (Required by: 1.1-Start-Page)

[Detailed specifications for each feature]

### Epic 2: [Next Epic]
[...]

## 3. Development Roadmap (from Phase 6)

### Priority 1: MVP (Weeks 1-4)
- Features list with Impact Scores
- Why these first (references Trigger Map)
- Timeline estimate
- Dependencies

### Priority 2: Enhanced Features (Weeks 5-8)
[...]

## 4. Dependencies & Constraints
- Technical dependencies between features
- Design constraints from Phase 4
- Third-party limitations discovered in Phase 3

## 5. Success Metrics
- Business goals from Phase 1
- Feature-specific KPIs
- How we measure success

---

Continuous vs. Final Handoff

The pattern:

• Phase 3: Initial PRD with technical foundation
• Phase 4: PRD grows with each page (step 4E adds requirements)
• Phase 6 (First time): Organize MVP scope from completed scenarios
  • Create first handoff package
  • Development can begin
• Phase 4 continues: More pages designed, more requirements added
• Phase 6 (Ongoing): Update PRD priorities, create new handoff packages
  • Weekly or bi-weekly updates
  • Keep dev team synced

You can run Phase 6 multiple times as design progresses.

---

When to Use This Phase

First PRD Finalization when:

• You have MVP-level scenarios complete (enough for dev to start)
• Core user flows are specified
• Critical features are documented
• Enough work for 2-4 week sprint

Ongoing PRD Updates as:

• Additional scenarios complete
• New feature areas designed
• Priorities shift based on learning
• Sprint planning needs updated scope

Timeline example:

Week 1-2: Phase 1-3 (Strategy, Research, Platform foundation)
Week 3-4: Phase 4 Scenarios 1-3 (Core MVP flows)
Week 5:   Phase 6 First Finalization
          └──► PRD v1.0: MVP scope ready
          └──► Development Sprint 1 begins

Week 6-7: Phase 4 Scenarios 4-6 (Additional features)
          Phase 5 Design System (extract components)
Week 8:   Phase 6 Update
          └──► PRD v1.1: Sprint 2 scope added
          └──► Development Sprint 2 begins

Week 9+:  Design continues in parallel with development
          Regular Phase 6 updates for new sprints

The beauty: Design doesn't block development. You hand off in waves.

Complete list for test automation:

Scenario	Object ID	Element Type	Notes
1.1	welcome-hero-cta	Button	Primary action
1.1	welcome-signin-link	Link	Secondary action
1.2	signin-email-input	Input	Required field
1.2	signin-error-email	Error	Validation message

---

How It Works

Review Completeness

Before handoff, verify:

• All scenarios specified and reviewed
• Design system covers all components
• Object IDs assigned throughout
• Multilingual content complete
• HTML prototypes validated

Identify Priorities

With Freyja, map your Trigger Map priorities to development order:

• Which user triggers are most critical?
• What's the minimum viable experience?
• What can wait for later releases?

Document Technical Context

Capture what developers need to know:

• Design decisions and their rationale
• Technical constraints discovered during design
• Interaction patterns that need special attention
• Performance considerations

Create the Handoff

Organize everything into the UI Roadmap folder:

• Clear priority sequence
• Complete component inventory
• Technical notes and open questions
• Verification checklist

---

The Handoff Checklist

## Design Handoff Verification

### Product Foundation
- [ ] Product Brief complete and current
- [ ] Trigger Map with prioritized users and goals
- [ ] ICP clearly defined

### Requirements
- [ ] PRD with technical specifications
- [ ] Platform architecture documented
- [ ] Integration requirements listed

### Visual Design
- [ ] All scenarios have specifications
- [ ] All pages have Object IDs
- [ ] States documented (empty, loading, error, success)

### Design System
- [ ] All components documented
- [ ] Design tokens defined
- [ ] Usage guidelines written

### Validation
- [ ] HTML prototypes created for key scenarios
- [ ] Stakeholder review complete
- [ ] Open questions documented

### Ready for Development ✅

---

When to Use This Phase

First handoff when:

• You have enough scenarios for MVP
• Core user flows are specified
• Critical components are documented
• Developers can start building foundational features

Ongoing handoffs as:

• Each major scenario completes
• New component patterns emerge
• Design decisions affect development
• Sprint planning needs updated priorities

The rhythm:

Week 1-2: Design Phase 1-3 (Strategy, Research, Platform)
Week 3-4: Design Phase 4 Scenarios 1-2 (Core flows)
         └──► First Handoff: MVP scope
Week 5-6: Design Phase 4 Scenarios 3-4
         Design Phase 5 (Components from 1-2)
         └──► Second Handoff: Additional features
Week 7+:  Design continues...
          Development builds in parallel
          └──► Ongoing handoffs as design progresses

You DON'T need to finish all design before handing off.

Development and design work in parallel streams, with regular sync points.

---

What to Prepare

Bring:

• Completed scenario specifications (Phase 4)
• Design System (Phase 5)
• PRD (Phase 3)
• Trigger Map priorities (Phase 2)

---

What Comes Next

Your UI Roadmap enables:

• Development kickoff - Clear starting point
• Sprint planning - Prioritized work items
• Test automation - Object ID inventory
• QA validation - Specifications to verify against

---

Tips for Great Sessions

Think from dev perspective

• What questions will developers have?
• What decisions can't you make for them?
• What context will save them time?

Be explicit about priorities

• Not everything is Priority 1
• Make trade-offs visible
• Connect priorities to business goals

Document the unknowns

• Open questions are valuable
• Don't pretend certainty you don't have
• Let dev team contribute decisions

Keep it updated

• Handoff is ongoing, not one-time
• Update as design evolves
• Maintain as source of truth

---

Integration with BMM

When handing off to BMad Method (BMM) for development:

WDS → E-UI-Roadmap/ → BMM Architecture & Stories

The UI Roadmap provides:

• Context for architecture decisions
• Specifications for story creation
• Priorities for sprint planning
• Test automation foundations

---

Example Output

See: examples/dog-week-patterns/E-UI-Roadmap/ for a complete UI Roadmap from a real project.

---

Phase 6 of the Whiteport Design Studio method