Product Requirements Document Template and Example

Copy the complete Markdown template below to define the user problem, intended outcome, scope, and observable product requirements before technical design or implementation planning begins. A product requirements document, or PRD, should explain what the product needs to accomplish and why. Remove any section that does not help a product decision. If the team still needs to test whether the product idea has clear customer value, start with a PRFAQ template and example. Write the PRD after the customer promise and hard questions are clear. For a framework-generated requirements example, inspect the GSD requirements ledger from the reliable-webhook-delivery run. It is GSD project output, not a neutral PRD template.

# [Product or feature] product requirements document

Status: Draft | In review | Accepted | Superseded
Owner: [Person or team]
Last updated: [Date]

## Answer
[What should be built, for whom, and why now, in two or three sentences.]

## Problem and evidence
[What users cannot do today. Link research, support evidence, usage data, or direct observation.]

## Goals
- G1. [User or business outcome]

## Non-goals
- [Adjacent outcome deliberately excluded]

## Users and journeys
### UJ-1: [Journey name]
- User: [Who and relevant context]
- Entry: [Where the journey begins]
- Action: [What the user does]
- Outcome: [How the user knows value arrived]
- Failure: [Important recovery path]

## Functional requirements
- FR-1. [Actor] can [observable capability] [under stated conditions].
  - Acceptance: Given [state], when [action], then [observable result].

## Nonfunctional requirements
- NFR-1. [Accessibility, performance, reliability, privacy, security, or operability requirement with a measurable boundary.]

## Constraints and dependencies
- Constraint: [Fixed policy, platform, time, cost, compatibility, or legal boundary]
- Dependency: [Team, service, decision, research, or external system]

## Success metrics
- SM-1. [Outcome metric, definition, target, and measurement window]

## Counter-metrics
- CM-1. [Metric that must not degrade while the team improves SM-1]

## Open questions
- OQ-1. [Unknown, owner, and date or evidence needed]

## Acceptance criteria
- AC-1. [Product-level evidence required before this scope is accepted]

## Related work
- Technical specification: [link when design begins]
- Implementation plan: [link when sequencing begins]
- Research and decisions: [links]

Filled example

This fictional example demonstrates the document shape. It is not a current or promised Plannotator feature.

# Expiring guest links product requirements document

Status: Draft
Owner: Sharing team
Last updated: 2026-07-18

## Answer
Workspace owners need optional expiry for guest links so temporary external
access ends without requiring them to remember a manual cleanup task.

## Problem and evidence
Three design partners share launch documents with contractors. They currently
revoke links by hand and cannot tell whether the intended access window ended.

## Goals
- G1. Let an owner choose an expiry when creating a guest link.
- G2. Make expired access predictable to the owner and guest.

## Non-goals
- Scheduled deletion of the document.
- Different expiry rules for individual files inside one shared folder.

## Users and journeys
### UJ-1: Owner shares a launch folder for one week
- User: A workspace owner working with an outside illustrator.
- Entry: The owner opens Share for the launch folder.
- Action: They choose guest-link access and a seven-day expiry.
- Outcome: The dialog shows the exact expiry before the link is copied.
- Failure: If the date is invalid, no link is created and the field explains why.

## Functional requirements
- FR-1. An owner can create a guest link with an expiry later than the current time.
  - Acceptance: Given an owned folder, when the owner chooses seven days, then
    the created link shows the same expiry in the Share dialog.
- FR-2. An expired guest link does not grant document access.
  - Acceptance: Given an expired link, when a guest opens it, then no document
    bytes or metadata are returned.

## Nonfunctional requirements
- NFR-1. Expired-link responses reveal no more document information than an
  unknown-link response.

## Constraints and dependencies
- Constraint: Existing non-expiring links keep their current behavior.
- Dependency: The access resolver must evaluate expiry before reading content.

## Success metrics
- SM-1. At least 80% of owners in the pilot who need temporary access choose an
  expiry instead of creating a permanent link.

## Counter-metrics
- CM-1. Failed guest opens caused by owners choosing the wrong date stay below 2%.

## Open questions
- OQ-1. Should owners receive a reminder before expiry? Owner: Product research.

## Acceptance criteria
- AC-1. Pilot owners can create, inspect, and revoke expiring links.
- AC-2. Security tests prove expired and unknown links have the same public shape.

Annotations on the filled example

Section	What makes it useful	Feedback still needed
Problem and evidence	Names the affected users and their current manual work	Link the interviews or observation notes and state whether three partners are enough evidence for a pilot
Goals and non-goals	Separates temporary access from deletion and nested sharing rules	Confirm whether auditing or owner notifications belong in the first release
User journey	Shows the entry point, action, visible outcome, and failure path	Define what the guest sees when an expired link is opened
Functional requirements	Describes observable behavior and pairs it with acceptance criteria	Resolve the allowed date range and time-zone behavior in technical design
Success and counter-metrics	Measures adoption without ignoring accidental lockouts	Identify the analytics source and the pilot window before accepting the targets
Open question	Keeps an unresolved product choice visible	Assign a decision date before technical design begins

The example stays at product intent. A technical specification should later define storage, time comparison, access resolution, error shapes, and migration. An implementation plan should name the code changes and validation sequence. Reviewers should leave unresolved product choices visible rather than letting a coding agent turn them into technical assumptions.

Review prompts

Does the PRD name a real user problem and link the evidence?
Can every requirement be observed without guessing at the author’s intent?
Do goals, non-goals, metrics, and counter-metrics prevent a misleading success?
Are constraints and dependencies facts rather than hidden design decisions?
Which open question must be resolved before technical design begins?
Has implementation detail displaced a product requirement?

This template is Plannotator-authored. It is informed by BMad Method’s pinned PRD template and GitHub Spec Kit’s pinned feature specification. Atlassian’s product requirements document template and Notion’s product requirements document template provide other inspectable structures. This page does not copy those templates. Read how to write and review a product requirements document. You can annotate the Markdown locally with open-source Plannotator or use Plannotator Workspaces when several people and agents need the same document. The PRD, technical specification, and implementation plan comparison is supporting guidance. Plannotator does not generate PRDs. Reviewed July 19, 2026. Written and maintained by the Plannotator documentation team.

Templates

Frameworks

Comparisons

Product Requirements Document Template and Example

Filled example

Annotations on the filled example

Review prompts

​Filled example

​Annotations on the filled example

​Review prompts

Filled example

Annotations on the filled example

Review prompts