The PRD that becomes a product, not a document that becomes a drawer
A loose PRD becomes interpretation. A PRD with a testable acceptance criterion becomes a product, because an AI agent can execute against it and you can check the result. The difference lives in the criterion, and the criterion is still yours.
You write a three-page PRD describing the new feature, hand it to the team, and move on to the next thing. Two weeks later the dev delivers something that technically fulfills what's written, and doesn't solve the problem you had in mind. The PRD wasn't wrong in its wording. It was wrong in its criterion: it never stated, in a way you could actually test, what "done" means.
The recurring report you redo from scratch every week doesn't need to be redone from scratch. This lesson shows the ladder that turns that repeatable task into a system that nearly triggers itself.
For a due diligence, AI calculated a target company's consolidated labor liability and wrote a confident-sounding paragraph about the risk. It almost went into the opinion like that, without checking.
You ask AI for a campaign brief and it hands back a pretty document, full of vague goals like "increase engagement". Nobody knows, at the end of the campaign, whether it worked or not, because nothing in it was measurable.
You write an onboarding program description with generic goals like "integrate the new hire well". Three months later nobody knows how to measure whether it worked, because "integrate well" never became a checkable criterion.
You write a three-page PRD describing the new feature, hand it to the team, and move on to the next thing. Two weeks later the dev, or the AI agent you connected to the repository, delivers something that technically fulfills what's written, and doesn't solve the problem you had in mind. The PRD wasn't wrong in its wording. It was wrong in its criterion: it never stated, in a way you could really test, what "done" means. A pretty PRD with no verifiable acceptance criterion isn't a spec, it's prose. And prose doesn't become a product.
You write the playbook for a new sales approach with vague instructions like "personalize the pitch more". The team interprets it each their own way, and there's no way to tell if the playbook worked, because there was no criterion at all to measure it.
You write the distribution center's new procedure with a generic goal of "reduce picking time". Without a number and a test criterion, every shift interprets it differently, and nobody knows if the procedure actually solved the bottleneck.
You write the new data-handling policy with generic language about "security best practices". At audit time, nobody can prove the policy was followed, because a verifiable criterion never existed.
You write the technical issue saying "improve search performance". The dev delivers a real optimization, except it's not the one that solved the problem the user felt, because the issue never defined what "improve" meant, with a number.
You write the redesign brief with the goal of "make the flow more intuitive". Without a test criterion, the design team interprets it their own way and you only find out, in the final usability test, that it wasn't what was actually tripping up the user.
You write the board's strategic recommendation with a punchy line and no measurable success criterion. Six months later nobody can say whether the bet paid off, because it was never clear what "paid off" meant.
Let me tell you something about PRDs. Everyone has written a PRD that looked complete: context, goal, scope, a list of "requirements". And it still turned into rework, because two weeks later nobody agreed on whether what was delivered was right or not. Think about it: the problem is almost never the writing. It's that the document never stated, in a way you could test, what "done" means.
The core idea of this lesson. A PRD becomes a product when it carries a testable acceptance criterion: a sentence that anyone, or any AI agent, can verify as true or false after implementation. AI drafts the PRD's structure and suggests candidate criteria fast. What's still yours, and what decides whether the PRD works, is making sure the criterion captures the real intent, not just an easy-to-test version that doesn't solve the actual problem.
01Why the loose PRD ends up in a drawer or turns into rework
A PRD with no verifiable criterion has a treacherous trait: it LOOKS complete. It has context, it has a goal, it has a list of "what to do". What's missing is the ruler that says when to stop tinkering and call it done. Without that ruler, everyone who reads the document, a dev, a designer, an AI agent, fills the gap with their own interpretation.
The classic result: the feature "technically" fulfills the PRD and doesn't solve the problem. Nobody lied, nobody was lazy. The document simply never defined what "right" meant in a way you could check.
02The anatomy of the executable PRD: problem, criterion, out of scope
A PRD that becomes a product has three parts that do the heavy lifting:
- The problem, with supporting evidence. Not "the user wants more speed", but "twenty-three tickets and three enterprise accounts cite checkout slowness", pulled straight from the previous lesson's feedback choreography.
- The acceptance criterion, testable. A sentence in the format "given this, when this happens, then this must be true". Not "checkout should get faster", but "the time between clicking finalize and seeing the confirmation must drop below two seconds in ninety percent of purchases".
- What's out of scope, explicit. What you decided NOT to do now, written with the same clarity as what you will do. This cuts the biggest source of rework: people adding things nobody asked for.
03AI drafts fast, the right criterion is still yours
Here AI helps a lot, and it's worth using without guilt. You hand over the insight from the feedback choreography (the problem's evidence), and ask for the whole PRD draft: context, goal, a first list of candidate acceptance criteria. It builds this in minutes, in the right format, well written.
What it doesn't do on its own is guarantee that the criterion truly captures the intent. It's easy for AI to suggest a criterion that's easy to test and easy to build and that isn't what solves the user's problem. Classic example: the criterion "the export button must appear on screen" is testable and solves nothing if the real problem was "the user doesn't know the export exists". You read each candidate criterion and ask: if this is true, is the problem from step one actually solved? If the answer is no, the criterion is wrong, even if it's perfectly testable.
Learn more: a testable criterion isn't synonymous with a correct criterion
There's a subtle trap here. "Testable" is a quality of form: you can verify whether it's true or false. "Correct" is a quality of content: the criterion actually captures what solves the user's problem. AI is great at guaranteeing form, because form is structure, and it writes structure well. Guaranteeing content, that this specific criterion is the right thing to measure, requires you to have read the source insight and to really know what the user was trying to do. A PRD full of testable and wrong criteria is worse than a vague PRD, because it gives off a false sense of rigor.
04From criterion to agent: read, do, show for you to check
A well-written acceptance criterion is what lets an AI agent execute the implementation safely, the way you saw in lesson 1.1: it reads the PRD and the criterion, makes the change in your code or your system, and shows you so you can check whether the criterion is now true. Without a clear criterion, the agent has no way of knowing when to stop, and you have no way of approving with confidence, only with the feeling of "looks like it turned out fine".
A well-written criterion becomes, almost for free, the test script that confirms the delivery. It's the same principle as any choreography in this course: the clearer the criterion going in, the easier and safer the check coming out.
05What never gets automated: the intent behind the criterion
This lesson's final rule, and it's short. AI can write the entire PRD, suggest all the criteria, even simulate whether the implementation seems to meet each one. What it can't do on its own is decide whether that set of criteria, taken as a whole, solves the problem the user actually has. That reading of intent is yours, it comes from the evidence you gathered, and it's the reason you're still necessary now that writing got cheap.
Do it now
Take a real feature or fix you need to spec out, your real task or another one. Write the PRD in three parts:
- Problem with evidence. A sentence with the real data behind it (ticket count, user quote, a metric that dropped).
- Testable acceptance criterion. Write it in the format "given this, when this happens, then this must be true". If you can't write it in a testable format, the criterion is still vague.
- Out of scope. List two or three things someone might assume are included, and that you're leaving out this round, in writing.
Now reread the acceptance criterion and ask: if this is true, is the problem from step one really solved? If the answer is no, rewrite the criterion before sending it to the team or the agent.
Practice
1. Why can a PRD look complete and still turn into rework?
2. For the problem 'the user doesn't know the export exists', AI suggested the criterion 'the export button must appear on screen'. That criterion is testable. Is it correct?
For the board
On what the PRD is missingthe problem is almost never the writing. It is never having said, in a testable way, what done means.
On the gapwith no verifiable criterion, every person and every agent fills it with their own interpretation.
On the limitthe AI drafts fast. Checking whether the criterion captures the real intent stays human.
Thanks for the feedback. It helps sharpen the next lesson.