AI Feature PRD Template, with prompts

How to use this template

Copy the sections below into your doc tool. Work through them in order, because later sections depend on earlier decisions. Each section has a short note on what to decide and a prompt you can paste into an AI assistant along with your own notes.

Placeholders sit in square brackets. Replace them before you share the document.

The template extends the PRD-first approach from the AI Vibe Coding programme: write down what the product is for before any tool starts building it. A generator fills every gap in a vague spec with its most likely default, and an AI feature has more gaps than most.

1. Problem and person

Name one person and the job they are trying to get done. Describe how they do it today. Write down what the current workaround costs them in time, money or mistakes.

Prompt: I am writing a PRD for an AI feature. Here are my notes on the user and their problem: [notes]. Ask me five questions that would make the problem statement more specific. Then draft a problem statement of three sentences or fewer that names one user, their job and their current workaround.

2. Why AI, and how much

Decide whether the job needs a model at all. Many jobs fit a fixed workflow better than an agent. Anthropic's guide to building effective agents recommends the simplest solution that works, and adding complexity only when it improves the result.

Then pick an autonomy level for each step. Feng, McDonald and Zhang define five levels by the user's role: operator, collaborator, consultant, approver and observer.

Prompt: Here is the job the feature supports: [job]. List the steps. For each step, say what should handle it (a model, a fixed rule or a person) and why. Then propose an autonomy level for each model step, using the user roles operator, collaborator, consultant, approver and observer. Flag any irreversible step.

Our note on levels of autonomy for AI agents covers this decision in depth.

3. Inputs and context

List what the model sees: user input, documents, records, tool results. Note the source and owner of each one. Flag anything that holds personal data. For Malaysian users, check how personal data is handled under the Personal Data Protection Act 2010.

Prompt: Here are the data sources the feature could use: [sources]. For each one, list what the model needs from it and what it should never see. Add the privacy question we must answer before launch.

4. Output and states

Describe the good answer, then every other state the user can meet: empty, working, unsure, wrong, corrected and handed off to a person. For each state, write what triggers it, what the user sees and what they can do next.

Prompt: Here is the feature and its happy path: [description]. Draft one line each for these states: empty, working, unsure, wrong, corrected, handed off. For each, give the trigger, what the user sees and the next action available. Point out any state where the user could act on a wrong answer without noticing.

Design the states the AI demo skips explains each state with examples.

5. Success metrics and evals

Separate product metrics, such as task completion or time saved, from output quality. For output quality, start from real examples. Hamel Husain and Shreya Shankar's AI evals FAQ puts error analysis on real traces first, and recommends binary pass or fail criteria over rating scales. If you plan to use a model as the judge, check its verdicts against human labels before you rely on it.

Prompt: Here are 10 example inputs and the outputs we would accept: [examples]. Propose binary pass or fail criteria for output quality, each one checkable by a person in under a minute. Then list the failure types you would expect to see in real traces, and how we would spot each one.

Our note on LLM error analysis as user research shows how a designer and a PM can read traces together.

6. Guardrails and risk

List what the feature must never do and what needs human approval. Describe what happens when a guardrail triggers. Name who reviews incidents.

Prompt: Here is the feature, its autonomy levels and its data: [summary]. List the ways it could cause harm to the user, to other people or to the business. For each, propose a guardrail and say what the user sees when it triggers.

7. Cost and speed budget

Set a ceiling for cost per request and for waiting time at the busiest step. These two numbers shape model choice, caching and how much context you send.

Prompt: Here is the expected usage: [requests per day, typical input size]. Estimate the cost per request and per month for two model options, and the likely waiting time. List two ways to cut cost that would not hurt the pass rate from section 5.

8. Build plan

Describe the prototype scope, the stack and what gets tested with users before any production work. You can test much of an AI feature before the model exists with NN/g's Wizard of Oz method, where a person plays the AI.

Prompt: Here is the PRD so far: [sections 1 to 7]. Propose the smallest prototype that would let us test the riskiest assumption with five real users. List what to build, what to fake and what to leave out.

9. Rollout and feedback loop

Decide who gets the feature first and how you collect traces and feedback. Agree up front on the result that sends it back to the drawing board.

Prompt: Here is the feature and its success metrics: [summary]. Draft a rollout plan in three stages, with the group, the length of each stage and the result that would stop or roll back the release.

10. Open questions

List every decision still open, with an owner and a date. A PRD with honest open questions beats one that pretends to be finished.

Prompt: Read this PRD: [full draft]. List every place where it assumes something it has not decided, and phrase each as a question with a suggested owner.

Before you share it

Run the finished PRD against the AI Slop Test, row 3 in particular. If the states section only covers the happy path, the PRD is not ready.

If you want a PM or designer to work through this with your team, see product management consulting. If you are a PM moving into AI product work and want feedback on your own PRD, see 1-on-1 coaching.