The standard PRD template — problem statement, user stories, acceptance criteria, success metrics — works for features with deterministic behaviour. Either the button does what it's supposed to or it doesn't. Either the filter returns the right results or it doesn't. You define what "correct" means and engineering builds toward it.
AI features don't work like that. The output exists on a probability distribution. The model produces a range of outputs — some excellent, some acceptable, some unusable. Your PRD has to specify where the acceptable range ends, what happens when output falls outside it, and how that determination gets made in production. Standard templates have none of this.
When a PM uses a standard template for an AI feature, the engineering team ends up filling in the gaps — making model choice decisions, confidence threshold decisions, and fallback behaviour decisions that belong in the PRD. Those decisions don't get made consistently, and they don't get made with user impact in mind. They get made based on what's easiest to implement.
The Five Sections an AI PRD Needs That a Standard Template Doesn't
1. Model selection rationale
If the feature uses a foundation model (Claude, GPT-4, Gemini, etc.), the PRD should specify which model — or model tier — and why. This is a product decision, not just an engineering one: it affects latency, cost per request, context window limits, content policy constraints, and output quality on your specific task.
What to include:
- The model and version, with the rationale (e.g. "Claude Sonnet 4.5 — chosen for its balance of quality and latency on structured extraction tasks; Opus tested but P95 latency was unacceptable for real-time UX")
- Acceptable fallback model if the primary is unavailable
- Known model limitations that affect this feature (content policy restrictions, max output length, etc.)
If you're not specifying this in the PRD, engineering will make the choice — often defaulting to whatever they're already using, regardless of whether it's the right fit for this specific task.
2. Input/output specification with edge cases
For a deterministic feature, the output spec is simple: given input X, return output Y. For an AI feature, you need to specify the structure and acceptable range of outputs, not just the happy path.
PRDs that only specify "the AI will generate a summary of the document" leave engineering to define: max length, required fields, what to do with documents over the context window, how to handle non-English input, what constitutes a malformed or unusable summary, and who decides.
What to include instead:
- Input constraints: Max length, supported formats, language requirements, what happens with inputs that exceed limits
- Output structure: Required fields, format (markdown/plain/JSON), max length, tone requirements
- Edge cases: Empty input, input in unsupported language, input that's ambiguous or contains errors, input that triggers model content restrictions
- Out-of-scope content: What the model should not produce — important for features in sensitive domains
3. Confidence threshold decisions
Some AI tasks produce outputs with associated confidence signals. Classification tasks, extraction tasks, and structured output tasks often allow you to specify how confident the model needs to be before the output is used directly vs. flagged for review vs. rejected.
This is a product decision — it trades off precision against recall, and it has direct user experience implications. If you set the threshold too high, the feature sends too many outputs to manual review and the automation value disappears. Too low, and low-quality outputs reach users.
"Confidence thresholds are product decisions, not engineering ones. They belong in the PRD."
What to include:
- Whether the feature uses confidence-gated outputs at all
- If yes: the accept/review/reject thresholds and the rationale
- Who reviews outputs in the "needs review" bucket, and what the SLA is
4. Fallback behaviour specification
What happens when the AI output is unusable? The model returns empty output. The output fails a quality check. The API call times out. A refusal fires because the input hit a content restriction. The model hallucinates a field value that breaks downstream parsing.
Every AI feature needs a fallback, and the fallback is a product decision. The options are usually: graceful degradation (show the user a manual alternative), retry logic (with what parameters), escalation to a human, or surfacing an error state. Which one depends on the feature context, the cost of a failed output, and the user experience tradeoffs — things a PM should be deciding, not an engineer.
Specify the fallback for each failure mode separately — a timeout has a different appropriate response than a model refusal, which is different from a malformed output. One line for each failure mode is enough to prevent engineers from making ad hoc decisions under time pressure.
5. Evaluation criteria engineering can test against
The acceptance criteria section of a standard PRD typically looks like: "User can generate a summary. Summary is displayed in the results panel. Summary loads in under 3 seconds." These are testable with standard QA.
AI output quality isn't testable the same way. You need evaluation criteria that are both meaningful and measurable. The most common approaches:
| Method | What it tests | When to use |
|---|---|---|
| Human eval rubric | Output quality on dimensions you define (accuracy, completeness, tone match) | Features where "good" is subjective but you can define criteria |
| LLM-as-judge | Uses a second model to rate output quality against your criteria | High-volume testing where human eval is too slow |
| Golden set comparison | Compares model output against a set of human-approved reference outputs | Structured tasks where correct output can be pre-defined |
| Downstream metric proxy | Tracks user action after AI output (edit rate, acceptance rate, regeneration rate) | After launch, to measure real-world quality |
The PRD should specify which evaluation approach will be used pre-launch, what score constitutes "ship-ready," and what the ongoing monitoring metric will be post-launch.
That gap is exactly what the AI PRD Writer skill for Claude was built to close.
The Sections That Stay the Same
The AI-specific sections above are additions, not replacements. Your AI PRD still needs:
- Problem statement — what user problem the feature solves and why it matters now
- User stories — the specific actions a user takes and the outcome they expect
- Non-functional requirements — latency, availability, privacy/data handling, cost per request
- Success metrics — how you'll know the feature is working three months post-launch
- Out of scope — what this feature explicitly does not do
What changes is the depth of the output specification and the addition of the AI-specific sections above. The sections engineers care most about in any PRD — the ones that prevent ambiguous implementation decisions — are precisely the ones that AI PRDs most commonly omit.
Common Questions
Put this to work: the AI PRD Writer skill for Claude turns everything above into one guided workflow you run in a normal Claude chat. Not ready to buy? Start with a free Claude skill and see how it works first.