# Writing PRDs Walkthrough — Learn by Doing ## Before We Begin **Diagnostic:** When someone asks for a feature, are they describing the *problem* or the *solution*? If a stakeholder says "We need a dark mode button," what problem might they actually be trying to solve? How would you find out? **Checkpoint:** You can restate a feature request as a problem (a user need or pain) without mentioning the proposed fix. --- ## Step 1: Problem or Solution? Before writing anything, distinguish problem from solution. **Task:** Choose a real or hypothetical product area (e.g., "onboarding," "search," "notifications"). Write one sentence that describes a *problem* a user has, and one sentence that describes a *solution*. Make sure the problem stands alone—it should make sense even if the solution never existed. **Question:** If you showed your problem statement to someone who had never seen your solution, would they understand the pain? Or would they only understand it in terms of your proposed fix? **Checkpoint:** The user can articulate a problem without mentioning any feature or UI. --- ## Step 2: Write a Problem Statement **Task:** Expand your one-sentence problem into a 2–3 sentence problem statement. Include: who has the problem, what the pain is, and why it matters (impact). Avoid any mention of solutions. **Question:** What happens if you flip your statement and ask "So what?" repeatedly? Does each "so what?" lead to a clearer, more concrete outcome? **Checkpoint:** The problem statement is user-centered and avoids solution language. --- ## Step 3: Apply JTBD **Task:** Restate your problem using the Jobs To Be Done format: *When [situation], I want to [motivation], so I can [outcome].* Write 2–3 variations with different situations or outcomes. **Question:** Does the JTBD wording reveal any assumptions you had about *who* the user is or *when* they experience this? Could there be different "jobs" for different segments? **Checkpoint:** The user produces at least one valid JTBD statement that maps to their problem. --- ## Step 4: Define Success Metrics **Task:** For your problem, define 1–2 success metrics. For each: name the metric, state the current baseline (or "unknown" if you don't have data), and set a target with a timeframe. **Question:** If you hit your target, would that *prove* you solved the problem? Or could the metric improve for unrelated reasons? **Checkpoint:** Metrics are specific, measurable, and tied to the problem. --- ## Step 5: Add Non-Goals **Task:** List 2–3 things that are explicitly **out of scope** for this initiative. These are things stakeholders might assume are included but you're intentionally excluding. **Question:** Why is it as important to define what you're *not* doing as what you are? What happens when non-goals are missing? **Checkpoint:** Non-goals are concrete and would prevent common scope-creep scenarios. --- ## Step 6: Draft a Minimal PRD **Task:** Combine your problem statement, JTBD, success metrics, and non-goals into a minimal PRD. Add a "User Stories" section with 2–3 stories that support the goals. **Question:** If an engineer read this PRD tomorrow, what would they still need to ask you? What's missing? **Checkpoint:** The PRD has clear sections and could be shared for feedback. --- ## Step 7: Review for Anti-Patterns **Task:** Re-read your PRD. Check for: solution-first language, vague metrics, missing non-goals, and hidden assumptions. Revise at least one section. **Question:** Which anti-pattern are you most likely to slip into in your own work? How could you catch it next time? **Checkpoint:** The user identifies and fixes at least one anti-pattern in their draft.