The first time I wrote a PRD for an AI feature, I used the same template I used for everything else. Problem, goal, scope, success metrics. It looked complete.
Two weeks into the build, engineering asked me what the model should do when the source material didn't contain the answer. I didn't have one. A week after that, someone asked what an acceptable cost per request was. I didn't have that either.
A regular PRD assumes the feature behaves predictably. That gap is a big part of what an AI product manager actually does. An LLM feature doesn't, so the document needs a few extra sections. I've written separately about the one-page PRD I use for normal work. This is what I add on top when the feature is model-backed.
1. What a good output looks like
Write two or three example inputs with an example of a good response, an acceptable one, and an unacceptable one. Real examples, not descriptions.
This is the section engineers and reviewers will come back to most. "The answer should be helpful and accurate" doesn't tell anyone anything. A concrete bad example does.
2. The evaluation set
Say where the test cases will come from and who owns them. Include the awkward ones: ambiguous requests, questions with a false premise, inputs in a different language, cases where the right move is to decline.
You don't need hundreds on day one. You do need agreement that this set is what "ready" will be judged against. The AI evaluation checklist has more on what to put in it.
3. Failure behaviour
| Situation | What the feature should do |
|---|---|
| No supporting information in the source | Say so and suggest a next step |
| Request is ambiguous | Ask a clarifying question if it changes the answer |
| Model or provider times out | Show a clear error and keep the user's input |
| Output fails a format or safety check | Don't show it; retry or fall back |
| User asks for something outside their access | Refuse, and enforce it in the application, not the prompt |
This table is the part of an AI PRD I'd fight hardest to keep. If failure behaviour isn't specified, it gets decided by whoever writes the code, usually under deadline.
4. Cost and latency limits
Give a target range for response time and a ceiling for cost per request or per user per month. Rough is fine. Without a number, the team has no way to judge whether a bigger model or a longer prompt is acceptable.
At WiZR, building content generation for enterprise clients, cost per output was a real constraint on what we could offer at each price point. It belonged in the requirements from the start.
5. Data rules
Which data can go to the model? Which can be logged? Can customer content be used to improve prompts or evaluation, and under what agreement? Who can see stored outputs?
These usually need legal or security input, so list them early as open questions with owners. Finding out at the security review that you can't log prompts is a bad week.
6. Human review
If outputs get reviewed before they're used, say who reviews them, at what point, and what they're checking for. If they don't get reviewed, say why that's acceptable for this use case.
7. What will change after launch
AI features need ongoing tuning. Note who owns prompt changes, how they get tested before release, and how often you'll review real outputs. Otherwise the feature ships and slowly drifts with nobody watching.
How long it ends up
With these added, my AI PRDs are usually two pages instead of one, plus a linked evaluation sheet. I'm fine with that. The extra page answers the questions that otherwise turn up in week three, when changing direction is expensive.