The eval is the spec
For probabilistic systems, requirements written in prose are opinions. Requirements written as evals are testable. Write the eval first.
Product managers know how to write requirements for deterministic software. The user clicks this, the system does that, and "done" is a checkbox because the behavior either happens or it doesn't. Then we started writing requirements for systems that answer differently every time, and mostly we kept using the same document. The PRD says the assistant should "respond accurately and helpfully in the user's context." Everyone nods. Nobody can say whether the finished system meets the requirement, because the requirement was never something you could check.
The fix I've settled on is blunt: for an AI feature, the evaluation is the specification. Not a section at the end of the PRD — the load-bearing middle of it. Before anyone builds, the team writes the eval: the set of real input cases the system must handle, the definition of an acceptable output for each, and the score that separates shippable from not. Those three things are the requirements. Everything else in the document is context.
What changes when the eval comes first
Disagreements move to where they're cheap. Ask five stakeholders whether a drafted answer is "good" and you'll get five yeses in the abstract and five different objections at launch review. Ask them to grade twenty concrete outputs against written criteria and the disagreement surfaces immediately — turns out legal means "never speculate," support means "always offer the workaround," and sales means "shorter." That argument was always going to happen. Having it over a criteria document in week one costs a meeting. Having it over a built system in week twelve costs the quarter.
Scope gets honest. Writing eval cases forces you to enumerate what the system will actually face — the ambiguous request, the missing context, the question that's out of bounds. Every case you write is a decision about what's in scope. Vague PRDs hide scope creep inside adjectives; an eval set can't. If the case isn't in the set, it isn't in scope, and everyone can see that.
Engineers get a target instead of a vibe. "Make it more helpful" is not an instruction. "Case 14 fails because the model speculates when the document doesn't contain the answer; the criterion says decline and cite" — that's an instruction. Teams iterate dramatically faster when the definition of better is written down and runnable, because every prompt change, model swap, and retrieval tweak gets scored against the same bar instead of re-argued.
"Done" becomes checkable again. The launch decision stops being a demo and a feeling. The system clears the thresholds on the failure modes that matter, or it doesn't. This is the property deterministic software always had and probabilistic software lost; the eval gives it back.
Ask a team to show you the eval for the feature they're building. If they can't — if the criteria live in someone's head, or the test set is ten friendly examples — the requirement is not yet understood, by anyone. A feature that's hard to evaluate is almost always a feature that's vaguely conceived. The difficulty isn't a tooling problem; it's the spec telling you it isn't finished.
The practice, concretely
In the PRD, where acceptance criteria used to go, I put three things: the golden cases (real inputs, pulled from the actual workflow, ugly ones included), the per-case criteria written as pass/fail statements a non-author could apply, and the thresholds with their justification — stricter where an error acts on its own, looser where a human reviews every output. Stakeholders sign off on that, before the build, the same way they used to sign off on mockups. Engineering wires the cases into a harness that runs on every change.
The pattern will be familiar to anyone who has worked near test-driven development: write the test, then the code, and the test defines correct. This is the same discipline aimed at a harder target — call it evaluation-driven development. The PM's contribution isn't writing the harness; it's owning what "good" means with enough precision that a harness can check it. That has always been the actual job. Probabilistic systems just stopped letting us fake it with adjectives.
If you take one thing: a requirement you can't evaluate is an opinion. Write the eval first, and the spec argument happens while it's still cheap.