What This Template Covers
The PRD template for AI products covers nine sections that together define what the product does, how the AI component fits into it, and what it means for the product to work correctly. The problem statement section establishes why this product needs to exist, what specific user pain it addresses, and what the business outcome is if it works. This section should be written before any discussion of solutions. The user personas section defines who uses the product, what they currently do without it, and what success looks like for them. AI products often serve two types of user: the end user who interacts with the AI output, and a secondary user such as a business administrator who configures or monitors the AI. Both need to be defined. The user stories section translates personas into specific interactions. For AI products, user stories need to include stories for the AI-generated outputs as well as the conventional UI interactions. The AI model requirements section is where this template differs from a standard PRD. It covers: which AI capability is required (text generation, classification, search, summarisation, image understanding), what performance characteristics are required, what the acceptable latency range is, how the product behaves when confidence is low, and what the cost constraints are at scale. The data requirements section covers what data the AI system needs to function, where it comes from, who owns it, and what preparation it needs. The evaluation criteria section defines what "the AI is working" means in measurable terms. The compliance section covers GDPR, EU AI Act classification, and sector-specific requirements. The integration architecture section maps how the AI component connects to the rest of the product. The launch plan section covers phased rollout, monitoring setup, and feedback collection.
How to Use This Template Step by Step
Step one: write the problem statement with the following structure. Current situation (what users do today). Pain point (what is wrong with the current approach). Desired outcome (what a working solution looks like). Business case (why solving this problem is worth the investment). Do not mention technology in the problem statement. Step two: define user personas. For each persona, document their role, their current workflow, their technical literacy, and their tolerance for AI errors. That last point matters specifically for AI products. A persona who is a domain expert will catch AI mistakes quickly and may distrust an AI that makes errors. A persona who is a novice may over-trust AI outputs. Both scenarios have different design implications. Step three: write user stories. Use the format "As a [persona], I want to [action], so that [outcome]." For AI-specific interactions, add a fourth line: "The AI output must [quality criterion]." For example: "As a legal analyst, I want to upload a contract and receive a summary of key obligations. The AI output must identify all clauses related to termination, payment terms, and liability with no significant omissions." Step four: complete the AI model requirements. Specify the capability type. Set a maximum acceptable latency. Define what happens when the model returns a low-confidence result: does the product show the output with a warning, withhold it and show a fallback, or escalate to a human review queue? Set a cost ceiling per request and per month. Step five: map data requirements. Create a table: data type, source, volume, update frequency, preparation required, GDPR basis for processing, retention period. This table becomes the input to your AI data requirements planning. Step six: write evaluation criteria. For each AI output type, define at least one quantitative metric and one qualitative review process. Quantitative examples: precision and recall for classification, BLEU or ROUGE scores for summarisation, task completion rate for assistants. Qualitative: expert review of 50 sample outputs per week. Step seven: complete the compliance section. Note the EU AI Act risk classification for your use case. Note any GDPR considerations including the lawful basis for any personal data processed by the AI. If the product operates in fintech (FCA), healthtech (NHS Digital or MHRA), or education, note the sector-specific requirements. Step eight: define the integration architecture. Which AI provider API is being used? What is the call pattern? How are prompts constructed and versioned? What is the error handling strategy? Step nine: write the launch plan. Phased rollout is strongly recommended for AI products. Phase one: internal testing with known data. Phase two: closed beta with selected users. Phase three: general availability with monitoring in place.
Section-by-Section Walkthrough
The problem statement section should be no more than one page. If it runs longer, you are drifting into solution space. Keep it diagnostic. The strongest problem statements are specific: they name the user type, describe the exact friction point, and quantify the cost of the problem if possible. The AI model requirements section needs to address four questions that standard PRDs never ask. First: what is the minimum acceptable quality bar for AI outputs, and how will you measure it? Second: what happens when the AI is wrong? AI systems make errors. The product design needs to account for this at the requirements stage, not as an afterthought. Third: what is the cost model? AI API calls have per-token costs that scale with usage. A product that is free to prototype can be expensive at scale. Cost constraints belong in the PRD. Fourth: what are the prompt design requirements? If specific information needs to be included in every model call (user context, previous interactions, document extracts), that is a data architecture requirement that affects the entire system design. The data requirements section often reveals the biggest risks in an AI project. Common blockers include: the data exists but is not accessible without legal agreements, the data exists but is too dirty to use without significant cleaning, the data does not exist yet and needs to be created through the product itself, or the data contains personal information that restricts how it can be used under GDPR. Document these honestly in the PRD. A product that depends on unavailable data is not ready to build. The evaluation criteria section should name who is responsible for running evaluations, how often they are run, what the threshold for action is, and what action is taken when quality drops below threshold. This is particularly important for products that are continuously updated or that use fine-tuned models. The compliance section for AI products needs to address the EU AI Act if your product will be sold in the EU or UK. Note that the EU AI Act has direct implications for high-risk AI systems including those used in employment, credit scoring, education, and healthcare. The ICO has also published guidance on AI and data protection that is relevant to any UK-based product using AI to process personal data.
Common Mistakes This Template Prevents
The most common mistake in AI PRDs is defining the product in terms of the technology rather than the user outcome. "We will use GPT-4o to summarise documents" is a technical specification, not a product requirement. The requirement is "Users need to understand the key obligations in a contract in under two minutes without reading the full document." The technology choice follows from the requirement. The second common mistake is omitting failure mode requirements. Every AI system produces incorrect outputs. The PRD must specify what the product does when this happens. Does it show the output with a confidence indicator? Does it present multiple options? Does it route to human review? Products that do not address failure modes in the PRD end up with ad hoc decisions made during development that often result in poor user experience. The third mistake is ignoring the evaluation criteria until after launch. If you do not define what "good" looks like before build starts, you will not know whether you have built a good product. Evaluation criteria also drive test data requirements, which need to be identified early. The fourth mistake is treating compliance as a legal department issue rather than a product design issue. GDPR, EU AI Act, and sector-specific regulations have direct implications for what data you can collect, how long you can store it, what decisions the AI can make autonomously, and what disclosures you must make to users. These constraints affect product design. They need to be in the PRD.
Customisation Tips for Different Project Types
For LLM-based products such as chatbots, writing assistants, or document analysis tools, add a prompt design section to the PRD. This should cover: the system prompt structure, what context is injected per user session, how the product handles sensitive topics or off-topic requests, and how prompts are versioned and tested. For classification or prediction models, add a model performance section with precision, recall, and F1 score requirements. Define acceptable performance separately for different user groups if fairness is a concern. The Equality Act 2010 and the ICO's guidance on AI fairness are relevant here for UK products. For RAG (retrieval-augmented generation) systems, add a knowledge base management section. Who can add or remove content? How is content quality controlled? How frequently is the knowledge base updated? What happens when the retrieval returns no relevant results? For enterprise products where the AI makes decisions that affect individuals (credit, employment, healthcare triage), the PRD must include an explainability section. Under GDPR Article 22, individuals have the right not to be subject to solely automated decisions that significantly affect them. The product must either avoid such decisions or provide a human review mechanism and an explanation of the decision logic.