The PRD isn't dead — but writing specs for non-deterministic AI is different

Every few years someone declares the PRD dead. With AI, the obituary almost writes itself: how do you write a requirements document for a system that gives a different answer to the same question twice? If you can't pin down the exact output, what is there to specify?

Plenty, it turns out. The PRD doesn't vanish for AI products. It changes shape. Specs for traditional software describe deterministic behavior — given this input, produce exactly this output. Specs for AI describe acceptable distributions of behavior — across many inputs, here's how often and how well the system should be right, and here's what happens when it isn't.

“Plans are worthless, but planning is everything.”

What stops working

The classic acceptance criterion — "when the user clicks X, the system shows Y" — breaks immediately. There's no single Y. Pixel-exact expected outputs, exhaustive if-this-then-that branches, sign-off based on "it worked when I tried it": all of these assume a determinism the system doesn't have. Cling to them and you'll either never ship (nothing passes a deterministic test) or ship something nobody actually validated.

What replaces it

Four sections do the work a list of behaviors used to do.

1. The evaluation set is the spec

For an AI feature, the single most important artifact isn't a paragraph of prose — it's a curated set of representative inputs with notes on what a good response looks like for each. This dataset is your real source of truth. It's how you'll know if the feature works, how you'll catch regressions when the model changes underneath you, and how you'll settle arguments about quality with evidence instead of opinion. If you write nothing else, write this.

“It is a capital mistake to theorize before one has data.”

2. Quality bars, stated as metrics

Instead of "the summary should be accurate," specify the bar: on the evaluation set, factual-grounding above some threshold, an acceptable rate of a defined failure type, a maximum tolerable latency. Numbers turn "it feels off" into a conversation you can actually resolve — and they give engineering a target instead of a vibe.

3. Failure as a first-class design surface

Deterministic specs treat errors as edge cases in an appendix. AI specs put failure in the center, because failure is not rare — it's a guaranteed fraction of normal operation. So the PRD has to answer: how does the system behave when it's unsure? When does it abstain rather than guess? What does the user see when it's wrong, and how do they recover or correct it? Designing the unhappy path is most of the work, and it's where product judgment shows.

4. Guardrails and the non-negotiables

Probabilistic doesn't mean lawless. Some things must never happen regardless of what the model wants to do — leaking PII, giving regulated advice it isn't allowed to give, taking an irreversible action without confirmation. These belong in the spec as hard constraints enforced in the system around the model, not as hopes pinned on the prompt. The distribution can wander; the guardrails can't.

The PM's job didn't shrink — it moved

If anything, writing specs for AI demands more product judgment, not less. You're no longer transcribing a known design into requirements; you're deciding what 'good enough' means for a system that will surprise you, curating the data that defines it, and designing gracefully for the cases where it falls short. The document looks different, and that's the point. Write the eval set, state the bars, design the failures, fix the guardrails — and the PRD is very much alive.