AI Feature PRD Template

An AI Feature PRD covers a feature where a model, not deterministic logic, decides what happens next. It carries everything a Standard PRD does, plus the sections that only matter when the system can be uncertain, wrong, or manipulated: what the model should do, how you'll know if it's doing that, and what happens when it isn't.

When you need one

Write one when a model generates, judges, or decides something a human would otherwise have to — drafting text, classifying content, making a recommendation a user acts on. You don't need one for a feature that merely calls a model behind the scenes for something low-stakes and easily reversible, like a minor autocomplete suggestion; the Standard PRD template covers that fine. The test: if the model can be confidently wrong in a way a user might not catch, you need the evaluation and guardrail sections this template adds.

The template

# [Feature name] — AI Feature PRD
Owner: [name] · Status: [draft/review/approved] · Last updated: [date]

## TL;DR
[2-3 sentences: what this is, who it is for, why now.]

## Problem & why AI
[The problem, and why a model is the right approach rather than rules or a simpler heuristic.]

## User stories
- As a [role], I can [action], so that [outcome].
- As a [role], I can [action], so that [outcome].

## Goals & success metrics
| Metric | Baseline | Target | Why this metric |
| --- | --- | --- | --- |
| [metric] | [current value, or [TBD: reason, date]] | [target by date] | [why it proves the goal] |

## Model & approach
[Which model or technique, and why — off-the-shelf vs. fine-tuned, prompting strategy, retrieval, or a simpler non-model approach considered and rejected.]

## Behavior definition
[What "correct" looks like: tone, scope, what the model should refuse, what it should escalate rather than answer.]

## Cost & latency budget
[Cost per interaction at expected volume, and the latency target (e.g. p95) — with the volume at which either needs revisiting.]

## Data requirements
[Training, fine-tuning, or retrieval data needed, where it comes from, and any privacy or consent implications.]

## Evaluation plan
[How you'll know the model is behaving as defined: automated eval set, human evaluation cadence, red-teaming for the specific failure modes below.]

## Guardrails & failure modes
- [Failure mode] → [specific, testable response]
- [Failure mode] → [specific, testable response]

## Non-goals & scope
Non-goals: [explicitly out of scope]
In scope: [list]
Out of scope: [list]

## Launch plan
Phase 1 — [name]: [scope, audience]. Exit criteria: [measurable condition].
Phase 2 — [name]: [scope, audience]. Exit criteria: [measurable condition].

## Risks
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| [risk] | [H/M/L] | [impact] | [mitigation] |

## Open questions
- [Question] — Owner: [name] — Needed by: [date]

Section by section

TL;DR

Your own verdict, written before the reviewer forms theirs.

Problem & why AI

The question every AI PRD should answer and most skip: why does this need a model, rather than rules or a simpler heuristic.

User stories

Same bar as any PRD, with one addition: a story involving a model should be honest that the output can be wrong.

Goals & success metrics

The same measurability bar as any PRD, plus a metric that's about the model's behavior, not only the feature's adoption.

Model, approach & behavior definition

What the model is, and what it's supposed to do — the two questions an engineer and a reviewer both ask first.

Cost, latency & data requirements

The three constraints that determine whether this is viable at the volume the goals section is promising.

Evaluation plan

How you'll actually know the model is doing what the behavior definition says it should, before a user finds out for you.

Guardrails & failure modes

What happens when the model is uncertain, wrong, or asked something outside its scope — stated as a specific, testable response, not a hope.

Non-goals, scope & launch plan

Boundaries and rollout — logistics rather than argument. No pass maps to this group directly; it's the reviewer's check that the document is finishable, not that the feature is sound.

Risks and open questions

The risks specific to putting a model in front of users, not the generic delivery risk any feature carries.

Worked example

Here are two sections from a feature that drafts reply suggestions for a customer support inbox.

Behavior definition

The model drafts a reply suggestion, never sends automatically. Tone matches the support team's existing style guide (direct, no exclamation points, no "unfortunately"). The model refuses to draft anything committing to a refund amount, a ship date, or a policy exception — those route to a templated "needs human judgment" placeholder instead of a plausible-sounding guess.

Guardrails & failure modes

| Failure mode | Response | | --- | --- | | Model drafts a commitment (refund, date, exception) | Blocked before display; replaced with a flag for the agent to write manually | | Confidence score below 0.6 | Suggestion still shown, but visually marked as low-confidence rather than presented identically to a high-confidence draft | | Customer message contains abusive or self-harm content | Suggestion suppressed entirely; ticket flagged for a senior agent |

Both sections define testable behavior instead of aspirational tone, and the guardrails table names a specific, checkable response for each failure mode rather than a general promise.

The deliberate weakness: the 0.6 confidence threshold has no stated source — nothing in the document says whether that number came from a calibration study on this specific model and task, or was picked because it sounded reasonable. A reviewer will ask what happens at 0.59 versus 0.61 and whether the threshold was ever tested against real agent judgments of good and bad drafts. The honest fix: [TBD: 0.6 is a starting threshold, not yet calibrated — validate against 200 agent-labeled drafts before phase 2, owner: ML team, by 25 Aug]. An uncalibrated threshold dressed up as a decided one is exactly the kind of gap this template exists to catch.

Common mistakes

• "AI" as the entire justification for the feature. If nothing in the problem section explains why judgment or generation is needed, the model is a solution looking for a problem.
• Behavior defined as adjectives instead of tests. "Helpful and safe" cannot be checked by anyone. A refusal list and a tone guide can.
• An evaluation plan that's really just "we'll watch the metrics." By the time a metric moves, the failure has already reached users.
• No cost figure until the first real bill. Unit economics for a model-based feature can make or break it, and they're knowable before launch, not after.
• Guardrails with no adversarial cases. A guardrail table built only from expected inputs will miss the inputs someone deliberately tries to break it with.

Run it through a review

The AI-specific pass only fires when a document actually mentions AI or ML work — Thinkr's critique does not force it onto specs that don't need it, but it also does not skip cost, behavior definition, or evaluation when they're genuinely missing. Those three are usually where an AI feature PRD comes back first.