|
| 1 | +# BMAD PRD Purpose |
| 2 | + |
| 3 | +**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## What is a BMAD PRD? |
| 8 | + |
| 9 | +A dual-audience document serving: |
| 10 | +1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication |
| 11 | +2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents |
| 12 | + |
| 13 | +Each successive document becomes more AI-tailored and granular. |
| 14 | + |
| 15 | +--- |
| 16 | + |
| 17 | +## Core Philosophy: Information Density |
| 18 | + |
| 19 | +**High Signal-to-Noise Ratio** |
| 20 | + |
| 21 | +Every sentence must carry information weight. LLMs consume precise, dense content efficiently. |
| 22 | + |
| 23 | +**Anti-Patterns (Eliminate These):** |
| 24 | +- ❌ "The system will allow users to..." → ✅ "Users can..." |
| 25 | +- ❌ "It is important to note that..." → ✅ State the fact directly |
| 26 | +- ❌ "In order to..." → ✅ "To..." |
| 27 | +- ❌ Conversational filler and padding → ✅ Direct, concise statements |
| 28 | + |
| 29 | +**Goal:** Maximum information per word. Zero fluff. |
| 30 | + |
| 31 | +--- |
| 32 | + |
| 33 | +## The Traceability Chain |
| 34 | + |
| 35 | +**PRD starts the chain:** |
| 36 | +``` |
| 37 | +Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories) |
| 38 | +``` |
| 39 | + |
| 40 | +**In the PRD, establish:** |
| 41 | +- Vision → Success Criteria alignment |
| 42 | +- Success Criteria → User Journey coverage |
| 43 | +- User Journey → Functional Requirement mapping |
| 44 | +- All requirements traceable to user needs |
| 45 | + |
| 46 | +**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing. |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +## What Makes Great Functional Requirements? |
| 51 | + |
| 52 | +### FRs are Capabilities, Not Implementation |
| 53 | + |
| 54 | +**Good FR:** "Users can reset their password via email link" |
| 55 | +**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage) |
| 56 | + |
| 57 | +**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile" |
| 58 | +**Bad FR:** "Fast loading time" (subjective, unmeasurable) |
| 59 | + |
| 60 | +### SMART Quality Criteria |
| 61 | + |
| 62 | +**Specific:** Clear, precisely defined capability |
| 63 | +**Measurable:** Quantifiable with test criteria |
| 64 | +**Attainable:** Realistic within constraints |
| 65 | +**Relevant:** Aligns with business objectives |
| 66 | +**Traceable:** Links to source (executive summary or user journey) |
| 67 | + |
| 68 | +### FR Anti-Patterns |
| 69 | + |
| 70 | +**Subjective Adjectives:** |
| 71 | +- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive" |
| 72 | +- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds" |
| 73 | + |
| 74 | +**Implementation Leakage:** |
| 75 | +- ❌ Technology names, specific libraries, implementation details |
| 76 | +- ✅ Focus on capability and measurable outcomes |
| 77 | + |
| 78 | +**Vague Quantifiers:** |
| 79 | +- ❌ "multiple users", "several options", "various formats" |
| 80 | +- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats" |
| 81 | + |
| 82 | +**Missing Test Criteria:** |
| 83 | +- ❌ "The system shall provide notifications" |
| 84 | +- ✅ "The system shall send email notifications within 30 seconds of trigger event" |
| 85 | + |
| 86 | +--- |
| 87 | + |
| 88 | +## What Makes Great Non-Functional Requirements? |
| 89 | + |
| 90 | +### NFRs Must Be Measurable |
| 91 | + |
| 92 | +**Template:** |
| 93 | +``` |
| 94 | +"The system shall [metric] [condition] [measurement method]" |
| 95 | +``` |
| 96 | + |
| 97 | +**Examples:** |
| 98 | +- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring" |
| 99 | +- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA" |
| 100 | +- ✅ "The system shall support 10,000 concurrent users as measured by load testing" |
| 101 | + |
| 102 | +### NFR Anti-Patterns |
| 103 | + |
| 104 | +**Unmeasurable Claims:** |
| 105 | +- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling" |
| 106 | +- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA" |
| 107 | + |
| 108 | +**Missing Context:** |
| 109 | +- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load" |
| 110 | + |
| 111 | +--- |
| 112 | + |
| 113 | +## Domain-Specific Requirements |
| 114 | + |
| 115 | +**Auto-Detect and Enforce Based on Project Context** |
| 116 | + |
| 117 | +Certain industries have mandatory requirements that must be present: |
| 118 | + |
| 119 | +- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA |
| 120 | +- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails |
| 121 | +- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency |
| 122 | +- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction |
| 123 | + |
| 124 | +**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv. |
| 125 | + |
| 126 | +--- |
| 127 | + |
| 128 | +## Document Structure (Markdown, Human-Readable) |
| 129 | + |
| 130 | +### Required Sections |
| 131 | +1. **Executive Summary** - Vision, differentiator, target users |
| 132 | +2. **Success Criteria** - Measurable outcomes (SMART) |
| 133 | +3. **Product Scope** - MVP, Growth, Vision phases |
| 134 | +4. **User Journeys** - Comprehensive coverage |
| 135 | +5. **Domain Requirements** - Industry-specific compliance (if applicable) |
| 136 | +6. **Innovation Analysis** - Competitive differentiation (if applicable) |
| 137 | +7. **Project-Type Requirements** - Platform-specific needs |
| 138 | +8. **Functional Requirements** - Capability contract (FRs) |
| 139 | +9. **Non-Functional Requirements** - Quality attributes (NFRs) |
| 140 | + |
| 141 | +### Formatting for Dual Consumption |
| 142 | + |
| 143 | +**For Humans:** |
| 144 | +- Clear, professional language |
| 145 | +- Logical flow from vision to requirements |
| 146 | +- Easy for stakeholders to review and approve |
| 147 | + |
| 148 | +**For LLMs:** |
| 149 | +- ## Level 2 headers for all main sections (enables extraction) |
| 150 | +- Consistent structure and patterns |
| 151 | +- Precise, testable language |
| 152 | +- High information density |
| 153 | + |
| 154 | +--- |
| 155 | + |
| 156 | +## Downstream Impact |
| 157 | + |
| 158 | +**How the PRD Feeds Next Artifacts:** |
| 159 | + |
| 160 | +**UX Design:** |
| 161 | +- User journeys → interaction flows |
| 162 | +- FRs → design requirements |
| 163 | +- Success criteria → UX metrics |
| 164 | + |
| 165 | +**Architecture:** |
| 166 | +- FRs → system capabilities |
| 167 | +- NFRs → architecture decisions |
| 168 | +- Domain requirements → compliance architecture |
| 169 | +- Project-type requirements → platform choices |
| 170 | + |
| 171 | +**Epics & Stories (created after architecture):** |
| 172 | +- FRs → user stories (1 FR could map to 1-3 stories potentially) |
| 173 | +- Acceptance criteria → story acceptance tests |
| 174 | +- Priority → sprint sequencing |
| 175 | +- Traceability → stories map back to vision |
| 176 | + |
| 177 | +**Development AI Agents:** |
| 178 | +- Precise requirements → implementation clarity |
| 179 | +- Test criteria → automated test generation |
| 180 | +- Domain requirements → compliance enforcement |
| 181 | +- Measurable NFRs → performance targets |
| 182 | + |
| 183 | +--- |
| 184 | + |
| 185 | +## Summary: What Makes a Great BMAD PRD? |
| 186 | + |
| 187 | +✅ **High Information Density** - Every sentence carries weight, zero fluff |
| 188 | +✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria |
| 189 | +✅ **Clear Traceability** - Each requirement links to user need and business objective |
| 190 | +✅ **Domain Awareness** - Industry-specific requirements auto-detected and included |
| 191 | +✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers |
| 192 | +✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable |
| 193 | +✅ **Markdown Format** - Professional, clean, accessible to all stakeholders |
| 194 | + |
| 195 | +--- |
| 196 | + |
| 197 | +**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective. |
0 commit comments