# Writing PRDs — From Problem to Spec

<!-- hint:slides topic="PRD writing: problem-first thinking, JTBD, PRD structure, stakeholder alignment, and common anti-patterns" slides="5" -->

## What Is a PRD?

A **Product Requirements Document (PRD)** is a living document that defines what you're building, why, and for whom. It bridges the gap between strategy and execution—giving engineering, design, and stakeholders a shared understanding before a single line of code is written.

A good PRD answers: *What problem are we solving?* and *How will we know we succeeded?*

## Why PRDs Matter

Without a PRD, teams often:

- Build solutions before validating the problem
- Scope creep from unclear boundaries
- Disagree on "done" because success was never defined
- Waste cycles re-explaining the same context

A well-crafted PRD aligns everyone, reduces ambiguity, and makes prioritization decisions traceable.

## PRD Structure

A typical PRD includes these sections:

| Section | Purpose |
|---------|---------|
| **Problem Statement** | Clear description of the user/customer pain |
| **Goals & Non-Goals** | What we will and won't do (prevents scope creep) |
| **User Stories / Use Cases** | Who does what and why |
| **Success Metrics** | Measurable outcomes (quantified) |
| **Scope** | In/out of scope, phased approach |
| **Timeline** | High-level milestones |
| **Open Questions** | Known unknowns, risks, dependencies |

## Writing Effective Problem Statements

A problem statement is **not** a solution in disguise. It focuses on the pain, not the fix.

**Weak:** "Users need a dark mode toggle."

**Strong:** "Users report eye strain when using the app for extended sessions in low-light environments, leading to reduced engagement after 30+ minutes."

The **Jobs To Be Done (JTBD)** framework helps: *When [situation], I want to [motivation], so I can [outcome].*

Example: *When I'm reviewing a long PR diff, I want to quickly spot high-risk changes, so I can focus my review time where it matters.*

## Defining Measurable Success Criteria

Vague metrics ("improve user satisfaction") are hard to act on. Make them **SMART**:

- **Specific:** Which metric (e.g., NPS, retention, task completion)?
- **Measurable:** Can we track it in our systems?
- **Achievable:** Is it realistic given scope?
- **Relevant:** Does it tie to the problem?
- **Time-bound:** By when?

**Example:** "Reduce time-to-first-value for new users from 14 days to 7 days within Q2, measured by cohort analysis."

## JTBD Framework

Jobs To Be Done reframes features as outcomes:

| Element | Example |
|---------|---------|
| **Job** | Get my team aligned on the sprint |
| **Situation** | End of planning, many opinions |
| **Motivation** | Capture decisions and next steps |
| **Outcome** | Everyone leaves with clarity on who does what |

Using JTBD in your PRD keeps the focus on user value, not feature lists.

## Common PRD Anti-Patterns

1. **Solution-first thinking** — Starting with "We need a search bar" instead of "Users can't find what they need."
2. **Vague success metrics** — "Improve engagement" with no baseline or target.
3. **Missing non-goals** — Stakeholders assume everything is in scope.
4. **No open questions** — Pretending uncertainty doesn't exist.
5. **Waterfall rigidity** — Treating the PRD as unchangeable instead of iterative.

## PRD Lifecycle: Problem → Build

```mermaid
flowchart LR
  A[Problem] --> B[Research]
  B --> C[PRD]
  C --> D[Review]
  D --> E[Build]
  E -.->|feedback| B
```

1. **Problem** — Identify the pain point or opportunity.
2. **Research** — User interviews, data, competitive analysis.
3. **PRD** — Document findings, goals, and scope.
4. **Review** — Stakeholder alignment, design/engineering input.
5. **Build** — Execution with feedback loops back to research.

## Templates

Use a consistent template so your PRDs are comparable and complete. A minimal template:

```markdown
# [Feature Name]

## Problem
[1–2 paragraphs: who has the problem, what it is, why it matters]

## Goals
- [Goal 1]
- [Goal 2]

## Non-Goals
- [What we're explicitly NOT doing]

## Success Metrics
- [Metric]: [Baseline] → [Target] by [Date]

## User Stories
- As a [persona], I want [action], so that [outcome]

## Scope
- In scope: ...
- Out of scope: ...
- Phase 2 considerations: ...

## Open Questions
- [Question 1]
- [Question 2]
```

---

PRDs are communication tools. A great PRD doesn't have to be long—it has to be **clear**. When in doubt, start with the problem statement and success metrics. Everything else supports those two.