Overview
Once UX/UI designs are complete, the Product Owner collaborates with Business Stakeholders to create a Product Requirements Document (PRD). This document serves as the single source of truth for the development team.
Designs Complete
→
PRD Creation
→
PRD Review
→
PRD Sign-off
→
Ready for Sprint
When to Use Full PRD vs Lightweight Approach
| Item Type |
Approach |
Documentation |
| New Feature (large) |
Full PRD |
Complete PRD with all sections |
| Feature Enhancement |
Lightweight PRD |
Objective + User Stories + AC only |
| Bug Fix (P2/P3) |
Ticket Only |
Issue description + AC in ticket |
| Tech Debt / Refactor |
Tech Spec |
Technical approach + risk assessment |
Right-size documentation. Match effort to complexity. Small changes don't need 4-hour PRD sessions.
PRD Quality Principle
A great PRD serves three purposes: Requirements document, acceptance criteria, and test cases - all in one.
The PRD Trinity
Requirements
What to build
=
Acceptance Criteria
How to verify
=
Test Cases
What to test
↓
Single Source of Truth
Dev, QA, Stakeholders align
When scenarios and use cases are well-detailed, they should look similar to test cases. This is the quality bar we aim for:
- Detailed scenarios read like test cases - QA should be able to derive test cases directly from the PRD without additional interpretation
- Acceptance criteria are verifiable - Each criterion can be unambiguously tested as pass/fail
- Use cases cover happy paths and exceptions - Both expected flows and error conditions are documented
- The PRD is the single source of truth - Development, QA, and stakeholders all reference the same document
This is an evolving capability. With more like-minded product managers, we will get closer to this ideal state where PRD = Acceptance Criteria = Test Cases.
PRD Creation Session
| Aspect |
Details |
| Duration |
2-4 hours per feature |
| Attendees |
Product Owner, Functional Lead, Technical Architect, Business Stakeholders, UX Lead |
| Timing |
Completed before Sprint Planning (alongside or after Design Handoff) |
PRD Contents
| Section |
Description |
| Feature Overview |
High-level summary of the feature |
| Objectives |
Specific goals the feature aims to achieve |
| Business Benefits |
Expected ROI, efficiency gains, or strategic value |
| Use Cases |
Real-world scenarios describing how users will interact |
| User Stories |
"As a [role], I want [capability], so that [benefit]" |
| Acceptance Criteria |
Testable conditions for each story to be complete |
| Dependencies |
Related systems, APIs, or features required |
| Out of Scope |
Explicitly excluded items to prevent scope creep |
| Design References |
Links to UX/UI mockups and prototypes |
PRD Template
# PRD: [Feature Name]
## 1. Objective
What problem are we solving? What is the measurable goal?
## 2. Background
Why is this important now? Business context and drivers.
## 3. Benefits
- Business benefit 1
- Business benefit 2
- User benefit 1
## 4. Use Cases
### Use Case 1: [Name]
- Actor: [User role]
- Precondition: [Initial state]
- Flow: [Step-by-step interaction]
- Postcondition: [Expected outcome]
## 5. User Stories and Acceptance Criteria
### Story 1: [Title]
**As a** [role], **I want** [capability], **so that** [benefit].
**Acceptance Criteria:**
- [ ] Given [context], when [action], then [result]
- [ ] Given [context], when [action], then [result]
## 6. Design References
- [Link to Figma designs]
- [Link to prototype]
## 7. Dependencies
- [System/API dependencies]
## 8. Out of Scope
- [Items explicitly not included]
## 9. Open Questions
- [Unresolved items to be addressed]
View full PRD template →
PRD Review and Sign-off
| Aspect |
Details |
| Duration |
1 hour per PRD |
| Attendees |
Product Owner, Functional Lead, Technical Architect, Business Stakeholders, Quality Engineer |
| Required Approvers |
Functional Lead, Technical Architect |
Sign-off Checklist
- All user stories have clear acceptance criteria
- Use cases cover primary and edge scenarios
- Designs are linked and accessible
- Dependencies are identified and addressed
- Out of scope items are documented
- Stakeholders formally approve the PRD
PRD Handoff to Development
- PRD stored in feature sub-folder on Google Drive
- Dev team reviews PRD before Sprint Planning
- Questions and clarifications addressed in Refinement session
- PRD becomes the reference for Sprint Planning and QA test case creation
Definition of Ready: A feature is ready for Sprint Planning when it has an approved PRD with complete acceptance criteria and finalized designs.
Next Phase
With the PRD approved, the feature moves to
Sprint Planning where the team estimates, commits, and begins development.