A PRD template for AI-native product teams must do more than describe a feature. It should preserve the evidence behind the problem, turn product intent into testable requirements, define what people and agents may change, and make launch decisions auditable.

The PRD carries provenance and decision authority from the problem through launch verification.

Copy this PRD template

[Product or feature name]

Document control

The short answer

A reliable PRD has eight contracts:

1. a problem supported by identifiable evidence;

2. a target user and context;

3. measurable outcomes and non-goals;

4. testable functional and quality requirements;

5. explicit assumptions, constraints, and risks;

6. named owners and decision gates;

7. agent authority boundaries;

8. launch evidence and post-launch verification.

The PRD is not a promise that every sentence is correct forever. It is the current approved product contract, with its sources, owners, status, and change history visible.

Problem and evidence

Problem statement

[Target user] struggles to [complete a job] in [specific context], causing [observable cost or risk].

Evidence register

For every major claim, link to the underlying interview, event definition, query, ticket, or research record. A summary without retrievable evidence should be labeled as an assumption, not a fact.

Target user and job

• Primary user: [Role and environment]

• Secondary user: [Role]

• Job to be done: When [situation], I want to [motivation], so I can [outcome].

• Current workaround: [What the user does now]

• Switching trigger: [Why behavior changes now]

• Exclusions: [Who is not the target user]

Outcome and success measures

Define the metric owner, calculation, denominator, and decision threshold. “Improve engagement” is not measurable enough to approve a launch.

Non-goals

• We are not replacing the source system.

• We are not granting agents unrestricted write access.

• We are not automating ambiguous decisions.

• We are not changing existing permission ownership.

• We are not solving [adjacent problem] in this release.

Non-goals protect the product from accidental scope expansion. They should be specific enough to reject a plausible request.

User journey

1. The user enters from [trigger].

2. The system retrieves [authorized context].

3. The user or agent creates a proposal.

4. Deterministic validation checks required fields and policy.

5. An authorized human reviews consequential changes.

6. The system executes the approved payload.

7. The destination is read back and compared.

8. The user sees verified outcome or an owned exception.

Requirements register

Write requirements as observable behavior. Avoid “easy,” “fast,” “intuitive,” or “secure” unless the PRD defines how those qualities will be measured.

Requirement quality checklist

A requirement is ready when it has:

• a stable ID;

• one testable behavior;

• an owner;

• a priority;

• an acceptance method;

• dependencies;

• permission implications;

• failure behavior;

• a current status.

If an AI agent drafts a requirement, begin in Proposed. Do not let generated text appear approved merely because it is inside the PRD.

A requirement becomes build-ready only when its behavior, authority, evidence, dependencies, and failure path are explicit.

Agent authority contract

Agents may

• retrieve sources the current user is allowed to access;

• summarize evidence with citations;

• identify contradictions and missing fields;

• propose requirements, risks, tests, and decision questions;

• prepare a change packet;

• execute a specific pre-approved action;

• reconcile destination state;

• route exceptions to a named owner.

Agents must not

• approve their own proposal;

• invent evidence, owners, deadlines, or permission;

• change the problem statement, scope, budget, release gate, or target metric;

• publish externally;

• delete or archive product records;

• mark a requirement accepted without evidence;

• hide failed or partial execution.

Authority levels

Tool access is not authority. The PRD should state both what an integration can technically do and what the product policy permits it to do.

Decision gates

Gate 1: Problem validation

Approve only when:

• the target user and context are specific;

• evidence is retrievable;

• material contradictions are recorded;

• the cost of the problem is observable;

• the team agrees what would disprove the hypothesis.

Gate 2: Solution and architecture

Approve only when:

• the end-to-end journey is understood;

• permissions and data boundaries are explicit;

• failure and rollback behavior are defined;

• requirements have owners and acceptance evidence;

• high-risk assumptions have tests.

Gate 3: Build readiness

Approve only when:

• Must requirements are accepted;

• dependencies and external contracts are confirmed;

• instrumentation is specified;

• security and privacy reviews are assigned;

• the release and rollback plan has owners.

Gate 4: Launch readiness

Approve only when:

• acceptance tests pass;

• permission tests pass;

• observability is live;

• support and incident ownership are clear;

• rollback is executable;

• launch evidence is attached.

Gate 5: Post-launch verification

Close only when:

• metrics are read from the defined source;

• guardrails are within threshold;

• destination state reconciles;

• exceptions have owners;

• the decision to continue, change, or roll back is recorded.

Change packet

Every material PRD change should include:

{
  "prd_id": "PRD-104",
  "change_id": "CHG-018",
  "proposed_by": "agent:product-research",
  "field": "FR-02.acceptance_evidence",
  "from": "manual spot check",
  "to": "approved payload versus audit-log diff",
  "reason": "manual checks cannot detect payload drift",
  "evidence_ids": ["INC-024", "TEST-117"],
  "risk_class": "medium",
  "requires_approval": true
}

A reviewer should see the exact old value, new value, reason, evidence, consequences, and rollback—not a vague request to “review the latest PRD.”

Review the exact diff, execute only the approved payload, and verify the resulting PRD state.

Assumptions, constraints, and risks

Separate assumptions from facts. An assumption is not weaker writing; it is an explicit claim awaiting a test.

Data and permission model

Document:

• source systems and data owners;

• record types retrieved;

• identity used for retrieval;

• permission filtering point;

• retention and deletion behavior;

• fields an agent may propose;

• fields an agent may write;

• approval authority;

• audit events;

• sensitive-data exclusions;

• cross-tenant boundaries.

For AI features, permission behavior is part of the product experience, not an implementation footnote.

Failure modes

Define behavior for:

• source unavailable;

• stale evidence;

• contradictory sources;

• missing permission;

• reviewer unavailable;

• validation failure;

• partial destination write;

• retry after timeout;

• destination state mismatch;

• model output outside schema;

• user revokes access;

• launch metric source delayed.

For each failure, specify the visible user state, owner, retry rule, audit event, and safe fallback.

Acceptance plan

Functional tests

• Each requirement maps to at least one test.

• Proposed and approved states are visually distinct.

• Agents cannot approve their own changes.

• Exact approved payload is executed.

• Invalid transitions are rejected.

• Destination IDs are stored.

Permission tests

• Users see only authorized evidence.

• Revoked access takes effect.

• Agent scope does not exceed user and workspace policy.

• Cross-project and cross-tenant leakage tests fail closed.

Reliability tests

• Duplicate requests are idempotent.

• Timeout retries return or update the existing record.

• Partial failures create owned exceptions.

• Read-back detects mismatched owner, status, or due date.

Evaluation tests

• Answers cite current evidence.

• Unsupported claims are abstained or labeled.

• Contradictions are surfaced.

• Evaluation sets include realistic permission boundaries and failure cases.

Launch plan

• Cohort: [Users or workspaces]

• Feature flag: [Name]

• Start time: [Time]

• Launch owner: [Person]

• Monitoring owner: [Person]

• Support owner: [Person]

• Rollback authority: [Person]

• Rollback trigger: [Metric or incident threshold]

• Communication: [Audience and approved message]

• Evidence packet: [Tests, approvals, dashboards, runbook]

Post-launch decision record

Recommended database properties

A PRD database can include:

• PRD ID;

• title;

• status;

• product owner;

• technical owner;

• decision authority;

• project relation;

• evidence relation;

• decision relation;

• target release;

• priority;

• risk class;

• agent policy;

• last verified;

• next review;

• superseded by.

Notion’s official guide for product requirements documents recommends a PRD database with properties, views, templates, and relations to projects. Database templates can standardize the page structure, while relations keep PRDs connected to delivery work.

Views to create

Decision queue

PRDs or changes waiting for an authorized decision, sorted by impact and needed-by date.

Missing evidence

Claims or requirements without a source, owner, or acceptance method.

Agent proposals

Changes proposed by AI that have not been approved.

Build ready

Approved PRDs whose Must requirements, owners, dependencies, and acceptance plan are complete.

Launch readiness

Items at Gate 4 with tests, permissions, monitoring, runbook, and rollback status.

Stale PRDs

Documents whose last verified date exceeds the team’s review window.

Superseded decisions

Old PRDs and decision records linked to the current contract instead of silently overwritten.

Common PRD mistakes

The PRD is a long feature description

A product contract needs evidence, outcomes, decision rights, tests, risks, and launch gates—not only prose.

AI-generated requirements start as approved

Generated work begins as Proposed. Approval requires an authorized human or explicit bounded policy.

Sources are summarized but not linked

Store evidence identity and retrieval path so reviewers can verify claims.

Success has no denominator or window

Define the metric, baseline, target, cohort, time window, source, and guardrail.

Permission behavior is unspecified

For AI products, state whose identity is used, where filtering occurs, and what happens when access changes.

Requirements have no failure behavior

The safe fallback is part of the requirement.

A connector success response is treated as completion

Read the destination record back and compare it with the approved contract.

The document is overwritten without a decision record

Preserve material changes, rationale, authority, and effective date.

When a lightweight PRD is enough

Use a shorter PRD for reversible, low-risk work with a known user, clear acceptance criteria, and no material permission or external commitment. Keep at least:

• problem and evidence;

• outcome and non-goals;

• requirements;

• owner and decision authority;

• risks;

• acceptance evidence;

• launch and rollback owner.

Increase rigor when the feature changes permissions, identity, money, sensitive data, external communications, autonomous actions, or irreversible state.

Frequently asked questions

What should a PRD template include?

Include document control, problem evidence, target users, outcomes, non-goals, requirements, assumptions, constraints, risks, decisions, owners, acceptance tests, launch gates, rollback, and post-launch verification.

Should AI write the PRD?

AI can retrieve evidence, summarize sources, identify gaps, and propose sections. Humans should own the problem, scope, decision rights, accepted requirements, launch authority, and material changes.

How long should a PRD be?

Long enough to make the product contract testable. A small reversible change may need one page; a permission-sensitive agent workflow needs explicit data, authority, failure, audit, and rollback sections.

What is the difference between a PRD and a project plan?

A PRD defines why and what must become true. A project plan organizes how, who, and when the approved work will be delivered. Link them, but do not collapse their lifecycles.

How should requirements be written?

Use stable IDs, one observable behavior per requirement, an owner, priority, acceptance evidence, dependencies, permission implications, and failure behavior.

What should an agent be allowed to change?

Begin with read and propose. Permit execution only for exact approved payloads. Use bounded automation only with explicit records, fields, transitions, risk classes, idempotency, audit, read-back, and exception ownership.

How do you keep a PRD current?

Add last verified and next review dates, preserve decision records, link live evidence, flag stale assumptions, and mark superseded PRDs instead of deleting history.

Last verified: July 21, 2026.

Use the reusable template

Use the structured PRD table below to turn a product problem into explicit requirements, owners, evidence, decision gates, success metrics, and human approval.

Sources

• Notion: Using Notion for product requirement documents

• Notion: Database templates

• Notion: Relations and rollups

• Notion: Database buttons

• Notion: Database automations

Product facts were verified on July 21, 2026.

Where Dokki fits

A Dokki PRD can live beside the evidence, decision log, implementation tracker, and agent work it governs. That keeps requirements from becoming a static handoff document and makes launch acceptance traceable to the original product decision.

• Project management template for human-agent teams

• Content calendar template for an AI editorial workflow

• Notion Custom Agents: workflow design and permissions