Product Requirements Document: [Feature name]

Field	Value
Product owner	[Name]
Engineering lead	[Name]
Status	Draft / In review / Approved
Target release	[Date or milestone]
Last updated	[YYYY-MM-DD]
Related documents	[Design, business analysis, issue tracker links]

Replace bracketed fields and adapt the example requirements before review.

Problem and audience

[Who encounters this problem? What are they trying to accomplish, and what prevents them today?]

Evidence: [Customer interviews, support tickets, or usage data. Include source and date.]

Current workaround: [How users solve this today and its cost.]

Goals and success measures

Outcome	Metric	Baseline	Target	Measurement window
[User outcome]	[Metric and data source]	[Current value]	[Target value]	[Period after release]

Guardrails: [Metrics that must not regress, such as error rate or task completion time.]

Scope

In scope

• [Core capability required for the first release]
• [Supported platforms and user roles]

Out of scope

• [Adjacent capability intentionally deferred, with reason]

User journey

1. Trigger: [What brings the user to this feature?]
2. Action: [Steps the user takes.]
3. Success: [Visible confirmation and resulting state.]
4. Recovery: [Empty states, permission failures, and retry behavior.]

Requirements and acceptance criteria

ID	User story	Priority	Acceptance criteria
FR-01	As a workspace member, I want to save a draft so I can resume later.	Must	Given a valid draft, when I save and reopen it, then its content is unchanged.
FR-02	As a viewer, I want clear feedback about my permissions.	Must	Given read-only access, when I open a document, then editing is unavailable and my role is explained.
FR-03	[As a role, I want an action, so that an outcome.]	[Must / Should / Could]	[Given / When / Then, including a failure case]

Quality requirements

Area	Requirement	Verification
Performance	[Operation, percentile, target, and load]	[Measurement method]
Accessibility	[Keyboard, focus, and screen reader behavior]	[Manual and automated checks]
Security and privacy	[Permissions, sensitive data, retention]	[Review and tests]
Compatibility	[Supported browsers and devices]	[Test matrix]

Dependencies and risks

Dependency or risk	Owner	Impact	Mitigation or fallback
[External service, team, or assumption]	[Name]	[Release impact]	[Action]

Release and validation

• Design and requirements reviewed by [owners].
• Acceptance criteria verified and linked to test results.
• Analytics events and guardrails verified.
• Rollout cohort, feature flag, and support guidance prepared.
• Rollback trigger and responsible owner agreed.
• Post-release review scheduled for [date].

Open questions and decisions

Question	Owner	Due date	Decision and rationale
[Unresolved question]	[Name]	[Date]	[Pending]