MODULE 15
PRD Creation
Translate validated discovery into a clear Product Requirements Document.
Writing an Effective PRD
What is a PRD?
A Product Requirements Document captures what is being built, why (linked to discovery evidence), and the requirements/criteria for success — the handoff point from discovery to delivery.
Core Sections of a Strong PRD
- Problem & evidence — the validated problem statement, JTBD, and supporting research (link back to Modules 4 & 9–10).
- Goal & success metrics — the outcome this should drive and how it'll be measured (ties to Module 11).
- Target users — which segment/persona this is for, and why.
- Scope — what's in and explicitly out, to prevent scope creep.
- Requirements — functional requirements, edge cases, and any non-functional needs (performance, accessibility, compliance).
- Open questions/risks — remaining unknowns and assumptions still to validate during build.
PRD Best Practices
- Keep it living — update as new evidence or constraints emerge during delivery, don't treat it as frozen the day it's written.
- Write requirements as outcomes/criteria where possible ("user can recover a forgotten password in under 2 minutes") rather than overly prescriptive implementation detail, leaving room for design/engineering judgment.
- Always link back to the discovery evidence — a PRD with no "why" invites debate over priorities later.
Common PRD Mistakes
- Treating the PRD as the start of thinking rather than a summary of validated discovery work.
- Specifying solutions in excessive technical detail that should be left to engineering/design.
- Omitting success metrics, making it impossible to know after launch whether the feature worked.
Module Quiz
Answer all 5 questions and submit to check your understanding.
1. A PRD primarily serves as:
2. Which section ties a PRD back to Module 11 (Discovery Metrics)?
3. Why should a PRD link back to discovery evidence?
4. A common PRD mistake is:
5. Should a PRD be treated as frozen once written?