Home / PRD Creation

📋 Phase 4: PRD Creation

Product Requirements Document - The foundation for development

On This Page

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 Creation Session

Aspect Details
Duration 2-4 hours per feature
Attendees Product Owner, Functional Lead, Technical Lead, 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 Lead, Business Stakeholders, QA Lead
Required Approvers Functional Lead, Technical Lead

Sign-off Checklist

PRD Handoff to Development

Storage: PRDs are stored in Google Drive: Sequifi Product Docs in the feature's sub-folder.
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.