Pm Prd

---
name: pm-prd
description: Drafts a Product Requirements Document with the problem and its evidence, goals, non-goals, numbered testable requirements, open questions with owners and success measures. Use for "run pm-prd", "write a PRD", "PRD template", "spec for this feature", "turn my interview notes into a spec", "product requirements", "the team keeps reading the spec differently", part of the AI for Product Management Pack by Polar Bear.
---

# PRD Template

## When To Use
The last spec was read five different ways and you shipped something else. Or every PRD starts from a blank page and the path from interview notes to spec is clunky. It answers: what problem are we solving, what are we deliberately not doing, and how will each requirement be checked?

## When Not To Use
If nobody has agreed whether to build it, argue the why first with Working Backwards PR/FAQ. If the requirements are agreed and engineers need buildable slices, go to User Stories; a PRD is not a backlog.

## Inputs
- The PR/FAQ, brief or problem statement if one exists, plus evidence (interview synthesis, support themes, usage data, request log)
- Constraints (dates, dependencies, platform limits), your MoSCoW or RICE list if you have one, and the page limit your team will actually read
If you have none of this, I start from a one-line problem and mark the output as a first draft, with the evidence gaps listed as open questions.

## Approach
The product requirements document is a practitioner convention with no single originator. This version puts the problem, the non-goals and the open questions ahead of any solution, because those are the parts that stop five readings. Writing it is also how the PM finds their own gaps, so Claude drafts and the PM argues with the draft. The failure it prevents: a twelve-page spec where "fast search" meant one thing to design, another to engineering and a third to sales.

## Workflow
1. Ask three questions: who reads this (engineering, design, leadership), what is the page limit, and which evidence can I use?
2. Problem first, in customer terms, with the source of each claim. If a solution sits inside the problem statement ("users need a dashboard"), pull it out and restate the need.
3. Goals, then non-goals. Each non-goal names something a reasonable reader might assume is in scope. Most misreadings live here.
4. Requirements, numbered, one behaviour each, each with a check a tester could run. Vague words (fast, simple, intuitive) get a measurable definition or an open question. Priority comes from the user's MoSCoW or RICE list, never from me.
5. Open questions, each with an owning role and a date. An open question with no owner is a future misreading.
6. Success measures tied to the goals, linked to Success Metrics; the user sets every target and baseline. Then check the length against the limit, flag the overrun, and name the three places a reader is most likely to disagree.

## Output Format
```markdown
# Product Requirements Document
**Feature:** [name] | **Version:** [number] | **Approver:** [role]
## Problem and scope
**Problem:** [customer problem, no solution inside] | Evidence: [source]
**Goals:** [goal] | **Non-goals (not in this release):** [thing a reader might assume is in]
## Requirements
| ID | Requirement (one behaviour) | How it is checked | Priority |
|---|---|---|---|
| R1 | [requirement] | [check] | [from MoSCoW or RICE] |
## Open questions
| Question | Owner (role) | Answer by |
|---|---|---|
| [question] | [role] | [date] |
## Success measures
| Goal | Measure | Baseline | Target |
|---|---|---|---|
| [goal] | [measure] | [user sets] | [user sets] |
## Decision
[Named person] approves this version by [date], after a read-through with engineering and design.
```

## Done When
- The problem statement holds no solution and cites its evidence
- Every requirement has a check, every open question an owner and a date, and every goal at least one non-goal
- The document fits the page limit, or the overrun is flagged

## Quality Bar
- No invented baselines, targets or customer numbers: [placeholders] until the user supplies them
- One requirement per row ("and" means two rows); customer needs summarised, never profiles of named customers
- Changes after approval go in a new version, not a silent edit
- Claude drafts the PRD; the team reads it together and a named person approves it

## Next
Run pm-story-mapping (Story Mapping) to lay the requirements out along the user's journey.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).