Context Slice PRD Writing Guide
What Makes a Good PRD
A good PRD enables the team to:
- Understand why we're building this
- Know what to build (and what not to)
- Estimate effort and identify dependencies
- Make tradeoff decisions without PM involvement
- Know when it's done
Structure
# [Feature Name]
## Overview
[Problem statement, solution, why now - 2-3 paragraphs]
## Goals & Success Metrics
### Goals
- [Primary goal]
- [Secondary goal]
### Success Metrics
- [Metric 1] — current: [X], target: [Y]
- [Metric 2] — current: [X], target: [Y]
### Non-Goals
- [Explicitly out of scope]
## User Stories
- As a [user], I want to [action] so that [outcome]
## Requirements
### Functional
- [Requirement 1]
- [Requirement 2]
### Non-Functional
- Performance: [targets]
- Security: [requirements]
- Scale: [expectations]
### Edge Cases
- [Edge case]: [how to handle]
## Design Considerations
- [UX notes]
- [Technical considerations]
## Open Questions
- [Question needing answer before dev]
## Launch Plan
- Phase 1: [scope]
- Success criteria to expand: [metric]Problem Statement
Bad:
Users want better search.
Good:
Users report that search returns irrelevant results, with 40% of searches requiring multiple attempts. Exit surveys show "can't find what I need" as the #2 reason for churn. Improving search relevance could reduce support tickets by 25% and improve conversion by 10%.
Include:
- Who has the problem
- How big is the problem (data if available)
- What happens if we don't solve it
- Why now
Goals & Non-Goals
Goals Should Be
- Specific and measurable
- Tied to business outcomes
- Achievable with this scope
Bad: "Make search better"
Good: "Reduce zero-result searches from 15% to 5%"
Non-Goals Are Critical
Explicitly state what you're NOT doing:
- "We are not changing the search UI in this phase"
- "Personalized search is out of scope"
This prevents scope creep and aligns expectations.
User Stories
Format: As a [user], I want to [action] so that [outcome]
Bad:
As a user, I want better search.
Good:
As a shopper searching for running shoes, I want to filter by my size so that I only see products I can actually buy.
Cover:
- Primary use case (80% of users)
- Secondary use cases
- Edge cases that affect UX
Requirements
Functional Requirements
Be specific enough to implement:
Bad: "Users can filter search results"
Good: "Users can filter by: category (multi-select), price range (min/max), availability (in-stock only), rating (1-5 stars)"
Non-Functional Requirements
- Performance: "Search results return in <200ms p95"
- Scale: "Support 1000 concurrent searches"
- Security: "No PII in search logs"
- Accessibility: "WCAG 2.1 AA compliant"
Edge Cases
| Scenario | Handling |
|---|---|
| No results | Show "No results" with suggestions |
| Query too short | Require 3+ characters |
| Special characters | Escape and search |
Success Metrics
Format: [Metric] — current: [X], target: [Y], timeline: [when]
Examples:
- Zero-result rate — current: 15%, target: 5%, timeline: 30 days post-launch
- Search-to-purchase conversion — current: 2%, target: 3%, timeline: 60 days
- Support tickets re: search — current: 50/week, target: 25/week
Open Questions vs Assumptions
Open Questions = Need answers before development
- "Do we index out-of-stock products?"
- "What's the SLA for search index updates?"
Assumptions = Decisions made to move forward
- "Assuming we can reuse existing Elasticsearch cluster"
- "Assuming design will provide search result card specs"
Call out assumptions explicitly—they often turn into blockers.
Common PRD Mistakes
| Mistake | Fix |
|---|---|
| Solution-first writing | Start with problem, validate solution fit |
| Vague requirements | Specific enough for engineering estimate |
| Missing edge cases | Walk through user flows, find branches |
| No success metrics | If you can't measure it, how do you know it worked? |
| Scope creep in doc | Be ruthless about non-goals |
| Writing in isolation | Get eng/design input before finalizing |
PRD Anti-Patterns
Solution-First Writing — Starting with "we should build X" before establishing the problem. Red flag: PRD jumps straight to features without evidence of user pain.
Feature-List PRD — Just a bullet list of requirements with no context. Engineering can build it but doesn't know why, leading to poor tradeoff decisions.
Spec-by-Committee — PRD tries to please everyone, scope balloons, non-goals are empty. Result: 6-month project that ships nothing.
Metrics Theater — Success metrics that sound good but aren't measurable or connected to the feature. "Improve user satisfaction" instead of "Reduce task completion time from 5min to 2min."
Assumption Blindness — Critical assumptions buried or unstated. The PRD assumes eng capacity, design availability, or technical feasibility without calling it out.