How to Write a Product Spec (With Template)
A practical guide to writing PRDs that engineers love. Includes templates, examples, and advice on balancing detail with flexibility.
What a Product Spec Is For
A product spec (or PRD—Product Requirements Document) is your thinking made concrete. It's not documentation for documentation's sake; it's a tool to:
- Align your team
- Clarify your thinking
- Enable engineers to build what you intend
The best specs answer every question an engineer will have before they start building. What are we building? Why? For whom? What's in scope? What's out? What does success look like? What are the edge cases?
Specs also serve as accountability. They're a record of what you decided and why. When someone asks "why didn't we build X?" you can point to the spec. When scope creeps, you can point to the spec.
The Core Structure
Every spec needs four essentials:
| Component | Description |
|---|---|
| Problem | Why are we doing this? |
| Solution | What are we building? |
| Scope | What's included and excluded? |
| Success Metrics | How will we know if it worked? |
Everything else is supporting detail.
Different companies use different templates, but the fundamentals are the same. Don't get lost in format.
A clear spec in a plain Google Doc beats a confusing spec in a fancy tool.
Length varies by complexity. A small feature might be one page. A new product might be ten. The right length is "enough to be unambiguous," not "as long as possible."
Problem Statement
Start with why this matters:
- What user problem or business need are you addressing?
- Who has this problem?
- How painful is it?
Make It Real
Use data and user quotes:
| ❌ Vague | ✅ Specific |
|---|---|
| "Some users have checkout problems" | "23% of users drop off at checkout" |
| "Users are frustrated" | "One user said: I gave up after the third error" |
The problem statement is your permission to build. If you can't articulate a compelling problem, you shouldn't be building the solution.
Goals and Success Metrics
Define what success looks like before building:
- What metrics will improve if this works?
- By how much?
- By when?
This forces clarity on outcomes.
Primary and Guardrail Metrics
| Type | Purpose | Example |
|---|---|---|
| Primary | What you're optimizing for | Checkout conversion |
| Guardrail | What you don't want to hurt | Mobile experience |
If you can't define success metrics, you're either building the wrong thing or you don't understand the problem well enough. Go back to discovery.
Solution Overview
Describe the solution at a high level before diving into details:
- What is the user experience?
- How does it solve the problem?
A one-paragraph summary that anyone could understand.
Visuals Help
Include mockups, wireframes, or user flows if they help. Visuals often communicate faster than words. But don't over-polish—sketches are fine at the spec stage.
Explain the Why
"We chose tabs over accordion because user research showed users want to compare options side-by-side."
This helps engineers make consistent decisions when they encounter edge cases.
Detailed Requirements
This is where you get specific:
- What happens when the user clicks this button?
- What does the error state look like?
- What are the validation rules?
- What are the edge cases?
Use Structured Formats
User stories:
"As a [user], I can [action], so that [benefit]."
Acceptance criteria:
"Given [context], when [action], then [expected result]."
This structure forces clarity.
Don't write technical requirements unless you have to. Describe what the user experiences, not how the code should work. Engineers will find better implementations than you would.
Scope and Non-Goals
Explicitly list what's out of scope. This prevents scope creep and clarifies priorities:
- "We will not support mobile in v1"
- "We will not handle the enterprise use case yet"
Non-Goals vs. Never
Non-goals are different from "never doing." They're "not doing now."
"Mobile is out of scope for this release but planned for Q3."
Scope discussions should happen before spec finalization. If stakeholders want something out of scope, discuss it and make a decision. Don't let scope expand silently.
Technical Considerations
Include technical context that affects the solution:
- API constraints
- Performance requirements
- Dependencies on other teams
- Data model implications
Know Your Boundaries
| ✅ Your Job | ❌ Overstepping |
|---|---|
| "We need to handle 10,000 requests per second" | "Use Redis for caching" |
Flag things you're uncertain about: "I think we can reuse the existing notification system, but engineering should validate." Acknowledging uncertainty is better than pretending you know.
Timeline and Phases
If the work spans multiple sprints or has phases, describe the breakdown:
"Phase 1 (2 weeks): MVP with basic flow. Phase 2 (3 weeks): Add edge cases and analytics."
Avoid Specific Dates
Don't commit to specific dates if you can avoid it. Phases or relative timing is better:
| ❌ Risky | ✅ Better |
|---|---|
| "Phase 2 ships March 15" | "After Phase 1 ships, we'll start Phase 2" |
Engineering should own the timeline estimate, not you. Your job is to clarify scope; theirs is to estimate effort. Collaborate, don't dictate.
Open Questions and Risks
Open Questions
List things you don't know yet:
"Open question: Should we require email verification? Need to check with legal."
This shows you've thought about gaps and prevents surprises.
Risks
Include risks with mitigations:
"Risk: Third-party API has inconsistent response times. Mitigation: Implement caching."
Identifying risks proactively shows strategic thinking.
It's okay to not have all the answers. A spec with acknowledged open questions is more honest than a spec pretending completeness.
Working With Engineers on Specs
Collaborate Early
Don't write specs in isolation. Loop in engineering leads early. They'll:
- Catch feasibility issues
- Suggest better approaches
- Flag technical constraints you've missed
Expect Iteration
The first draft is never final. Engineers will ask clarifying questions. Stakeholders will request changes. Version your specs and track what changed.
After Shipping
Update the spec with what actually happened. This creates a historical record and helps you improve future specs.
Get the weekly digest of top product people & jobs
One email a week. No spam.