# Prd Development

Build a structured PRD that connects problem, users, solution, and success criteria.

- Repository: https://github.com/deanpeters/Product-Manager-Skills (7825 stars)
- Category: Writing
- License: see repository
- Last updated: 2026-10-16
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add deanpeters/Product-Manager-Skills --skill prd-development -g -a claude-code -y`
Codex: `npx skills add deanpeters/Product-Manager-Skills --skill prd-development -g -a codex -y`
Cursor: `npx skills add deanpeters/Product-Manager-Skills --skill prd-development -g -a cursor -y`
Gemini CLI: `npx skills add deanpeters/Product-Manager-Skills --skill prd-development -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add deanpeters/Product-Manager-Skills`

## Description

Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

## Purpose
Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth, avoiding ambiguity, scope creep, and the "build what's in my head" trap.

This is not a waterfall spec, it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery.

## Input

**Works best with:** The feature or initiative the PRD covers.
**Also useful:** Discovery notes, problem statements, user research, success metrics, and constraints, paste whatever exists; the workflow slots it into the right phases and skips what's already answered.

Anything supplied with the invocation itself, text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line, counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The workflow starts at problem definition and builds up from there.

**Example invocation:** `Build a PRD for self-serve workspace provisioning, here are my discovery notes and the OKR it ladders to.`

## Key Concepts

### What is a PRD?

A PRD (Product Requirements Document) is a structured document that answers:
1. **What problem are we solving?** (Problem statement)
2. **For whom?** (Target users/personas)
3. **Why now?** (Strategic context, business case)
4. **What are we building?** (Solution overview)
5. **How will we measure success?** (Metrics, success criteria)
6. **What are the requirements?** (User stories, acceptance criteria, constraints)
7. **What are we NOT building?** (Out of scope)

### PRD Structure (Standard Template)

```markdown
# [Feature/Product Name] PRD

The rest: https://github.com/deanpeters/Product-Manager-Skills/blob/HEAD/skills/prd-development/SKILL.md