AI Feature PRD: [Feature name]

Product requirements document for a feature powered by a machine learning model or large language model. Beyond a normal PRD it covers why AI is the right approach, how the experience handles wrong or uncertain outputs, model options, data needs, product and model metrics, an evaluation plan with acceptance thresholds, responsible AI review, human oversight, cost per request, latency, experimentation, monitoring and legal review. Based on common industry practice. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Problem and users
2. Goals and non-goals
3. Why AI
4. User experience
5. Requirements
6. Model and approach options
7. Data needs
8. Success metrics and evaluation
9. Responsible AI and human oversight
10. Cost and latency
11. Rollout and experimentation
12. Monitoring
13. Legal, privacy and security
14. Launch checklist
15. Open questions and appendix

1. Problem and users

1.1 Problem statement

[Who has what problem, when, and what it costs them.] Example: Small business owners using our invoicing app spend a median of 11 minutes per week categorising expenses by hand; 34% of expenses stay uncategorised at month end, which breaks their tax reports.

1.2 Evidence

1.3 Users and personas

2. Goals and non-goals

3. Why AI

[Summarise why AI is needed and what happens if it underperforms.] Example: Rules cover half of expenses; the long tail of merchants needs a learned model. If accuracy falls below threshold, the feature falls back to rules only.

4. User experience

4.1 Main flow

1. User adds an expense (photo, bank import or manual).
2. System suggests a category within [1] second and marks it as suggested.
3. User accepts with one tap, picks another category, or ignores.
4. Corrections are stored and used to personalise future suggestions.

4.2 Uncertainty display

4.3 Failure and edge states

4.4 Transparency and control

[Example: An info icon explains "Categories are suggested by an automated model based on merchant and amount. Check them before filing." Settings let users turn suggestions off.]

5. Requirements

6. Model and approach options

Decision: [Example: fine-tuned small transformer. Revisit if top-1 drops below 0.86 or if multilingual support is required.]

7. Data needs

See [Datasheet for the training dataset] for full documentation.

8. Success metrics and evaluation

8.1 Metrics

8.2 Evaluation plan and acceptance thresholds

The minimum sample per arm to detect a change of $\delta$ in a proportion $p$ with significance $\alpha$ and power $1-\beta$ is approximately

Example: $p = 0.06$, $\delta = 0.01$, $\alpha = 0.05$, $1-\beta = 0.8$ gives $n \approx 2 \times 7.85 \times 0.0564 / 0.0001 \approx 8{,}860$ per arm.

9. Responsible AI and human oversight

10. Cost and latency

For a self-hosted model, cost per request is driven by GPU time. With instance cost $c_h$ per hour and sustained throughput $r$ requests per second per instance at target utilisation $u$:

Example: $c_h = \text{\textdollar}1.20$, $r = 150$, $u = 0.6$ gives $C_{\text{req}} \approx \text{\textdollar}0.0000037$, about $\text{\textdollar}0.004$ per thousand requests; at 2.5 million requests per month, about $\text{\textdollar}9$ plus a fixed minimum of two instances ($\approx \text{\textdollar}1{,}730$ per month).

11. Rollout and experimentation

Rollback: [Example: feature flag expense_ai_suggest off returns to rules only within one minute; stored suggestions stay labelled].

12. Monitoring

13. Legal, privacy and security

14. Launch checklist

15. Open questions and appendix

Standard and licence note

Based on common industry practice for product requirements of AI-powered features, including standard sample-size estimation for A/B tests. Original text written for this collection; example numbers and prices are illustrative. Template licence: MIT.