An example of a product requirements document for an AI feature must include sections that traditional PRDs don't need: the expected model behavior specification, the acceptable failure mode taxonomy, the human review threshold for when AI output should be escalated, and the evaluation criteria for determining whether the AI component is performing well enough to ship.
AI features fail in ways that traditional software features don't. A standard feature either works or it doesn't — the error state is binary. An AI feature can be wrong in subtle, hard-to-detect ways: it can hallucinate plausible-sounding but incorrect information, it can degrade gradually as input distribution shifts, or it can perform differently for different user segments in ways that aren't visible in aggregate metrics.
The AI PRD Additions
H3: Section 1 — Standard PRD Sections
Include all standard PRD sections:
- Problem statement
- User segment and use case
- Success metrics (primary, business impact, guardrails)
- Acceptance criteria
- Out of scope
H3: Section 2 — AI Behavior Specification
Unlike traditional features where "works as designed" is testable, AI features require explicit specification of expected behavior across different input types.
For each major input category, specify:
- Ideal behavior: What should the model output for a typical good input?
- Edge case behavior: What should happen for unusual but valid inputs?
- Graceful degradation: What should happen when the model is uncertain? (Show confidence score? Fall back to non-AI output? Ask for clarification?)
- Hard limits: What inputs should the model refuse to process or flag for human review?
Example for an AI-generated meeting summary feature:
| Input type | Expected behavior | Fallback | |-----------|------------------|---------| | Clear transcript, 30–60 min | Summary with action items and decisions | — | | Short transcript (<10 min) | Summary with note that meeting may be incomplete | — | | Transcript with no clear decisions | Summary with explicit "no decisions detected" note | — | | Transcript in a non-supported language | Detect language, prompt user to use supported language | Human review option | | Transcript with sensitive data (PII) | Redact or flag before processing | Block + alert |
According to Lenny Rachitsky's writing on AI product development, the most common AI PRD failure is specifying only the happy path — what the model should do when everything works — without specifying degradation behavior, failure modes, and the cases where human judgment should override the model.
H3: Section 3 — Failure Mode Taxonomy
Categorize the ways the AI feature can fail and specify the product response to each:
Type A — Factual error: The model produces output that is confidently wrong.
- Detection: How will this be detected? (User feedback, ground truth comparison, human review sample)
- Response: What does the product do? (Flag for review, show confidence indicator, disable feature for affected input type)
Type B — Hallucination: The model produces plausible-sounding output that has no basis in the input.
- Detection: Semantic comparison between output and input source content
- Response: Require citation to source content; flag outputs with low citation confidence
Type C — Bias: The model produces systematically different quality outputs for different user segments.
- Detection: Stratified performance analysis by user segment, language, role
- Response: Block rollout to affected segments until addressed; add to evaluation suite
Type D — Gradual degradation: Model performance degrades over time as input distribution shifts.
- Detection: Weekly performance sampling against held-out test set
- Response: Alert engineering when performance drops below threshold; trigger re-evaluation
H3: Section 4 — Human Review Threshold
Define explicitly when AI output should be reviewed by a human before being presented to the user, or when the user should be prompted to review before acting:
- Always review: High-stakes outputs (financial decisions, medical information, legal content)
- Confidence-gated review: Show AI output with a confidence score; flag low-confidence outputs for user verification
- Sample review: PM or trust/safety team reviews a random sample of outputs weekly
H3: Section 5 — Evaluation Criteria
Define how you will know the AI component is good enough to ship:
- Offline evaluation: Test set performance on labeled examples. What accuracy/precision/recall threshold must be met?
- Human evaluation: For outputs that cannot be automatically evaluated (e.g., summary quality), define the human evaluation rubric and sample size
- A/B readiness: What is the minimum offline performance required before running a live A/B test?
- Rollout gate: What live performance metrics must be met before expanding from beta to full rollout?
According to Shreyas Doshi on Lenny's Podcast, the AI feature PRD must have a "not ready to ship" definition — a specific performance threshold below which the team will not launch regardless of stakeholder pressure — because AI features with insufficient evaluation can cause harm at scale that is very difficult to reverse once users have seen unreliable outputs and lost trust.
Instrumentation Requirements for AI Features
H3: AI-Specific Events
Beyond standard product analytics, AI features require:
- Inference events: Every AI call logged with input hash, model version, latency, and output confidence
- User feedback events: Thumbs up/down, correction submitted, or output flagged
- Override events: User edited AI output before using it (suggests AI was wrong)
- Abandonment events: User requested AI output then didn't use it (suggests AI was unhelpful)
According to Gibson Biddle on Lenny's Podcast, the most important instrumentation for an AI feature is not accuracy measurement but user behavior measurement — a model that produces technically accurate outputs that users ignore or override is not a successful feature, and only behavioral instrumentation tells you whether the AI output is actually trusted and used.
FAQ
Q: How is a PRD for an AI feature different from a standard PRD? A: An AI PRD must include a model behavior specification across input types, a failure mode taxonomy with product responses, a human review threshold, and offline and live evaluation criteria — sections that traditional software PRDs don't need.
Q: What is a failure mode taxonomy in an AI PRD? A: A categorization of the ways the AI feature can fail — factual errors, hallucination, bias, and gradual degradation — with a specified detection method and product response for each.
Q: How do you set evaluation criteria for an AI feature? A: Define offline evaluation thresholds on a labeled test set, a human evaluation rubric for subjective outputs, an A/B readiness gate, and a live rollout gate based on behavioral metrics from the beta population.
Q: What is a human review threshold in an AI PRD? A: The specification of when AI output should be reviewed by a human before being presented to the user — always for high-stakes outputs, confidence-gated for uncertain outputs, or sample-reviewed for ongoing quality monitoring.
Q: What analytics events should an AI feature instrument? A: Inference events with model version and confidence, user feedback events, output correction events, and output abandonment events — behavioral signals that indicate whether AI output is trusted and used, not just technically accurate.
HowTo: Write a Product Requirements Document for an AI Feature
- Include all standard PRD sections — problem statement, user segment, success metrics, acceptance criteria, and out of scope
- Add a model behavior specification table covering expected behavior, edge case behavior, graceful degradation, and hard limits for each major input category
- Define a failure mode taxonomy with detection methods and product responses for factual errors, hallucination, bias, and gradual degradation
- Specify the human review threshold — which outputs are always reviewed, which are confidence-gated for user verification, and which are covered by random sample review
- Define evaluation criteria including offline test set thresholds, human evaluation rubrics, A/B readiness gates, and live rollout gates based on behavioral metrics
- Specify AI-specific instrumentation including inference events with model version and confidence, user feedback events, correction events, and abandonment events