Product Requirements Document

Product Requirements Document (PRD)

Why this exists

A PRD fails in one of two directions, almost never in the middle. Too vague ("support bulk export") and engineering ends up inventing the edge cases themselves, inconsistently, mid-build. Too prescriptive (specifying exact pixel layouts or implementation details with no hard constraint requiring it) and it strips design and engineering of the room to find a better solution than the one the PM happened to imagine. The other constant failure: no acceptance criteria, so "done" becomes a subjective argument at the worst possible time — right before ship.

This skill is a structure for landing in the middle: precise about outcomes, silent about implementation unless there's a real constraint.

Process

1. State the user problem, tied to evidence

Name the user, the job they're trying to do, and what's broken today — and cite where this came from rather than asserting it from gut feel. If this repo's other skills produced the evidence (a call-insight-extraction summary, a feedback-triage-scoring ranking, a usage-trend-narration finding, an internal-signal-scouting pulse, or an approved BRD), link to it directly. A PRD without traceable evidence invites exactly the debate it's trying to prevent.

2. State the goal and how you'll know it worked

If a BRD exists, this should trace directly to one of its objectives. Either way, this needs to be a measurable outcome, distinct from a list of features — "reduce time to generate a report from 10 minutes to under 1 minute" is a goal; "add an export button" is a feature.

3. Write user stories that include the edge cases up front

Use "As a [user], I want [capability], so that [benefit]" for the primary path, and then explicitly list the edge cases in the same pass: empty states, permission boundaries, error/failure states, and what happens with conflicting or concurrent actions. Edge cases caught while writing the PRD are cheap. The same edge cases discovered mid-sprint are not.

4. Specify functional requirements as observable outcomes, not implementations

Describe what the system must do in a way that's checkable from the outside, and leave the specific UI treatment or algorithm to design/engineering unless a real constraint (compliance, a hard performance floor, an existing pattern that must be matched) requires dictating it. Use MoSCoW (Must / Should / Could) to separate what's required for this release from what can slip.

5. Call out non-functional requirements explicitly

Performance, scale, accessibility, security/privacy, localization. These get silently dropped when unwritten, and they're the most expensive category to retrofit after the fact — write them down even when the answer is "no special requirement beyond the platform default," so it's a decision rather than an omission.

6. Draw the scope boundary in three parts

In scope, explicitly out of scope, and explicitly deferred to a later phase. The "deferred" bucket matters specifically because it's where scope creep tries to sneak in during build — having named it up front makes it easy to point back to when someone asks "can we also just add..." mid-sprint.

7. Write acceptance criteria per requirement

One testable, unambiguous statement per requirement, ideally Given/When/Then. This is what QA tests against and what makes "done" a fact rather than an opinion.

8. List open questions with an owner and a deadline

Anything genuinely undecided goes here by name, not silently assumed one way in the body of the document. An open question without an owner and a decision deadline just becomes an assumption nobody agreed to.

Output format

# Product Requirements Document: [Feature/Initiative Name]
**Owner:** [name] | **Date:** [date] | **Status:** [Draft/Approved]
**Linked BRD / evidence:** [link, if applicable]

## 1. Problem & Evidence
[User problem, who's affected, linked evidence]

## 2. Goal & Success Metric
[Measurable goal, tied to BRD objective if one exists]

## 3. User Stories
- As a [user], I want [capability], so that [benefit].
  - Edge cases: [empty state, permissions, failure state, concurrency]

## 4. Functional Requirements
| # | Requirement | Priority (MoSCoW) |
|---|---|---|

## 5. Non-Functional Requirements
- Performance: [...]
- Accessibility: [...]
- Security/Privacy: [...]
- Localization: [...]

## 6. Scope
**In scope:** [...]
**Out of scope:** [...]
**Deferred to later phase:** [...]

## 7. Acceptance Criteria
- Given [context], when [action], then [expected result].

## 8. Open Questions
| Question | Owner | Needed by |
|---|---|---|

Anti-patterns to avoid

• Don't specify pixel-level UI decisions without a real constraint requiring it — that turns the PRD into a wireframe substitute and removes design's ability to solve the problem well.
• Don't skip edge cases and failure states — "what happens when it fails" is a requirement, not an afterthought.
• Don't write a requirement without an acceptance criterion — an untestable requirement produces a dispute about "done," not a shared understanding of it.
• Don't leave non-functional requirements implicit — silence reads as "doesn't matter" and gets baked in that way.
• Don't assume an open question's answer just to keep the document moving — name it, assign an owner, set a deadline.

Example (illustrative, continues the BRD example)

# Product Requirements Document: Self-Serve Audit Report Export
**Owner:** J. Alvarez | **Date:** 2026-08-22 | **Status:** Draft
**Linked BRD:** Enterprise Self-Serve Reporting (2026-08-15)

## 1. Problem & Evidence
Enterprise finance admins cannot generate audit-ready usage reports themselves
and file support tickets instead (see linked BRD: ~3 support-hours/request,
cited in 2 of last quarter's escalations).

## 2. Goal & Success Metric
Reduce time-to-generate an audit report from a multi-day support ticket cycle
to under 5 minutes, self-serve. Success: support tickets tagged "audit report
request" drop to near zero within 90 days of launch.

## 3. User Stories
- As an enterprise finance admin, I want to generate an audit-ready usage
  report for a custom date range, so that I don't need to file a support
  ticket for routine audits.
  - Edge cases: admin has no usage data in the selected range (empty state);
    admin lacks report-export permission (permission boundary); report
    generation fails partway through (failure state, must show a clear retry
    path, not a silent partial file).

## 4. Functional Requirements
| # | Requirement | Priority |
|---|---|---|
| 1 | Admin can select a custom date range and generate a report | Must |
| 2 | Report includes fields required for SOC 2 audit (per compliance spec) | Must |
| 3 | Admin can save a report configuration for reuse | Should |
| 4 | Report can be scheduled to auto-generate monthly | Could |

## 5. Non-Functional Requirements
- Performance: report generation completes in under 30 seconds for a 12-month range
- Accessibility: meets existing platform WCAG 2.1 AA standard, no new exceptions
- Security/Privacy: export respects existing role-based data-visibility rules
- Localization: no new localization requirement beyond existing platform support

## 6. Scope
**In scope:** Enterprise-tier, on-demand and scheduled report generation
**Out of scope:** SMB tier, real-time/streaming report data
**Deferred to later phase:** Custom report templates beyond the standard audit format

## 7. Acceptance Criteria
- Given an admin with export permission, when they select a valid date range
  and click Generate, then a downloadable report is produced within 30 seconds.
- Given an admin without export permission, when they attempt to generate a
  report, then they see a clear permission-denied message, not a silent failure.

## 8. Open Questions
| Question | Owner | Needed by |
|---|---|---|
| Should scheduled reports email the file or link to a secure download? | J. Alvarez | 2026-09-01 |

Note requirement #2 references a compliance spec rather than restating it — the PRD points to the constraint instead of trying to own compliance detail it isn't the source of truth for.