danielpradilla Product Requirements Blueprint
Use this workflow to create professional Product Requirements Documents following industry best practices.
Required Inputs
Ask the user for these if not provided:
- Feature or product name
- Problem being solved (from the user's perspective)
- Target user (role, context, what they're trying to accomplish)
- Success metrics (how will you know it worked?)
- Scope (MVP vs full vision - what's in and out of scope)
- Key stakeholders (who needs to review and approve)
Template Structure
Every PRD should include these sections in order:
1. Overview
- Problem Statement: What problem are we solving? (2-3 sentences)
- Proposed Solution: High-level description of what we're building (2-3 sentences)
- Success Metrics: How we'll measure success (3-5 key metrics)
2. Context & Background
- Why Now: Why is this the right time?
- Strategic Alignment: How does this align with company objectives?
- User Research Summary: Key insights from research (if applicable)
3. User Stories & Use Cases
Format: "As a [user type], I want to [action] so that [benefit]"
- Include 3-7 primary user stories
- Add acceptance criteria for each
4. Requirements
Functional Requirements:
- Must-have features (P0)
- Should-have features (P1)
- Nice-to-have features (P2)
Non-Functional Requirements:
- Performance expectations
- Security considerations
- Accessibility requirements
5. Design & User Experience
- Link to design mocks or wireframes
- Key user flows
- Edge cases and error states
6. Technical Considerations
- Architecture implications
- Dependencies on other systems
- Technical risks and mitigations
7. Implementation Plan
- Phase 1 (MVP): What goes in first version
- Phase 2: What comes next
- Phase 3: Future enhancements
8. Open Questions
- Decisions that still need to be made
- Stakeholders to consult
- Research needed
9. Appendix
- Research links
- Related documents
- Competitive analysis
Writing Guidelines
Tone: Clear, concise, actionable Audience: Engineers, designers, stakeholders Length: Aim for 3-6 pages for features, 8-12 for products
Best Practices:
- Use concrete examples over abstractions
- Include "why" not just "what"
- Make requirements testable
- Link to supporting materials
- Update as decisions are made
What Makes a Good PRD
Do:
- Write from the user's perspective
- Include specific success metrics
- Address edge cases
- Link to research and data
- Make trade-offs explicit
Don't:
- Write implementation details (that's tech spec)
- Assume everyone has context
- Leave requirements ambiguous
- Skip the "why"
- Forget about accessibility
Quality Checks
- Problem statement is written from the user's perspective (not the company's)
- Success metrics are specific and measurable
- User stories include acceptance criteria
- Requirements are testable (not vague)
- Open questions are listed explicitly
- Implementation plan distinguishes MVP from future phases