Step 3 of 7: From Idea to Impact
A traditional PRD defines what the feature does. An AI PRD has to also define what happens when it's wrong, because it will be. If your PRD doesn't have a section for "acceptable failure modes" and "fallback behavior," it's not ready for engineering.
Data requirements: not "we'll use the transaction database," but which fields, what freshness SLA, what happens when a field is null, who owns fixing upstream data quality issues discovered mid-build.
Eval criteria: the specific, numeric bar the feature must clear before launch, tied to a labeled eval set, not a vibe ("it should feel accurate").
Confidence thresholds: at what model confidence does the system auto-act vs surface for human review vs refuse entirely? Three thresholds, not two. Teams that only define "confident vs not confident" end up either over-automating or over-escalating.
Human-in-loop points: exactly which steps have a human checkpoint, who that human is, and what SLA they operate under. If this isn't specified, it defaults to "nobody," which is how ungoverned AI actions ship.
Kill criteria: the specific metric and threshold that triggers a rollback, decided before launch, in writing, so it's not negotiated under pressure after a bad week of production data.
2. Claude Prompt Chain for PRD Generation: the prompt that forces your PRD to expose gaps instead of filling them in with confident-sounding boilerplate.
3. Fill-in AI-PRD Template: the success metrics tree and 3-tier failure mode table, ready to copy.
4. Worked Example: the exact confidence bands and kill criteria used for the dispute-resolution feature, and where the numbers actually came from.
5. Common Pitfalls: why writing eval criteria as adjectives instead of numbers is the most common way AI PRDs fail engineering review.
6. Nuance Most Guides Skip: why AI success metrics need a target range, not a single number, before launch.