--- title: "How to Write a PRD for AI Features" description: "An AI feature spec needs four things a normal PRD does not: an eval set, guardrails, named failure states, and a policy for what happens when the model changes." canonical_url: "https://builderscamp.com/guides/templates/how-to-write-a-prd-for-ai-features" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Inês Lourenço" publisher: "Builders Camp" guide_class: "templates" --- # How to write a PRD for AI features **TL;DR:** An AI feature PRD adds four sections a normal one does not have: the eval set that defines good, the guardrails that bound the system, the named failure states with a designed response for each, and the policy for what happens when the model changes underneath you. Acceptance criteria still apply to the deterministic parts, and only to those. ## What does an AI feature spec carry that a normal PRD does not? Four sections, and they are not decoration on top of the usual document. They replace the part of a normal PRD that quietly assumed the same input always produces the same output. A conventional spec can rely on acceptance criteria because software is deterministic: press the button, get the behaviour, verify it once. An AI feature breaks that assumption at the first sentence. The same prompt produces different text on Tuesday than it did on Monday, a model upgrade you did not schedule changes the distribution of answers, and a single failing case proves nothing about the rate at which that failure happens. The [PRD template](https://builderscamp.com/guides/templates/prd-template) still holds for problem, goals, non-goals, users, and the cut line. What follows is what you add. ## How do you write the eval set into the document? Name it, source it, and state the bar, in the PRD itself rather than in an engineering ticket nobody outside the team reads. Anthropic's own guidance on defining success criteria puts the evaluation ahead of the build for the same reason: a criterion you cannot measure is a preference, and preferences do not survive a launch argument. So the section reads as three lines. Where the examples come from, which is real usage, real support tickets, or your own honest attempts to break the thing, never inputs invented to be easy. What good means, written as a rubric a second person could apply and reach the same answer. And what bar ships, stated as a number you chose deliberately. The limit of an eval score is worth writing down beside it. A score of any size tells you the output matches a rubric you already believed in. It cannot tell you the rubric was wrong, which is the failure mode that produces a technically passing feature nobody wants. Pair the offline score with one behavioural metric, such as how often a user edits or discards the output, and treat a gap between the two as the signal it is. For the mechanics of building the set itself, see [how to write evals for AI products](https://builderscamp.com/guides/tools/how-to-write-evals-for-ai-products). ## What belongs in the guardrails section? Four boundaries, written as constraints rather than intentions. What the system may read, named as specific data sources rather than a general permission. What it may do without asking, separated from what needs a human approval before it executes. What it must refuse, including the cases where refusing is the correct product behaviour rather than a gap. And what happens when it is asked something outside its scope, because an unspecified out-of-scope response becomes an improvised one. Most teams write the first two and skip the last two, then discover in production that the interesting failures all live there. Builders Camp's AI Agents bootcamp makes the same point from the building side: most failures trace to missing guardrails, not to weak models. The spec is where that observation turns into something reviewable. See [AI guardrails](https://builderscamp.com/guides/glossary/ai-guardrails) for the constraint types themselves. ## Why do failure states get their own section? Because an AI feature fails in ways a form does not, and the design of the failure is a product decision you either make in advance or improvise under pressure. Write each failure state with the response you have chosen for it: the model is confidently wrong, the model refuses something legitimate, the model is slow enough that the user leaves, the upstream provider is unavailable, and the output is plausible but unverifiable. That last one is the expensive case. A wrong answer that looks wrong gets caught. A wrong answer that looks right gets acted on, and the cost lands somewhere downstream from your feature. The AI Product Management bootcamp's practical challenge is built around exactly that shape of problem: an AI triage feature that turns out to be biased, an incident already in progress, and a decision to make where nobody built the feature to discriminate and that does not make it acceptable. Working through the response before launch is cheaper than composing it during an incident. ## What does the requirements section look like when output is probabilistic? Split it in two, and label both halves. - **Deterministic requirements** keep normal acceptance criteria: the disclosure renders, the response streams within a stated time budget, the user can edit and resubmit, the audit log records the input and the output. - **Probabilistic requirements** carry a rubric and a bar instead: the summary names every action item present in the transcript, scored against the rubric, at the bar you set. - **Human-in-the-loop requirements** name the moment control passes back to a person, which action triggers it, and what the person sees when it does. That split is what stops a QA engineer from being handed a story they cannot test. It also makes the spec honest about which parts of the feature you are promising and which parts you are measuring. ## Does any of this change if you are only calling an API? It changes the ownership, not the work. Buying the model does not outsource the eval set, the guardrails, or the disclosure; it outsources the training. The NIST AI Risk Management Framework is organised around mapping, measuring, and managing risk in the deployed system rather than in the model artefact, and a PRD is where a product team does the mapping in language the rest of the company can read. The honest limitation is cost. Writing all four sections properly adds real time to a spec, and for a low-stakes internal tool that time is not always well spent. Scale it to the blast radius: a feature that drafts a suggestion a user edits before sending needs far less of this than a feature that classifies a customer, moves money, or acts without review. Deciding which one you are building is itself a decision the PRD should record. ## The objection worth answering Somebody will say this is a normal PRD with more sections, and that the team can figure out evals later. They are half right. The sections are recognisable. What changes is the order in which the uncertainty gets resolved: in a conventional spec, the hard part is deciding what to build, and the build is predictable afterwards. In an AI feature, deciding what to build is the easy half, and the hard half is finding out how often the thing is wrong and what that costs. Writing the eval set and the failure states into the document is what moves that discovery before the launch instead of after it. ## Where this is taught end to end Builders Camp's AI Product Management bootcamp runs 2 weeks across 4 live sessions, structured almost exactly as this page is: meeting the AI PM role, defining good through evals, designing the agent environment and its guardrails, then capturing the value. Its own framing is that evals replace acceptance criteria and the launch gate, not discovery, which is the distinction most specs get wrong in their first draft. If your feature acts rather than answers, AI Agents covers tool use, orchestration, memory, and human approvals across 2 weeks and 3 live sessions. The AI Product Expert Track bundles both alongside prompting and responsible rollout for PMs who want the ordered path rather than a single bootcamp. [See the AI Product Management bootcamp](https://builderscamp.com/bootcamps/ai-product-management?utm_source=guide&utm_medium=organic&utm_campaign=how-to-write-a-prd-for-ai-features) One section almost nobody writes, and should: the deprecation plan. Name in advance what evidence would make you turn the feature off, because an AI feature that quietly degrades is harder to kill than one that fails loudly, and the team that shipped it is the worst placed to notice. ## Frequently asked questions ### What is actually different about a PRD for an AI feature? Four sections a normal PRD does not have: an eval set that defines good, guardrails that bound what the system may do, named failure states with a designed response for each, and a policy for what happens when the model version changes. Everything else in the document stays the same. ### Do acceptance criteria still work for an AI feature? Only for the deterministic parts, like whether the response renders or whether a disclosure appears. The quality of the output itself needs an eval set scored against a rubric, because the same input can produce different text twice and a binary pass or fail cannot describe that. ### How many examples should the eval set in the PRD have? Name the set, the source of its examples, and the bar, rather than the count. A first set built from real usage and real support tickets is more useful than a larger set written from imagination, because invented inputs rarely reproduce the way your own product breaks. ### What counts as a guardrail in a spec? A written boundary on what the system may see, may do, and may decide alone. Which data sources it can read, which actions need a human approval before they execute, what it must refuse, and what happens when it is asked something outside its scope. ### Does the PRD need to say anything about disclosure? Yes, where the feature interacts with people directly. The EU AI Act's Article 50 sets transparency obligations including informing people they are interacting with an AI system, so the disclosure is a requirement to specify, not a copy decision to settle later. ### How do you write a success metric for an AI feature? Pair an offline metric with an online one. The eval score tells you whether the output meets the rubric before launch. A behavioural metric, such as how often users accept or edit the output, tells you whether the rubric was the right one, which the eval set can never tell you by itself. ### What should the PRD say about model upgrades? Which model version the spec was validated against, who re-runs the eval set when it changes, and what score drop triggers a rollback. Without that, a silent provider upgrade becomes an unplanned change to your product that nobody reviews. ## Sources - [Claude Platform Docs: Define success criteria and build evaluations](https://docs.claude.com/en/docs/build-with-claude/define-success) - [EU Artificial Intelligence Act, Article 50: Transparency obligations](https://artificialintelligenceact.eu/article/50/) - [NIST: AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.