Context Slice When to Use a Brief vs PRD
Use a brief when you need quick alignment without full specification detail:
| Situation | Use |
|---|---|
| Early exploration, gauging interest | Brief |
| Stakeholder buy-in before deep investment | Brief |
| Small features (< 2 weeks work) | Brief |
| Full engineering handoff | PRD |
| Complex features with multiple phases | PRD |
| Features requiring detailed acceptance criteria | PRD |
A brief is a conversation starter. A PRD is a contract.
One-Pager Template
# [Feature Name] — One-Pager
**Author:** [Name] | **Date:** [Date] | **Status:** [Proposed / Approved / In Progress]
## The Problem
[2-3 sentences describing the problem. Be specific about who experiences this and what impact it has.]
## Proposed Solution
[1 paragraph describing the approach. Focus on what it does for users, not implementation details.]
## Key Requirements
- **Must have:** [Core capability that defines success]
- **Must have:** [Another essential requirement]
- **Should have:** [Important but not blocking]
- **Nice to have:** [If time permits]
## Success Metrics
| Metric | Target | How We'll Know |
|--------|--------|----------------|
| [Primary metric] | [Goal] | [Measurement method] |
| [Secondary metric] | [Goal] | [Measurement method] |
## Timeline & Next Steps
- **Estimated effort:** [T-shirt size or week estimate]
- **Target launch:** [Date or quarter]
- **Next step:** [Specific action and owner]
## Open Questions
- [Question that needs resolution before proceeding]Feature Brief Template
For features that need slightly more structure than a one-pager but less than a full PRD:
# [Feature Name] Brief
**Author:** [Name] | **Last Updated:** [Date]
**Status:** [Draft / In Review / Approved]
## Summary
[2-3 sentence executive summary. What are we building and why?]
## Problem Statement
### The Problem
[Describe the problem users face. Be specific about context and frequency.]
### Evidence
- [User feedback, data point, or support ticket theme]
- [Additional evidence]
### Impact
[What happens if we don't solve this? Quantify if possible.]
## User Story
**As a** [user type],
**I want to** [capability],
**so that** [outcome/benefit].
## Solution Overview
### What We're Building
[1-2 paragraphs on the proposed solution. Focus on user-facing behavior.]
### Key Capabilities
1. [Capability with brief description]
2. [Capability with brief description]
3. [Capability with brief description]
### What's Out of Scope
- [Explicitly excluded item]
- [Another exclusion]
## Requirements
### Must Have (Launch Blocking)
- [ ] [Requirement — specific and verifiable]
- [ ] [Requirement]
### Should Have (Fast Follow)
- [ ] [Requirement]
## Success Criteria
| Metric | Baseline | Target |
|--------|----------|--------|
| [Metric] | [Current] | [Goal] |
## Risks & Dependencies
| Risk/Dependency | Impact | Mitigation |
|-----------------|--------|------------|
| [Item] | [H/M/L] | [How we'll handle] |
## Timeline
| Phase | Duration | Deliverable |
|-------|----------|-------------|
| Design | [X days/weeks] | [Output] |
| Build | [X days/weeks] | [Output] |
| Launch | [Date] | [What ships] |
## Appendix
[Links to mockups, research, or related documents]Required Inputs
Before writing a brief, gather:
- Problem/opportunity — What are we addressing?
- Proposed approach — High-level solution direction
- Audience — Who will read this? (determines detail level)
- Constraints — Timeline, resources, technical limitations
Writing Tips
Keep briefs scannable. A busy stakeholder should grasp the essence in 60 seconds.
Lead with the "so what"—why should anyone care about this problem? Concrete impact beats abstract description.
Requirements should be verifiable. "Improved performance" is vague. "Page load under 2 seconds" is testable.
Be honest about unknowns. A brief with open questions is more useful than one with fake certainty.
Adapting Templates
For quick stakeholder alignment: Use the one-pager, trim to essentials.
For engineering scoping: Use the feature brief, expand requirements section.
For executive review: Use one-pager, emphasize business impact and metrics.
The templates are starting points. Remove sections that don't apply, add sections your team expects.