About a year ago I was reviewing a PRD for an AI feature my team was about to ship. It had user stories, acceptance criteria, three mockups, a list of edge cases, and a paragraph at the bottom that read, in essence, "the LLM will return a good answer". I sent it back.
The problem wasn't that the PRD was bad. It was that the template we used didn't have the right slots for AI work. The deterministic-software template silently treated the model as a black box that would Just Work. For features with deterministic output, that's fine. For features that fail in distinct ways (wrong answer, slow answer, expensive answer, made-up answer), you need slots that name those failures.
I've been iterating on a template since. It has four sections the team's original format didn't. Sharing them here in case they're useful.
1. The rubric
Before any user story, the PRD opens with a rubric. Three to five criteria, each with a 1–5 scale, each tied to a concrete check.
For a customer-support AI:
- Accuracy (1–5): does the response answer the user's actual question?
- Tone (1–5): does it match our brand voice (direct, warm, no jargon)?
- Brevity (1–5): is it under 100 words?
- Hand-off (1–5): does it route to a human when it should?
The rubric is the contract. It defines what "good" means for this feature before anyone designs the UI or specs the prompt. Without it, every reviewer judges the feature against their own private criteria and arguments don't converge.
It's the single highest-leverage section in the PRD. I've watched one save twenty hours of "the AI is wrong / no it isn't" debate.
2. Hallucination tolerance
This sounds dramatic. It's not. Every AI feature has a tolerable rate of fabricated content, even if that rate is zero. The PRD needs to state it explicitly.
Three buckets I use:
- Zero-tolerance: legal text, medical guidance, customer account data, anything where a wrong answer costs money or trust. The feature must cite sources, refuse when uncertain, and route to a human path on low confidence.
- Low-tolerance: in-product suggestions, draft copy for review, summaries the user will read. Wrong answers are user-correctable; the system shouldn't bear false weight.
- Best-effort: brainstorming, name generation, exploratory output the user uses as a creative starting point. Here a "wrong" answer often isn't wrong, it's just one of many.
Each bucket implies different infrastructure. Zero-tolerance needs retrieval + citations + confidence thresholds + escalation. Best-effort needs almost none of that. The PRD picks the bucket. Engineering builds to it.
3. Cost ceiling
The boring section. Also the section I see PMs skip and then get burned by.
I write it as a per-call cost target and a monthly total. Example:
- Target per-call cost: $0.005 (assuming Claude Haiku or equivalent).
- Hard ceiling per-call: $0.02. Engineering should alert if this is breached.
- Monthly cost ceiling: $5,000 across forecasted volume.
- If we breach the ceiling: the fallback path (section 4) takes over until volume normalises.
This forces the cost conversation up front. AI features have a marginal cost that grows with usage. PMs who don't model it ship features that look great in pilot and quietly hemorrhage budget at scale.
4. Fallback path
What happens when the model is slow, expensive, down, or just wrong?
I make engineering and design map this in the PRD itself. Three failure modes get explicit handling:
- Timeout (>5s for synchronous, >30s for async): graceful degradation to a non-AI path or a "still thinking…" UX with a cancel option.
- Rate-limit or upstream error: queue, retry with backoff, or fall back to a deterministic alternative. Never silently fail.
- Low-confidence output: when the model returns something the rubric scores below threshold, the system either re-prompts, escalates, or falls back to a human-in-the-loop path.
The fallback is what makes the feature usable under realistic operating conditions. Skip it and your support team becomes the fallback. They will notice.
What the template doesn't change
User stories, acceptance criteria, mockups, dependency lists, success metrics: all still there. The four AI-specific sections sit on top. The total PRD length goes up by maybe 40%. That's a fair price for catching the four most common AI-feature failure modes in review instead of in production.
One thing I'd warn against
Don't write the rubric after the feature is built. Write it before. The whole point is to commit to a definition of "good" while it's still possible to discover that you haven't built it yet.
If you find yourself writing the rubric to match outputs you've already seen, you're optimising for shipping, not for being right. That's a meta-failure the rubric was supposed to prevent.
I'll know the template is wrong when a feature ships clean against all four sections and still flops with users. That hasn't happened yet. The day it does, I'll write a follow-up.
Further reading
- Claude Haiku: Anthropic's lightweight model; the cost example in section 3 assumes this tier.
- Claude pricing: per-million-token rates for Haiku / Sonnet / Opus; the ceiling math in section 3 starts here.
