AI Product Requirements Document Template: 14 Sections with a Worked Example

First decide what “AI PRD” means for this project

A product requirements document, or PRD, explains the product problem, intended outcomes, required behavior and boundaries for a particular decision. Atlassian's template brings together objectives, assumptions, requirements, supporting designs and open questions. It is a useful reminder that a PRD is more than a generated feature list. The fourteen-part arrangement here is an editorial choice, not an industry-mandated format. Atlassian PRD template

AI-assisted writing means an assistant helps organize approved material. Your feature might be entirely deterministic, such as a new export option. You still need a product owner to resolve missing facts and competing requests. A fluent draft is not evidence that interviews took place or an implementation is feasible.

Requirements for an AI feature add another layer. You need to define acceptable output, evaluation data, failure handling, human interaction and changes to the model or knowledge sources. A prompt is one implementation input; it is not the complete product contract. Likewise, a model that performs well on selected examples does not establish that the surrounding permissions, interface and operations work.

Our running example is an internal support-reply composer. It proposes a draft from permitted, current knowledge articles for a support agent to inspect. It does not send the reply, issue refunds, change account details or decide policy. The PRD must make that boundary visible to both builders and users. Microsoft's Human-AI Experience guidance emphasizes setting expectations about supported tasks and domains; a short capability statement is useful, but must agree with actual behavior. Microsoft HAX capability guidance

Separate evidence, requirements and decisions before writing prose

Give important statements a type and a stable reference. Otherwise, “an agent asked for faster replies” can become “all customers require a two-second response,” then a committed engineering target, without anyone noticing the change in meaning.

Use an evidence register with source IDs, dates, versions, access boundaries and the exact claim supported. A link proves where something came from only if the reader can inspect the relevant content. A valid document ID does not prove that the cited document supports a generated statement.

Write requirements so their outcome can be checked. NASA's requirements checklist emphasizes clarity, unique references, traceability and verifiability. Apply those disciplines to your product without importing aerospace procedures as mandatory SaaS rules. “Fast,” “secure” and “accurate” need defined conditions and an evaluation method, not stronger adjectives. NASA requirements-writing checklist

The fourteen sections of the AI product requirements document template

1. Document status, owner and requested approval

Record a PRD ID, version, document owner, accountable product owner, required reviewers and the decision being requested. Make the status unambiguous: draft, under review, approved for a named purpose, superseded or withdrawn. Keep a date for the next decision, not a release date that nobody has accepted.

The example is P077, version 0.3, draft. Its purpose is to review a bounded support-reply concept and its unresolved dependencies. A product owner agreeing that automatic sending is out of scope has not approved the whole document. Approval must name the version and purpose so later edits do not inherit authority automatically.

2. Executive summary: the problem and proposed outcome

Explain who is blocked, what they are trying to do, the proposed change and why a decision is needed now. A useful summary should still make sense if the implementation changes from an assistant to better search or a maintained response library.

For the fictional composer: support agents need a reviewable response draft tied to current permitted material. The proposed change puts a draft and its evidence beside the existing editor, while the agent remains responsible for sending. The requested decision is whether to resolve the remaining access, evaluation and operational questions before a limited pilot—not whether to launch immediately.

3. Problem, evidence and counterevidence

Describe the current workflow using authorized research or operational records. Separate what people said, what was observed and what you infer. Include who was not represented and which alternative explanations remain. If you have no baseline for writing time, state that rather than inventing a percentage improvement.

The case packet contains invented source excerpts and interaction records for teaching. It does not contain a real discovery study. In a live PRD, attach the actual approved interview notes or usage extracts and explain what each supports. Evidence that agents open several articles does not, by itself, show that generated replies are the best solution.

4. Target users, tasks and excluded contexts

Identify the primary role, task, environment, language and access conditions. Separate the person operating the feature from the people affected by its output. In our example, the support agent uses the composer, but the customer may later receive an edited reply. Their interests are related, not interchangeable.

Specify the initial language and product area, and decide whether assistants, temporary staff or external contractors are included. Do not invent demographic personas or assume everyone uses a mouse. If a workflow requires a screen reader or keyboard-only operation, include that requirement and its review plan from the start.

5. Goals, metrics and the decision each metric supports

For every metric, write the event definition, numerator, denominator, cohort, time window, source, owner and intended decision. Distinguish product usage, output quality, latency, cost and harm. A support agent accepting text unchanged is a behavior signal; it does not prove factual accuracy or a satisfied customer.

The example proposes three exploratory targets: at least 85% of in-scope attempts reach a preview, at least 70% of reviewed drafts are accepted unchanged, and success-only nearest-rank p95 preview latency is at most eight seconds. These are fictional planning choices that require validation, not industry benchmarks. Missing baseline and cost evidence remain open rather than becoming a savings claim.

6. Non-goals and the conditions for reopening them

Name adjacent capabilities that are deliberately excluded. In this case, the composer cannot automatically send, authorize refunds, edit customer accounts, or use private material outside the operator's access. A “draft” label alone is not a sufficient boundary if the implementation still has an outbound action available.

Give each significant exclusion a reason and a reconsideration condition. Automatic sending would require a different risk assessment, operational design, evidence and explicit authorization; it must not enter the release through a prompt change. A non-goal is an actual scope decision, not a feature left undocumented until someone asks.

7. Scope and uniquely identified requirements

Give each requirement a stable ID, required outcome, rationale, priority, dependency and acceptance link. Keep the behavioral statement distinct from the reviewer's assignment. Where several behaviors can fail independently, split them into separate requirements or clearly separated acceptance cases.

Avoid dictating a particular model or database unless it is a genuine constraint. “Every displayed factual claim must have support in an accessible current source” describes a needed outcome; “always use model X” does not explain why the outcome matters. If the chosen approach cannot reliably support the outcome, narrow the feature or withhold unsupported text rather than pretending the requirement has been satisfied.

8. User experience, failure states and recovery

Specify entry, loading, preview, empty result, denied access, timeout, correction and exit states. In the example, failed generation must leave the agent's existing text intact and offer a way to continue manually. Do not replace a working editor with an error screen that makes the underlying task impossible.

Google's People + AI Guidebook discusses defining errors, identifying their sources and helping users continue after failure. Apply that at the product level: a technically valid answer to the wrong task is still a problem for the user. Google PAIR failure and recovery guidance

For status notices that do not move focus, specify how assistive technology receives the information. W3C's explanation of WCAG 2.2 criterion 4.1.3 covers programmatically identifiable status messages; it does not mean every new paragraph should become an interrupting announcement. A recorded accessibility requirement still needs actual testing with suitable tools and reviewers. W3C status-message guidance

9. Data, integrations and the AI configuration boundary

List authorized inputs, systems of record, output fields, source versions, freshness rules, identifiers and failure behavior. Separate current knowledge from superseded content. Decide what happens if retrieval finds nothing, returns conflicting articles or provides material the current operator cannot view.

For an AI feature, record the selected model or candidate, prompt version, retrieval configuration, evaluation-set version and meaningful generation settings. Training data requirements apply only if training or fine-tuning is actually part of the plan. In our fictional PRD the production model and integration are not selected; the document cannot legitimately claim that access filtering or source traceability already works.

10. Security, privacy and required specialist review

Define the information flow and the responsible reviewers. Cover permissions at request time and when a result is displayed, sensitive material in logs, retention, deletion and the consequences of changed access. Do not treat a pseudonymous account code or a “private” toggle as sufficient evidence that all requirements are met.

The example specifically asks what happens when an agent loses article access after retrieval but before preview. That scenario is untested in the fictional record and remains a release blocker. Real privacy, security and legal decisions require qualified owners in the relevant environment; a generated PRD cannot certify compliance or replace their review.

11. Dependencies, constraints and fallback choices

List the systems, teams, data, vendor arrangements and operational resources that the release depends on. For each important dependency, name an owner, current evidence, unresolved condition and consequence of delay. Distinguish a genuine constraint from a preference that can change.

For the composer, permission-aware retrieval, an approved knowledge collection and a stable manual editor are prerequisites. If retrieval is unavailable, the fallback is the existing manual workflow, not unrestricted search across all company documents. If cost data is missing, keep the business case provisional rather than setting a budget from invented token prices.

12. Risks, triggers and residual decisions

Describe what could go wrong, how you would notice, who responds and what must happen before exposure continues. Risks include unsupported policy statements, stale sources, unauthorized disclosure, overreliance and disruption of the support task. A risk should not disappear because someone created a mitigation ticket.

The NIST AI Risk Management Framework is a voluntary reference for considering risks across AI design, development, use and evaluation. The official overview also states that AI RMF 1.0 is being revised. Record the version consulted; citing NIST is not certification or proof that your controls work. NIST AI RMF overview

13. Acceptance evidence, release conditions and rollback

Connect requirements to actual checks, the build or configuration checked, the result and unresolved defects. A test title is not a test result. Separate what was inspected from what was executed, and keep not-run checks visibly distinct from passes.

Specify who may approve a limited pilot and later expansion. Include stop conditions, a way to disable the feature, support ownership and the path back to manual work. Rollback does not necessarily retract a reply already sent or erase information already disclosed; the response plan must account for external effects rather than assuming a feature flag undoes everything.

14. Open questions and the decision history

Each open question needs an owner, evidence needed, due date and blocking effect. Keep unresolved items in the relevant section as well as the log, so the reader does not mistake an apparently complete paragraph for a settled issue.

When a decision changes, record the previous choice, new choice, reason, approver and affected requirements, tests and documentation. If the eight-second target changes, update the metric definition and explain why; do not edit yesterday's target merely to make today's example pass. Preserve superseded versions so the team can reconstruct the decision.

Worked example: a complete PRD that still says “hold”

Follow a requirement from source to acceptance evidence

The populated packet supplies seven requirements and eight fictional check records. These are deliberately limited teaching records, not a complete verification plan for a support product and not checks performed against OpenMax.

KB-01 says only a workspace administrator can change billing email. It does not say the change takes 24 hours. In T03, the proposed reply promises completion within 24 hours and cites KB-01. The link exists, but the claim is unsupported. A checker that validates only source IDs would miss the defect.

Five checks pass, one fails and two are not run in the fictional record. Only RQ-01, RQ-03, RQ-04 and RQ-05 have all their listed checks passing: four of seven requirements. That is coverage of this small matrix, not proof that those requirements are exhaustively verified in a real system.

Recalculate the interaction metrics without hiding failed attempts

A separate fictional interaction log contains twenty attempts. Fourteen reach preview, four time out and two are blocked by access. Of the fourteen previews, twelve receive an operator disposition: eight are accepted unchanged, three are edited and one is rejected. Two remain unreviewed. The log is separate from T01–T08; do not combine their denominators.

“Two thirds of reviewed drafts were accepted unchanged” is supported by the fictional log. “Two thirds of requests were successfully automated” is not. Acceptance does not establish correctness, and a draft-only product has not automated sending or resolution.

The fourteen successful preview durations are 2, 3, 3, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9 and 12 seconds. Using the declared nearest-rank rule—sort values and select position ceiling(p × n)—p50 is the seventh value, five seconds; p95 is the fourteenth, twelve seconds. This is success-only latency. Four timeouts took twenty seconds each and must remain visible separately. Do not relabel twelve seconds as the p95 for all attempts.

Make the release decision from the actual conditions

These targets are invented planning choices, not recommended defaults for every support team. The central lesson is the decision discipline: a polished document and several passing checks do not cancel a blocking defect. The example remains hold, and no real-world readiness or performance is inferred.

How to draft and review the PRD with an assistant

1. Prepare the evidence packet. Collect authorized sources and existing decisions. Give each a stable ID and state the exact scope the assistant may use. Record missing research rather than asking it to manufacture evidence.
2. Draft one section at a time. Provide that section's question, permitted source set and output format. Require evidence IDs and explicit uncertainty. An empty field with a responsible owner can be more useful than an invented answer.
3. Challenge the document across roles. Product checks the problem and scope; design checks the experience; engineering checks feasibility; data and relevant specialists examine evaluation and information handling. These are real people and responsibilities, not simulated approvals from an AI persona.
4. Replay the links in both directions. Pick a requirement and trace backward to the need or decision, then forward to acceptance evidence. Check a failed and a not-run case, not only a happy path. Separate a verified source link from a supported claim.
5. Freeze the decision version. Record what was approved, by whom and for which purpose. If the model, knowledge collection, permission rules or key requirement changes, identify affected evidence and request the appropriate new review.

For more detailed behavior statements, use the user-story acceptance-criteria guide. For unresolved risks, use the project risk register template. These documents support the PRD; they do not replace the decision owner.

Choose the lightest workflow that can maintain the evidence

Manual document and review: appropriate when the change is small and the evidence set is manageable. The important work is resolving meaning, not filling fourteen headings. Keep decision dates and requirement IDs even in a short document.

Existing collaboration tools: use comments, history and issue links already available to the team. Confirm what an approval actually covers and whether a changed attachment remains traceable. A shared page URL is not a version-specific approval record by itself.

Scripts or no-code checks: check duplicate requirement IDs, missing source references, invalid links and incomplete required fields. These checks can catch omissions; they cannot determine whether the product is useful or a policy interpretation is correct.

Agent-assisted drafting: useful when the evidence is distributed across authorized material and a structured first draft would reduce clerical work. Keep candidate requirements, assumptions and decisions visibly distinct. Do not grant source mutation, customer contact or release authority merely to prepare the PRD.

Recurring product operations: add versioned inputs, evaluation ownership, change notifications and re-review triggers as the process scales. Monitor whether old acceptance evidence still applies after a meaningful configuration change. Increasing document volume is not evidence of better decisions.

Where OpenMax can help—and what still needs verification

What the official documentation actually supports

OpenMax's AI product manager documentation contains a PRD-generation prompt asking for problem evidence, user stories, AI-specific acceptance criteria, system inputs and outputs, evaluation data, launch conditions and open questions. It also includes a stakeholder sign-off checklist as a requested output. That supports using the prompt as a drafting reference; it does not prove that your environment enforces approvals, maintains version history or connects every requirement to a test. OpenMax AI product manager documentation

Start with a source-bounded draft, not an approval claim

Try the fictional packet first. Ask for the evidence table, the seven requirements and the unresolved release conditions before requesting an executive summary. Compare the output with the supplied case. If it invents a 24-hour deadline from KB-01 or turns a not-run check into a pass, stop and correct the workflow.

Draft the requested PRD section using only the supplied evidence and decisions. Preserve source IDs, versions and limitations. Separate facts, proposed requirements, assumptions and open questions. Do not invent interviews, estimates, approvals or test results. Identify unsupported statements and conflicting rules. Produce a review draft only; do not edit source systems, contact customers, approve scope or release a feature.

Before real use, confirm tool access, data handling and integration behavior with the responsible owners. A restrictive prompt is not a substitute for implemented access controls. Keep the smallest useful task until its output can be checked against the actual sources.

When a simpler method is the better choice

If the team already has clear evidence and a short change, write directly in its existing document. If stakeholder disagreement is the bottleneck, another generated draft may only restate the disagreement more elegantly. If specialist approval or a baseline is missing, the next step is obtaining that evidence—not asking an assistant to make the PRD sound finished.

Use the populated PRD case to align reviewers, then adapt the blank template to one real, authorized product decision. Keep the resulting document in draft until the required owners decide otherwise.

Limits that should remain visible after the PRD is written

A template cannot establish demand, technical feasibility or compliance. Fourteen complete sections may still describe the wrong problem. The example's twenty interactions and eight check records are fictional teaching inputs; they are not sufficient evidence for a population estimate, causal improvement, cost saving or real release decision.

Model output can change with inputs, configuration and source updates. A single exact expected sentence may be too narrow for useful generative behavior, while a vague “looks good” review is too weak. Define the aspects that must remain true, the evaluation method and the consequences of failure. Human review also has capacity and error limits; naming a reviewer does not prove every output will be carefully read.

Real privacy, security, accessibility and legal requirements need appropriate specialists and actual evidence. Never insert a fabricated reviewer biography, simulated stakeholder approval or imagined customer quote to make the document seem authoritative. If a required review has not happened, say so and keep its blocking effect.

Frequently asked questions

Is this a template for writing with AI or for an AI product?

Both, with a clear distinction. Any PRD can use AI-assisted drafting from authorized evidence. If the feature itself uses AI, also complete model behavior, evaluation, data and failure requirements. Do not add irrelevant training sections to a product that only calls an existing model.

How long should a PRD be?

Long enough to support the specific decision, trace requirements and evaluate the outcome. Small changes can use short entries. Complex or consequential features need linked evidence and specialist detail; a page or word count is not a quality gate.

Can an assistant fill in missing metrics and estimates?

It can propose clearly labeled options for discussion, but it cannot turn missing baselines, costs, customer research or engineering estimates into facts. Give unknowns owners and a resolution plan before relying on them for commitments.

Does an approved PRD mean the feature can launch?

Not necessarily. Approval may cover discovery or implementation of a particular version. Release requires its own specified evidence, resolved blockers, operational readiness and authorized decision. In the fictional example, the correct release status remains hold.

Must a PRD choose the model and prompt permanently?

No. It should define required behavior and genuine constraints, while recording the implementation configuration that evidence applies to. Changes to the model, prompt, retrieval data or permission behavior can require re-evaluation rather than inheriting old results automatically.

Sources, revision method and the next action

Official sources were checked on September 4, 2026. This revision adds an explicit distinction between AI-assisted writing and an AI feature, a fully inspectable fictional PRD, source-to-requirement-to-check links, and separate interaction denominators. The fourteen-section structure and teaching case are original editorial material. No real customer study, OpenMax execution, integration test or professional approval is claimed.

For your next PRD, choose one product decision, freeze its authorized evidence and fill the sections that determine whether the team should proceed. Read the unsupported, failed and not-run items before polishing the summary. A useful PRD makes the next responsible decision clearer—even when that decision is to wait for evidence rather than launch.