# Product Requirements Blueprint

> Draft product requirements with the problem, users, scope, requirements, metrics, and open decisions.

- Skill: `danielpradilla/product-requirements-blueprint` (Agent Skill)
- Install (CLI): `npx skillmds add danielpradilla/product-requirements-blueprint`
- Raw SKILL.md: https://api.skillmd.com/api/skills/danielpradilla/product-requirements-blueprint/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: danielpradilla (https://skillmd.com/u/danielpradilla)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/danielpradilla/product-requirements-blueprint

---


# 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