The 2018 PRD template is structurally wrong for AI-native products. Wrong at the spine. The user-story tree, the boolean acceptance criteria, the exhaustive edge-case list, the hand-off-at-spec model — all four load-bearing properties of the document we wrote for a decade fail on the first AI feature they touch. Adding a “model choice” section does not fix this. What fixes it is rebuilding the document around the three properties that distinguish AI-native from SaaS: probabilistic outputs, model-as-dependency, and eval-as-spec.
It builds on the idea validation playbook within the idea-to-product manifesto. Companion pieces describe the 10-section anatomy and argue why the eval set is the spec. This is the opinion piece — what gets cut, what replaces it, and why the one-page rule is the forcing function.
Table of Contents
- The four 2018 PRD properties that no longer fit
- The four properties that replace them
- The non-obvious deletion: feature lists shrink
- The non-obvious addition: the no-AI fallback is bigger than any feature
- What an AI-native PRD looks like at a glance
- The one-page rule
- Frequently Asked Questions
- Closing
The four 2018 PRD properties that no longer fit
The PRD that dominated SaaS writing from 2014 through 2020 — Cagan-style, Atlassian-template, Lenny-newsletter — converged on four load-bearing properties. Every one was correct for deterministic software. Every one is wrong for AI-native software.
Property 1 — Acceptance criteria as boolean assertions
The 2018 PRD treated each acceptance criterion as a Gherkin-style boolean: given the user clicks Save, when the row commits, then the record exists. The implementation satisfies the criterion or does not.
AI outputs have a third state. The same model produces an answer correct on Tuesday, wrong on Thursday, partially correct on Sunday. Quality is a distribution, not a state. Anthropic’s Building Effective Agents names this as a first-order property — success criteria must be measurable, not asserted. A boolean acceptance criterion in an AI PRD is a category error.
Property 2 — Exhaustive edge-case enumeration
The 2018 PRD listed negative paths. If the user enters an empty string, show error E04. If they enter more than 256 characters, truncate. The completeness of the list was treated as a quality signal.
AI systems do not have an enumerable edge-case set. The input space is natural language; the model invents new failure modes every time the prompt is rewritten. Listing edge cases is now a confession that the spec author thinks the input space is small enough to enumerate. What replaces enumeration is a failure-mode budget — the rate of each kind of error that is acceptable.
Property 3 — Determinism as background assumption
The 2018 PRD assumed determinism so deeply it never named the assumption. Same input, same output. Tests are repeatable.
The same prompt to the same model on the same day produces different outputs. Temperature is a sampling parameter, not a bug. The model layer updates outside the team’s control — the Artificial Analysis LLM leaderboard currently tracks Gemini 2.5 Pro, GPT-5, Claude Opus 4.8, and Llama 3.3, none of which existed when many in-flight PRDs were authored. A spec that does not encode reproducibility primitives is silently dependent on every vendor release calendar.
Property 4 — Hand-off-at-spec model
The 2018 PRD was finished when engineering signed the design review. After sign-off, the PRD was a reference, not a contract.
In an AI-native build, sign-off is meaningless until the eval set has been baseline-run against a candidate model. A founder who signs without a baseline pass-rate has signed a wish, not a contract. The hand-off moves from “the spec reads well” to “the eval passes a non-trivial threshold on a real model.” That shift breaks the PM-then-engineering relay model the 2018 PRD was built around.
The four properties that replace them
For each property that no longer fits, an AI-native replacement carries the structural load. These are not additions — they are spine swaps.
Replacement 1 — Eval set as spec
The user-story tree demotes from spine to decoration. In its place sits a named set of 10–30 hard inputs — the cases the founder already worries about. Ten is the floor below which a 70%–90% pass rate is statistically indistinguishable from noise; thirty is the ceiling before code is written. The eval set is the artifact every other section is graded against. A feature without an eval case is a feature without a definition of done.
Replacement 2 — Failure-mode budget instead of exhaustive edge cases
The edge-case enumeration disappears. In its place sits a budget — for each task, what fraction of failures of which type are acceptable.
A priority-classification task might tolerate 10% under-priority errors (P3 labeled P4) but 0% over-priority errors (P4 labeled P1, spamming the inbox). A reply-drafting task might tolerate length violations but not factual contradictions. The budget makes asymmetric error costs explicit and forces an early conversation about which errors the product can tolerate.
Replacement 3 — Probabilistic acceptance via pass-rate threshold
The boolean acceptance criterion is replaced by a single number per task. The system passes 85% of the eval set with the rubric returning correct. That is the contract.
The threshold is falsifiable and survives a model swap, a prompt rewrite, or a vendor change. Setting it honestly requires a feasibility probe — running the eval against a candidate model with a baseline prompt before sign-off. If the baseline returns 30%, the threshold is aspirational and the spec returns to the drawing board. McKinsey’s State of AI 2025 reports broad adoption with a small fraction capturing material value; the dominant cause is shipping at a quality bar nobody signed off on. A pass-rate threshold is the cheapest fix.
Replacement 4 — Hand-off-at-eval-set model
Sign-off moves. The PRD is no longer done when engineering signs the design review; it is done when the eval set baselines above a defensible threshold on a real model run.
This swaps the relay model for a synchronous one. PM, engineer, and founder all stand at the same eval gate. The PRD is signed and baseline-tested in the same week. This is what the eval-first PRD operationalizes — and the structural point is that this is a different document architecture, not a process tweak.
The non-obvious deletion: feature lists shrink
The interesting move is not what gets added — it is what shrinks.
Every feature in an AI-native PRD must carry its own eval set, rubric, threshold, and failure budget. A founder who scoped 12 features in a 2018-shape PRD scopes three or four in a 2026-shape one — not because the others were unnecessary, but because the founder cannot defensibly write the eval cases for eight in a single afternoon. The eval-authoring cost forces a culling pass the old template never imposed.
The 2018 PRD let feature lists grow because each feature was cheap on paper — a user story and a boolean criterion took ten minutes. An eval-first feature takes an hour. A PRD that imposes that cost surfaces feature bloat before code is written, which is the cheapest possible time.
The mechanical effect: the average AI-native PRD has three to five core features, not twelve. One or two have AI in the load-bearing path; the rest are integration plumbing. For the procurement-flavored version, see stop paying AI agencies for documentation, pay them for evals.
The non-obvious addition: the no-AI fallback is bigger than any feature
Most discussion of AI-native PRDs adds an eval section, a model section, a failure-mode section. Correct but undersized. The biggest new section is one most templates omit: the no-AI fallback.
When the model fails — latency spikes, an outage code from the API, an eval threshold missed in production for a week — the product still has to function. The fallback path is the deterministic behavior the user sees when AI is unavailable. For a priority-classification feature: route every email to the inbox unchanged. For a reply-drafting feature: open an empty draft window. For a summarization feature: show the original text with a “summary unavailable” notice.
In production, the fallback serves real traffic. A reasonable assumption for a v1 product is that 5–15% of requests will hit the fallback in the first quarter — failed retries, ambiguous inputs, model outages, eval threshold breaches. Treating that fraction as a margin rather than a feature causes the worst category of production failure: the product is broken for one in ten users and nobody noticed because the eval was green.
The no-AI fallback deserves more spec real estate than any single AI feature. A PRD that treats it as a one-paragraph appendix has the dependency graph backwards.
What an AI-native PRD looks like at a glance
Once the four replacements and two structural shifts are in place, the table-of-contents-level shape of the document changes. A defensible 2026 AI PRD reads like this:
| Section | Purpose | Length |
|---|---|---|
| 1. One-sentence idea | The system in one falsifiable sentence | 1 line |
| 2. AI capability dependency | Which model capability the product depends on | 3–4 lines |
| 3. Task taxonomy | Atomic tasks (one capability per task) | 1 line per task |
| 4. Eval set | 10–30 hard inputs per task, named | 1 page per task |
| 5. Rubric per task | Pass / fail / boundary, three lines | 3 lines per task |
| 6. Pass-rate threshold | Single number per task | 1 line per task |
| 7. Failure-mode budget | Acceptable rate per error type | 1 table per task |
| 8. No-AI fallback | Deterministic behavior when AI unavailable | 1 paragraph per feature |
| 9. Observability minimum | What must be logged in production | 5–10 events |
| 10. Out of scope | What this PRD explicitly is not | 5–8 lines |
The full anatomy is documented in the AI PRD explained. The user-story tree, the screen-flow appendix, and the exhaustive edge-case list all disappear. What is left is a small, dense, falsifiable contract — short because evals are denser per byte than user stories.
The one-page rule
The AI-native PRD’s single design principle is: the document fits on one page per AI-bearing feature. Not one page total. One page per feature.
A reply-drafting feature gets one page — task, eval set summary, rubric, threshold, failure budget, fallback. A priority-classification feature gets one page. A four-feature product runs to four pages of AI spec plus a one-page summary, a one-page integration map, and a one-page out-of-scope statement. Six to eight pages, not forty.
If you cannot write the eval set, rubric, threshold, failure budget, and fallback for a feature on one page, one of three things is true: the feature is actually two features; the feature is not yet ready for build; or it does not need AI in the load-bearing path. All three are useful diagnoses, surfaced before code is written.
This is why the deletion list matters. Cutting the user-story tree, the exhaustive edge-case enumeration, and the screen-flow appendix is not minimalism for its own sake — without the deletions, the additions would push the document to fifty pages and nobody would write it.
Frequently Asked Questions
Does this mean the user-story tree disappears entirely?
No. It demotes from spine to decoration. The user-story tree can still frame a feature in one paragraph — who uses this and why — but it does not carry the load. The eval set does.
Is the one-page rule realistic for complex agent systems?
The rule is per AI-bearing feature, not per product. A complex agent with seven sub-tasks runs to seven pages of AI spec. If a sub-task cannot fit on one page, it is two sub-tasks pretending to be one.
How is this different from just adding evals to a standard PRD?
The difference is structural, not additive. A standard PRD with an eval section still treats user stories as the spine. The AI-native PRD treats the eval set as the spine and user stories as supporting decoration. Different gravity, even if the same words appear in both.
Who writes the eval cases — the PM or the founder?
The founder, with PM assistance. Eval cases require domain knowledge only the founder reliably has. A PM writing eval cases without founder input produces cases that look reasonable but miss the hardest inputs.
What if the founder does not yet know what hard inputs look like?
That is the kill signal. If the founder cannot write ten hard inputs on day one, the founder does not yet understand the task well enough to spec it. The fix is a week of observation in the workflow, then return to eval authorship.
Does this approach work for retrieval / RAG systems?
Yes. The argument generalizes to any probabilistic system. RAG retrieval is graded with a rubric (was the right chunk retrieved); RAG generation is graded with a rubric (was the answer grounded). Each gets its own threshold.
How does this PRD format interact with a vendor SOW?
The SOW points at the PRD. The PRD defines what delivered means via the eval threshold. Milestone billing should tie payment to eval-threshold passes, not to documents shipped.
What is the most common authoring mistake?
Writing the rubric after the team has been prompt-tuning for a week. By that point the rubric encodes the team’s compromises. It must be authored before any prompt has been drafted.
What about non-LLM AI features — classifiers, recommenders, scorers?
The PRD shape is the same. Classifiers get a confusion matrix and a per-class error budget. Recommenders get a precision-at-K rubric and a coverage threshold. Model-architecture-agnostic.
Should the PRD specify a model, or stay model-agnostic?
Stay model-agnostic in the contract sections (eval set, rubric, threshold). Name a candidate model only in the feasibility-probe section. Locking the spec to one vendor’s model couples it to a release calendar — the dependency the AI-native shape is trying to break.
Closing
The 2018 PRD was correct for the software it was written about. Deterministic systems with enumerable inputs deserved deterministic specs. The document fit the work.
AI-native products do not. The four properties that made the old PRD load-bearing — boolean acceptance, exhaustive edge cases, determinism, hand-off-at-spec — all fail on the first AI feature they touch. What replaces them is a smaller, denser document organized around an eval set that survives model swaps, prompt rewrites, and vendor turnover.
The signature of this rewrite is the one-page rule. If you cannot write your PRD on one page per AI-bearing feature, you do not have a PRD — you have a wish list. The SFAI Labs AI MVP scoping worksheet walks the eval set, rubric, threshold, and failure budget for one feature in about two hours — the cheapest feasibility probe before the document is signed.
Arthur Wandzel
