Bootspring
HomeGet Started

Product Requirements Document (PRD) Workflow

Complete guide to creating effective PRDs including user stories, feature prioritization, success metrics, and MVP scope definition

The PRD workflow guides you through creating a comprehensive product requirements document that clearly defines what you're building, for whom, and why.

Overview#

PropertyValue
Phases4
TierFree
Typical Duration1-2 weeks
Best ForPre-development planning, feature definition, team alignment

Why PRDs Matter#

A good PRD:

  • Aligns the team - Everyone understands what success looks like
  • Prevents scope creep - Clear boundaries on what's in/out
  • Reduces rework - Think through edge cases before coding
  • Enables estimation - Engineering can size work accurately
  • Documents decisions - Reference for future questions

PRD Framework#

┌─────────────────────────────────────────────────────────────────────────┐ │ PRD STRUCTURE │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ PROBLEM DEFINITION │ │ │ │ What problem are we solving and for whom? │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ USER STORIES │ │ │ │ What does the user need to accomplish? │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ REQUIREMENTS │ │ │ │ Functional & non-functional requirements │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ SUCCESS METRICS │ │ │ │ How do we measure success? │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘

Phases#

Phase 1: Problem Definition (2-3 days)#

Agents: business-analyst, ui-ux-expert

Clearly articulate the problem and target user.

Tasks:

  • Define the problem statement
  • Identify target user personas
  • Document user pain points
  • Set project context and constraints
  • Define scope boundaries

PRD Header Template:

1# [Product/Feature Name] PRD 2 3## Document Info 4| Field | Value | 5|-------|-------| 6| Author | [Name] | 7| Created | [Date] | 8| Last Updated | [Date] | 9| Status | Draft / In Review / Approved | 10| Version | 1.0 | 11 12## Stakeholders 13| Role | Name | Responsibilities | 14|------|------|------------------| 15| Product Owner | | Final decisions on scope | 16| Tech Lead | | Technical feasibility | 17| Design Lead | | UX decisions | 18| Engineering | | Implementation | 19 20## Executive Summary 21 22### Problem Statement 23[One paragraph describing the problem we're solving] 24 25### Target User 26[One paragraph describing who we're building for] 27 28### Proposed Solution 29[One paragraph high-level description of the solution] 30 31### Success Criteria 32[2-3 bullet points defining what success looks like] 33 34## Background 35 36### Why Now? 37[What's changed that makes this important now?] 38 39### Prior Art 40[What have we tried before? What exists in the market?] 41 42### Constraints 43- Budget: [X] 44- Timeline: [Y] 45- Technical: [Z]

User Persona Template:

1## User Persona: [Name] 2 3### Demographics 4- **Role:** [Job title] 5- **Company:** [Company size, industry] 6- **Experience:** [Years in role] 7- **Technical Level:** [Novice / Intermediate / Expert] 8 9### Goals 101. [Primary goal] 112. [Secondary goal] 123. [Tertiary goal] 13 14### Pain Points 151. [Pain point 1] 162. [Pain point 2] 173. [Pain point 3] 18 19### Current Behavior 20- Uses [current tools] 21- Frequency: [how often they do the task] 22- Workarounds: [manual steps they take] 23 24### Quote 25> "[Actual quote from user research]" 26 27### Jobs to Be Done 28When [situation], I want to [motivation], so I can [outcome]. 29 30Example: 31> When I'm onboarding a new team member, I want to set up their 32> access permissions quickly, so I can get them productive on day one.

Phase 2: User Stories & Requirements (3-5 days)#

Agents: business-analyst, frontend-expert, backend-expert

Define detailed user stories and requirements.

Tasks:

  • Write user stories with acceptance criteria
  • Define functional requirements
  • Define non-functional requirements
  • Document edge cases
  • Create user flow diagrams

User Story Framework:

1## User Stories 2 3### Story Format 4**As a** [user type] 5**I want to** [action] 6**So that** [benefit] 7 8### Acceptance Criteria Format 9**Given** [context] 10**When** [action] 11**Then** [outcome] 12 13--- 14 15### Epic: User Authentication 16 17#### Story 1: User Registration 18**As a** new user 19**I want to** create an account with my email 20**So that** I can access the platform 21 22**Acceptance Criteria:** 231. Given I am on the registration page 24 When I enter a valid email and password 25 Then my account is created and I am logged in 26 272. Given I enter an email that's already registered 28 When I submit the form 29 Then I see an error message and a link to sign in 30 313. Given I enter an invalid email format 32 When I try to submit 33 Then I see a validation error before submission 34 35**Edge Cases:** 36- Password doesn't meet requirements (show requirements) 37- Email domain is blocked (company policy) 38- User abandons mid-flow (save progress?) 39 40**Priority:** P0 (Must have for launch) 41**Estimate:** 3 story points 42 43--- 44 45#### Story 2: Social Login 46**As a** new or returning user 47**I want to** sign in with Google or GitHub 48**So that** I don't need to remember another password 49 50**Acceptance Criteria:** 511. Given I am on the sign-in page 52 When I click "Sign in with Google" 53 Then I am redirected to Google OAuth 54 And upon success, I am logged in 55 562. Given I already have an account with that email 57 When I sign in with Google 58 Then my accounts are linked automatically 59 60**Priority:** P1 (Should have for launch) 61**Estimate:** 2 story points

Requirements Documentation:

1## Functional Requirements 2 3### FR1: User Management 4| ID | Requirement | Priority | Notes | 5|----|-------------|----------|-------| 6| FR1.1 | Users can register with email/password | P0 | | 7| FR1.2 | Users can sign in with Google OAuth | P1 | Use next-auth | 8| FR1.3 | Users can reset forgotten password | P0 | Email flow | 9| FR1.4 | Users can update profile information | P1 | | 10| FR1.5 | Users can delete their account | P2 | GDPR requirement | 11 12### FR2: Project Management 13| ID | Requirement | Priority | Notes | 14|----|-------------|----------|-------| 15| FR2.1 | Users can create new projects | P0 | | 16| FR2.2 | Users can invite team members | P0 | | 17| FR2.3 | Projects have role-based access | P1 | Admin, Editor, Viewer | 18| FR2.4 | Projects can be archived | P2 | | 19 20## Non-Functional Requirements 21 22### Performance 23| ID | Requirement | Target | Notes | 24|----|-------------|--------|-------| 25| NFR1.1 | Page load time | < 2 seconds | Core Web Vitals | 26| NFR1.2 | API response time | < 200ms p95 | | 27| NFR1.3 | Concurrent users | 1,000 | Initial target | 28 29### Security 30| ID | Requirement | Notes | 31|----|-------------|-------| 32| NFR2.1 | All data encrypted in transit (TLS) | | 33| NFR2.2 | Passwords hashed with bcrypt | | 34| NFR2.3 | Session tokens expire after 24h | | 35| NFR2.4 | Rate limiting on auth endpoints | | 36 37### Reliability 38| ID | Requirement | Target | 39|----|-------------|--------| 40| NFR3.1 | Uptime | 99.9% | 41| NFR3.2 | Data backup frequency | Daily | 42| NFR3.3 | Recovery time objective | < 4 hours | 43 44### Usability 45| ID | Requirement | Notes | 46|----|-------------|-------| 47| NFR4.1 | Mobile responsive | All core flows | 48| NFR4.2 | Accessibility | WCAG 2.1 AA | 49| NFR4.3 | Browser support | Chrome, Safari, Firefox, Edge |

Phase 3: Prioritization & MVP Scope (2-3 days)#

Agents: business-analyst

Prioritize features and define MVP scope.

Tasks:

  • Apply prioritization framework
  • Define MVP scope
  • Create feature roadmap
  • Identify dependencies
  • Get stakeholder alignment

Prioritization Framework:

1## RICE Scoring Framework 2 3### Scoring Criteria 4 5**Reach** (0-10): How many users will this impact? 6- 10: All users, every session 7- 5: Most users, occasionally 8- 1: Few users, rarely 9 10**Impact** (0-3): How much will it impact those users? 11- 3: Massive impact (10x better) 12- 2: High impact (2x better) 13- 1: Medium impact (notable improvement) 14- 0.5: Low impact (minor improvement) 15 16**Confidence** (0-100%): How confident are we? 17- 100%: High confidence (data-driven) 18- 80%: Medium confidence (qualitative research) 19- 50%: Low confidence (gut feeling) 20 21**Effort** (person-weeks): How much work? 22- Estimate in person-weeks of effort 23 24**RICE Score = (Reach × Impact × Confidence) / Effort** 25 26### Feature Prioritization 27 28| Feature | Reach | Impact | Confidence | Effort | RICE Score | Priority | 29|---------|-------|--------|------------|--------|------------|----------| 30| Email auth | 10 | 3 | 100% | 2 | 15.0 | P0 | 31| Google OAuth | 8 | 2 | 80% | 1 | 12.8 | P1 | 32| Team invites | 7 | 3 | 90% | 3 | 6.3 | P0 | 33| Dark mode | 6 | 0.5 | 50% | 1 | 1.5 | P2 | 34| API access | 3 | 2 | 70% | 4 | 1.1 | P2 |

MVP Scope Definition:

1## MVP Scope 2 3### In Scope (Must Ship) 4 5**User Authentication** 6- [ ] Email/password registration 7- [ ] Email/password sign in 8- [ ] Password reset flow 9- [ ] Session management 10 11**Core Feature: [Feature Name]** 12- [ ] [Sub-feature 1] 13- [ ] [Sub-feature 2] 14- [ ] [Sub-feature 3] 15 16**Essential Infrastructure** 17- [ ] Error tracking (Sentry) 18- [ ] Basic analytics (Posthog) 19- [ ] Email sending (Resend) 20 21### Out of Scope (Post-MVP) 22 23| Feature | Reason | Planned Release | 24|---------|--------|-----------------| 25| Google OAuth | Nice-to-have, not blocking | v1.1 | 26| Team features | Need single-user feedback first | v1.2 | 27| Mobile app | Web-first approach | v2.0 | 28| API access | B2B feature, validate B2C first | v2.0 | 29 30### Scope Boundaries 31 32**We WILL:** 33- Support web browsers only (no native apps) 34- Target English-speaking users only 35- Support single-user accounts (no teams) 36- Focus on core workflow only 37 38**We WON'T:** 39- Build admin panel (use database directly) 40- Support multiple languages 41- Build team/collaboration features 42- Offer API access 43- Support legacy browsers (IE11)

Phase 4: Success Metrics & Measurement (1-2 days)#

Agents: business-analyst, backend-expert

Define how success will be measured.

Tasks:

  • Define success metrics
  • Set baseline and targets
  • Plan measurement implementation
  • Create analytics dashboard spec
  • Define experiment framework

Success Metrics Framework:

1## Success Metrics 2 3### Primary Metrics (North Star) 4 5| Metric | Current | Target | Timeline | 6|--------|---------|--------|----------| 7| Weekly Active Users (WAU) | 0 | 500 | 90 days | 8| Activation Rate | N/A | 40% | 90 days | 9| Retention (D7) | N/A | 30% | 90 days | 10 11### Secondary Metrics 12 13| Metric | Target | Measurement | 14|--------|--------|-------------| 15| Sign-up conversion | 20% | Visitors → Signed up | 16| Onboarding completion | 70% | Signed up → Completed onboarding | 17| Feature adoption | 60% | Users using core feature | 18| NPS | > 30 | Monthly survey | 19| Time to value | < 5 min | Sign up → First success | 20 21### Guardrail Metrics 22Metrics that must not degrade: 23 24| Metric | Threshold | 25|--------|-----------| 26| Error rate | < 1% | 27| Page load time | < 3 seconds | 28| Support tickets/user | < 0.1/week | 29 30### Measurement Plan 31 32```typescript 33// lib/analytics/events.ts 34 35export const ANALYTICS_EVENTS = { 36 // Acquisition 37 PAGE_VIEW: 'page_view', 38 SIGN_UP_STARTED: 'sign_up_started', 39 SIGN_UP_COMPLETED: 'sign_up_completed', 40 41 // Activation 42 ONBOARDING_STARTED: 'onboarding_started', 43 ONBOARDING_STEP_COMPLETED: 'onboarding_step_completed', 44 ONBOARDING_COMPLETED: 'onboarding_completed', 45 FIRST_PROJECT_CREATED: 'first_project_created', 46 47 // Engagement 48 FEATURE_USED: 'feature_used', 49 SESSION_STARTED: 'session_started', 50 SESSION_ENDED: 'session_ended', 51 52 // Retention 53 RETURNED_USER: 'returned_user', 54 CHURNED_USER: 'churned_user', 55 56 // Revenue (future) 57 UPGRADE_STARTED: 'upgrade_started', 58 UPGRADE_COMPLETED: 'upgrade_completed', 59}; 60 61export function trackEvent( 62 event: keyof typeof ANALYTICS_EVENTS, 63 properties?: Record<string, unknown> 64) { 65 // Implementation 66}

Analytics Dashboard Spec#

Dashboard 1: Acquisition

  • Daily sign-ups (trend chart)
  • Sign-up source breakdown (pie chart)
  • Conversion funnel (visitor → sign-up)

Dashboard 2: Activation

  • Onboarding completion rate
  • Time to first value
  • Drop-off by onboarding step

Dashboard 3: Engagement

  • DAU/WAU/MAU
  • Session frequency distribution
  • Feature usage breakdown

Dashboard 4: Retention

  • Cohort retention curves
  • D1/D7/D30 retention rates
  • Churn rate trend
## Complete PRD Template ```markdown # [Product Name] PRD ## Document Info [Header section from Phase 1] ## Executive Summary [Problem statement, target user, proposed solution] ## Background [Context, prior art, constraints] ## User Personas [1-3 user personas] ## User Stories [Prioritized list of user stories with acceptance criteria] ## Functional Requirements [Detailed functional requirements table] ## Non-Functional Requirements [Performance, security, reliability, usability] ## MVP Scope [In scope, out of scope, scope boundaries] ## User Flows [Diagrams or descriptions of key flows] ## Wireframes / Mockups [Links to design files] ## Technical Considerations [Architecture notes, API contracts, data models] ## Success Metrics [Primary, secondary, guardrail metrics] ## Timeline & Milestones [High-level project timeline] ## Open Questions [Unresolved questions and decisions] ## Appendix [Research, competitive analysis, meeting notes]

Starting the Workflow#

1# Start PRD workflow 2bootspring workflow start seed-prd 3 4# Create new PRD 5bootspring seed prd create --name "My Feature" 6 7# Add user story 8bootspring seed prd story add 9 10# Prioritize features 11bootspring seed prd prioritize 12 13# Generate PRD document 14bootspring seed prd export

Deliverables#

A successful PRD workflow produces:

  • Complete PRD document
  • User personas (1-3)
  • Prioritized user stories with acceptance criteria
  • Requirements documentation (functional & non-functional)
  • MVP scope definition
  • Success metrics with targets
  • Wireframes or flow diagrams (optional)

Best Practices#

  1. Start with the problem - Not features
  2. Write for your audience - Technical details for engineers, outcomes for stakeholders
  3. Keep it living - Update as you learn
  4. Include the "why" - Decisions need context
  5. Be specific - Vague requirements cause delays
  6. Define "done" - Clear acceptance criteria

Common Pitfalls#

  • Writing a solution, not requirements
  • Too much detail too early
  • No prioritization (everything is P0)
  • Missing non-functional requirements
  • No success metrics
  • PRD as a one-time document

Related Workflows#