AI PRD basics are different from normal product requirements. A conventional PRD assumes the feature can be described once and implemented deterministically. An AI feature can be wrong in useful-looking ways: it can retrieve the wrong source, infer the wrong intent, skip an exception, or produce a plausible answer that still breaks the workflow.
That is why the PRD matters more, not less. It should tell the team what the system may know, what it may do, what it may get wrong, and when a human must step in. If you write those boundaries clearly, you can decide whether the feature is safe to build, what review it needs, and what evidence counts as a real launch gate.
Previous post: AI Agent Architecture for Product Managers.
If you want the business frame first, read The Founder’s AI Readiness Scorecard.
For the series starting point, read What Is AI in Business? A Plain-English Guide.
What this post covers
By the end, you should be able to decide whether an AI feature is ready for a PRD, a prototype, or a hard no.
- Why AI PRDs need wrongness controls that normal PRDs do not.
- The five controls every AI feature spec should define.
- How to write source truth, fallback, and review requirements.
- What evaluation and evidence belong in the product spec.
- A one-page AI PRD template you can use today.
A normal PRD assumes the feature is right; an AI PRD assumes it can be wrong
Product requirements documents already have a standard job. Atlassian’s product requirements guidance defines the document around purpose, features, behavior, user needs, and success criteria. Miro’s PRD template adds goals, success metrics, assumptions, out-of-scope items, and ownership. That is the right base.
An AI PRD needs one more layer: the feature can be plausible and still be wrong.
A product manager writing for a support assistant, sales copilot, or internal research tool cannot stop at "what should it do?" They also have to specify:
- which sources are authoritative,
- which behaviors are allowed,
- what the system should do when it is uncertain,
- when a human must approve, and
- how the team will prove the feature behaved as intended.
That is the business difference. A regular PRD is about alignment. An AI PRD is about alignment plus controlled wrongness.
If the model produces an answer that looks polished but is based on stale policy, missing context, or the wrong customer record, the product may fail in the only way that matters: it will be confidently wrong in production.
Conventional PRD vs AI PRD
| Conventional PRD asks |
AI PRD must also ask |
| What problem are we solving? |
What source is allowed to answer it? |
| What features are included? |
What can the system infer versus not infer? |
| What does success look like? |
What counts as acceptable wrongness? |
| What is out of scope? |
What outputs must never happen? |
| How will we ship it? |
Where do humans review or override it? |
The five controls every AI feature needs
A good AI PRD usually turns on five controls: source truth, behavior bounds, fallback behavior, review points, and evaluation. If any one of those is vague, the implementation team will invent the missing rule later, which usually means the rule is inconsistent.
1. Source truth
Source truth answers which systems, docs, or records are allowed to govern the feature. For a product AI feature, that might be the help center, a policy doc, a CRM record, or a pricing database. The PRD should say which source wins when they disagree.
2. Behavior bounds
Behavior bounds answer what the system may do and what it must not do. This is where product requirements become specific. Can the AI draft only, or can it send? Can it summarize private data, or only public docs? Can it make a recommendation, or must it wait for approval?
3. Fallback behavior
Fallback behavior answers what happens when the model cannot get enough signal. That may mean return a draft with citations, ask a clarifying question, show "I cannot verify this," or hand the task to a human. If you do not write the fallback, the model will improvise one.
4. Review points
Review points answer where a human checks the output before the system changes the world. This matters most when the AI can touch customers, money, or policy. OpenAI’s guide to agents and Anthropic’s work on effective agents both emphasize predictable orchestration and simple, composable patterns. In product terms, that means the review step belongs in the requirements, not only in engineering design.
5. Evaluation and evidence
Evaluation answers how the team will know the feature is good enough. Evidence answers what the team will log so they can inspect the result later. A PRD should name the test set, the success metric, the error cases, and the proof artifact. Without that, "looks good in demo" becomes the launch criterion.
Write the wrongness section before the nice-sounding feature copy
The most useful AI PRD question is not "how does the feature shine?" It is "how can this feature fail without causing damage?"
That is the section most product teams skip. They write user stories, UI notes, and success metrics, then leave the bad cases for a later meeting. In AI products, later is too late.
A practical way to write this is to separate the requirement into two columns in your own head:
- What the system should do when it has enough signal.
- What the system should do when it does not.
For example:
- If a support assistant cannot verify the customer tier, it should draft a response and flag the missing account data instead of guessing.
- If a finance assistant cannot confirm the invoice state, it should stop and request a human check before any external message.
- If a product research assistant only has stale notes, it should cite the source dates or refuse to summarize them as current truth.
Those are not implementation details. They are product decisions about risk.
The business upside is clarity. Product, design, and engineering can all see the same boundary: where the AI is allowed to help, where it must ask, and where it must stop.
A one-page AI PRD template for product teams
Use a compact template so the team does not hide uncertainty inside a long document.
Problem:
What user pain or business outcome are we trying to change?
User:
Who uses the feature, and in what workflow?
Source truth:
Which systems, docs, or records are allowed to govern the answer?
Allowed behavior:
What can the AI draft, recommend, retrieve, or change?
What must it never do?
Wrongness policy:
What kinds of errors are acceptable?
What kinds are not acceptable?
Fallback behavior:
What happens when confidence is low or context is missing?
Review points:
When must a human approve, edit, or take over?
Evaluation:
What test cases, metrics, and acceptance criteria define success?
Evidence:
What should the system log or show so we can prove what happened?
Out of scope:
What is deliberately not included in this release?
If you want the document to be useful in a real planning meeting, add one more line at the top: What decision will this PRD help us make?
That one sentence keeps the spec tied to a business outcome instead of a feature wish list.
If the team cannot describe the wrongness, the feature is not ready
This is the simplest test I know.
If the product team cannot explain the feature’s source truth, its allowed errors, its fallback behavior, and its review points, the AI PRD is incomplete. The issue is not that the team needs more model capability. The issue is that the team has not defined the control surface yet.
If you need the business case behind that view, read The Founder’s AI Readiness Scorecard. If you want the next layer of system thinking, read What Is Context Engineering and Why Is Everyone Talking About It?.
Small action for today: take one AI feature idea and write the wrongness policy before anything else.
If you want a structured review of source truth, permissions, fallback behavior, and evidence for one feature, run a company context audit.
