A 2026 AI PRD is structurally different from a 2018 SaaS PRD. In a SaaS PRD, the user-story tree carried the spec. In an AI PRD, the user-story tree is decorative — the eval set is the spec. This article walks the ten sections of a defensible AI PRD with example fragments and a worked scenario.
This is a spoke under the idea validation playbook within the idea-to-product manifesto. The playbook describes the 1-2 week operating sequence; this article describes the artifact.
Table of Contents
- Why the 2018 PRD broke
- The ten sections of a 2026 AI PRD
- A one-page worked example
- Frequently Asked Questions
- Closing
Why the 2018 PRD broke
A 2018 SaaS PRD assumed determinism. “When the user clicks Save, the row is persisted” is one assertion that passes or fails. The PRD listed features, mapped each to user stories, attached acceptance criteria, shipped.
A 2026 AI PRD cannot assume determinism. “When the user clicks Triage, the agent labels the email correctly” is not one assertion — correctly is a distribution. Same prompt, same model, different outputs an hour apart. A vendor model update can silently shift behavior overnight.
Three facts force the change. AI features are probabilistic — quality is a rate, not a state. The model layer updates outside the team’s control — OpenAI shipped the GPT-5 family, Anthropic shipped Claude Opus 4 through 4.8, Google shipped Gemini 2.5 Pro (Artificial Analysis). The pilot-to-production gap is the dominant failure mode: McKinsey’s State of AI in early 2025 reports 78% organizational adoption but only a small fraction capturing real value; Gartner’s CIO surveys track roughly 85% of AI pilots as stalled before production.
The ten sections of a 2026 AI PRD
Order matters: a team that writes the eval set before the task taxonomy ends up with cases that test arbitrary behaviors rather than the tasks the product exists to perform.
1. The one-sentence idea
One sentence — not a paragraph — that compresses user, trigger, desired outcome, and existing alternative.
Solo independent consultants who currently triage email manually want their inbox prioritized within five minutes of opening their laptop.
The sentence sets scope for every section below. “An AI email assistant” is not a one-sentence idea — it is a category.
2. The AI capability dependency
The single AI capability the product depends on — not the feature list, the capability.
Capability: classify an inbound email into a 1-5 priority bucket given the email content plus the user’s last 30 days of reply patterns. Ceiling reference: feasibility probe on 40 representative inputs returned 33 “useful or better” on Claude Opus 4.8 — comfortably below ceiling. Sensitivity to model updates: medium.
A feature called “smart inbox” cannot be evaluated; a capability called “classify into priority bucket given context” can. If the capability is above the model’s ceiling, the project is not ready for build.
3. The user and task taxonomy
5 to 15 named tasks the AI is asked to perform. Each task is a unit of work the model is responsible for, and each gets its own eval cases.
| ID | Task name | Input | Output | User-visible? |
|---|---|---|---|---|
| T01 | Priority classification | Email body + 30-day context | Priority bucket 1-5 | Yes (label) |
| T02 | Rationale generation | Email body + assigned bucket | One-sentence rationale | Yes (hover) |
| T03 | Confidence calibration | Email body + bucket + context | Confidence 0.0-1.0 | No (internal) |
| T04 | Escalation decision | Confidence + user policy | Escalate yes/no | Yes (modal) |
| T05 | Action logging | All of the above | Structured log entry | No (audit only) |
The taxonomy makes the eval suite tractable: T01 gets 40 cases, T02 gets 30, T03 gets 20, T04 gets 30, T05 gets 10 — a 130-row diagnostic suite rather than a 300-row spreadsheet that mixes everything together. Scoping at the task level rather than the feature level is the operating discipline argued in the eval-first build playbook and in the case to stop scoping AI projects in features.
4. The eval set
The section that did not exist in the 2018 SaaS PRD, and the one that does most of the load-bearing work. Three parts: inputs, rubric, threshold.
Inputs: 30 to 50 cases per task, drawn from discovery interviews, feasibility-probe failures, and founder-supplied edge cases.
Rubric: a short description of what good means per task — typically a 1-to-5 scale with anchor descriptions.
Rubric — T01 priority classification 5 = bucket matches founder-graded ground truth exactly. 4 = off by one with acceptable rationale. 3 = off by one with weak rationale. 2 = off by two or more, or misleading rationale. 1 = confidently wrong; user would act incorrectly.
Threshold: the pass rate the team commits to. “75% of T01 cases score 4 or 5, with zero scores of 1 on the production-critical subset” is a threshold; “the agent works well” is not.
The eval set lives in version control — it is what the build ships against, what every model update is tested against, and what a vendor cannot quietly disagree with mid-build. Working size at PRD time: 50 to 150 cases across all tasks combined.
5. The failure-mode budget
AI features fail probabilistically. A PRD that does not name which failure modes are tolerable, at what rates, and with what policy for each, is committing to “perfect” as the implicit target — which guarantees the build will fail.
| Failure mode | Tolerable rate | Policy when exceeded |
|---|---|---|
| Confident misclassification (T01 score 1) | 0% on critical subset; 2% long-tail | Roll back to last passing model+prompt |
| Refusal when none warranted | 5% | Log + flag for prompt iteration |
| Hallucinated rationale (T02) | 1% | Block deploy; iterate prompt |
| Confidence calibration drift | within ±10 points | Re-calibrate or escalate threshold |
| Latency over 5s | 5% of requests | Investigate model + retry policy |
The budget forces the team to distinguish failure modes that matter from those that do not. A 5% refusal rate is annoying but recoverable; a 5% rate of confidently wrong high-priority labels is a product killer. The PRD makes that asymmetry explicit before code is written.
6. The no-AI fallback
When the model fails, errors, refuses, or is unavailable, what does the product do? A 2018 PRD implicitly answers “the feature does not work today”. A 2026 PRD names: what the user sees, what the system does in the background, the cost ceiling on retries, and which prior model+prompt combo the system pins to under rollback.
No-AI fallback: when classification fails, return null bucket plus a banner reading “Triage unavailable; review manually.” Do not silently default to bucket 3 — null is the correct signal. Re-queue for retry when the model is healthy. Cost ceiling on retries: $0.05 per email per 24 hours. Rollback: pin to the last 7-day-stable model+prompt combo signed off in the eval suite.
Short but indispensable — it is what prevents the product from becoming useless during a 2-hour vendor outage.
7. The integration surface
Every external system the product calls into — API surface, scopes, retry policy. Integrations are the second-biggest source of build-cost surprises after evals.
For each integration the PRD records system name, scope, rate-limit policy, auth model, and explicit in-scope-versus-out-of-scope marking. Vendor lock-in shows up here too: a PRD that names one model with no comparable fallback commits to a single-vendor risk surface — the model-agnostic discipline argued in the idea-to-product manifesto belongs in this section.
8. The observability minimum
A 2018 SaaS product could ship with application logs and an uptime monitor. A 2026 AI product cannot. The minimum is five items.
- Per-request structured trace: inputs, outputs, model name, prompt version, latency, token counts, cost — every call, not sampled.
- Per-task pass-rate dashboard: the eval suite re-run on every deploy plus nightly, with pass rates per task tracked over time.
- Per-user inference cost: running spend total per user, surfaced to the founder.
- Failure-mode counter: counts of each failure type from section 5, with budgeted tolerances drawn as lines.
- Prompt and model version manifest: which prompt and which model is in production, queryable without engineering support.
This distinguishes a product the founder can operate from one that runs as a black box until it fails.
9. Acceptance criteria
Where the 2018 PRD wrote per-feature checklists (“user can sort by date”), the 2026 PRD writes per-task eval thresholds.
| ID | Task | Eval threshold | Failure-mode constraint | Date |
|---|---|---|---|---|
| AC01 | T01 priority classification | 75% pass on 40-case suite | Zero score-1 on critical subset | Build week 4 |
| AC02 | T02 rationale generation | 80% pass on 30-case suite | Under 1% rationale hallucination | Build week 5 |
| AC03 | T03 confidence calibration | within ±10 points observed | n/a | Build week 6 |
| AC04 | T04 escalation decision | 90% pass on 30-case suite | Zero false-negative escalations | Build week 6 |
| AC05 | T05 action logging | 100% on 10-case suite | n/a | Build week 4 |
A build is “done” when every row meets its threshold and failure-mode constraint by its date — not when a demo runs on the founder’s data, but when the eval suite says it is done. Acceptance criteria stop being a feature checklist and become a quality contract.
10. What’s explicitly out of scope
A short, blunt list of capabilities the founder is excluding from the MVP. It protects both parties from the bait-and-switch dynamic that kills most AI projects.
Out of scope for MVP:
- Outlook, Fastmail, Front, and any non-Gmail mailbox.
- Reply drafting, summary generation, follow-up scheduling.
- Multi-language support beyond English.
- Mobile app — web only.
- Real-time triage under 60 seconds; MVP runs on a 5-minute cadence.
- Calendar integration of any kind.
- More than one user per account.
Each row is a capability a reasonable reader might assume is included, made explicit as not included. Over-list rather than under-list — the cost of an unnecessary row is zero; the cost of an unstated assumption is a 4-week scope-creep argument in week 8.
A one-page worked example
The ten sections land more honestly against a single scenario — an inbox-triage agent for solo independent consultants.
- One-sentence idea. Solo independent consultants who currently triage email manually want their inbox prioritized within five minutes of opening their laptop.
- AI capability. Classify an email into a 1-5 priority bucket given body plus 30-day reply context. Probe: 33 of 40 “useful or better” on Claude Opus 4.8.
- Task taxonomy. T01 priority classification, T02 rationale generation, T03 confidence calibration, T04 escalation decision, T05 action logging.
- Eval set. 130 cases — 40 / 30 / 20 / 30 / 10 across the five tasks. Thresholds: 75% on T01, 80% on T02, ±10 points on T03, 90% on T04, 100% on T05.
- Failure-mode budget. Zero confident misclassifications on the production-critical subset; 1% hallucinated rationale ceiling on T02.
- No-AI fallback. Null bucket plus banner; re-queue for retry; cost ceiling $0.05 per email per 24 hours; rollback to last 7-day-stable model+prompt.
- Integration surface. Gmail OAuth, one primary model provider plus one named fallback, one vector store, one cost endpoint. Outlook, Fastmail, Front, Slack: out.
- Observability minimum. Per-request structured trace; nightly eval dashboard; per-user inference cost; failure-mode counter; model and prompt version manifest.
- Acceptance criteria. Five rows tied to per-task eval thresholds and failure-mode constraints, each with a build-week date.
- Out of scope. Non-Gmail mailboxes; reply drafting; non-English; mobile; sub-minute triage; calendar; multi-user.
Sibling spokes cover what an AI MVP actually is and how to write a PRD an AI dev team can estimate.
Frequently Asked Questions
How is a 2026 AI PRD different from a 2018 SaaS PRD?
The dominant artifact has changed. A SaaS PRD’s load-bearing section was the user-story tree; a 2026 AI PRD’s is the eval set, with per-task thresholds and a failure-mode budget. A PRD without an eval set, a failure-mode budget, and a no-AI fallback is a SaaS PRD with AI rebranded onto it.
How long should an AI PRD be?
Eight to twenty pages, with the eval suite, workflow diagram, and unit-economics worksheet attached separately. A 60-page narrative PRD with no eval contract is a worse artifact than a 10-page PRD with one.
Who writes the AI PRD?
The founder owns it; the partner contributes. Eval cases come from the founder — the founder owns the domain knowledge. Workflow map, integration surface, and observability minimum are partner-led drafts the founder signs.
Can a non-engineer founder write this PRD alone?
Most sections, yes. Sections 1, 3, 4, 5, and 10 are founder-led; sections 2, 7, and 8 need partner support — eight to twelve hours of senior-engineer pairing is enough.
How big should the eval suite be at PRD time?
50 to 150 cases across all tasks combined. Below 50, the suite cannot distinguish a regression from a flake; above 150 before code is written, the team is over-investing.
What is the most common AI PRD failure mode?
Skipping the failure-mode budget — vendors and founders write the eval threshold but skip the explicit list of acceptable failure rates per failure type, and the project ships at a quality bar nobody signed off on.
Should the PRD specify which model to use?
It should name a primary and a fallback, both with eval thresholds met. A PRD that names a single model with no fallback creates vendor-lock-in risk the founder did not consciously sign up for.
How does the PRD relate to the SOW?
The SOW points at the PRD; the PRD defines what “delivered” means. A SOW with no attached PRD and no eval thresholds is one the vendor interprets loosely and the founder cannot enforce.
Closing
A 2026 AI PRD is not a longer 2018 PRD. It is a different artifact organized around a different load-bearing section: the eval set. The validation work that produces each section lives in the idea validation playbook; the build discipline that ships against the PRD lives in the eval-first build playbook; the argument for why the eval set is load-bearing lives in the case to stop scoping AI projects in features.
Arthur Wandzel
