Writing PRDs That ML Engineers Actually Want to Build From

Part 12 of the Applied AI Product Management series. Posts 10 and 11 covered how to scope, ship, and operate AI features. This post covers the document that ties all of that together: the AI PRD, and specifically what makes it different from every other PRD you've written.

A team wrote a thorough PRD for a contract analysis feature. Problem statement was clear. User stories were specific. Success metrics included adoption rate and task completion time. Engineering got to work. Four months later, the feature shipped. The model was technically functional. Legal teams tried it, used it for a week, and stopped.

The problem wasn't the model. It was that nobody had written down what "good" looked like for a contract analysis output. The PRD specified what the feature should do. It said nothing about the quality bar the output needed to reach for a lawyer to trust it. The model was optimizing toward something, but that something wasn't defined well enough to produce a feature users would depend on.

This is the most common AI PRD failure. Not missing sections. Missing calibration. A traditional PRD specifies what to build. An AI PRD has to do something harder: specify what good looks like, what bad looks like, and how you'll know the difference before the feature ships.

Why AI PRDs are structurally different

A traditional software PRD specifies behavior deterministically. The button is blue. The form validates before submission. The email sends when the user clicks send. These are binary requirements. Either the behavior exists or it doesn't. Acceptance testing is straightforward.

An AI PRD specifies behavior probabilistically. The model produces helpful responses most of the time, under most conditions, for most users. "Most of the time" and "most users" are doing a lot of work in that sentence, and if you don't quantify them, you haven't actually written a requirement. You've written an aspiration.

The structural differences that follow from this:

A traditional PRD's quality section covers performance, scalability, and reliability. An AI PRD needs all of those plus model quality, which is a different kind of requirement entirely. It involves thresholds (what accuracy is acceptable), tradeoffs (precision vs. recall, which Post 8 covered in depth), segment-specific performance (the model works for power users; does it also work for beginners?), and failure behavior (when the model doesn't know, what does it do?).

A traditional PRD's launch section covers release dates and rollout scope. An AI PRD needs to embed the validation stages from Post 11 directly into the spec: shadow mode criteria, canary release thresholds, and the rollback triggers that would prevent full release. These aren't post-launch operational concerns. They're pre-launch commitments that should be reviewable before engineering starts.

A traditional PRD's success metrics section covers usage and business outcomes. An AI PRD needs model metrics connected explicitly to those outcomes, with an honest account of where the connection might break down. "BLEU score improves 10%" is not a success metric for a user-facing product. "BLEU score improves 10%, which we expect to correlate with a 15% improvement in user satisfaction scores based on our validation data" is the beginning of one.

Teams that complete all required sections of a PRD ship 34% fewer post-launch bugs than teams that write informal specs. For AI products, the section most commonly skipped is the quality requirements section. It's also the section most responsible for post-launch remediation.

The sections that matter most

Rather than walking through every section of an AI PRD, which would be a template document rather than a blog post, what follows focuses on the sections that are either unique to AI or require substantially different thinking than their traditional equivalents.

Problem statement with AI specificity

Most problem statements in AI PRDs stop at the user problem. They should go one step further and answer why AI is the right solution for that problem, not just a possible one.

The addition that matters: what evidence suggests this problem has a learnable pattern? If the task requires consistent judgment on similar inputs at volume, name that. If there's historical data that demonstrates humans make consistent decisions on this task that could train a model, reference it. If a foundation model already handles the core capability zero-shot and the differentiation is context or integration, say so.

This addition serves two purposes. It forces the PM to have done the feasibility thinking from Post 10 before the PRD is written. And it gives engineering and leadership a shared rationale for the AI approach that isn't "AI is the obvious solution."

Quality requirements: the section most PRDs get wrong

This is where AI PRDs diverge most sharply from traditional ones, and where the contract analysis failure from the opening story lives.

Quality requirements for an AI feature need four components: the performance threshold, the evaluation methodology, the segment breakdown, and the failure behavior specification.

The performance threshold is the minimum acceptable quality level before the feature can ship. Not the target. The minimum. "The model must achieve 90% precision on the core classification task as measured on a held-out test set representative of our production traffic distribution." That sentence has a metric, a threshold, and a dataset specification. All three are required. "The model must be accurate" has none of them.

The evaluation methodology answers how you'll measure the threshold. LLM-as-a-judge, human evaluation, automated metrics, or some combination. If you're using automated metrics, which ones and why are they appropriate for this task, given the Post 5 context on why BLEU misleads. If you're using human evaluation, who the evaluators are and what rubric they'll apply. This section is often written as "we'll evaluate quality before launch," which is not a methodology. It's an intention.

The segment breakdown is the requirement that most teams discover they needed only after launch. A model that achieves 90% overall but 70% for non-English inputs, or 65% for new users with limited history, has a user trust problem that the aggregate number hides. The PRD should specify which segments matter for this feature and what the minimum acceptable performance is for each. This forces the disaggregated analysis from Post 5 to happen before launch rather than as a post-mortem.

The failure behavior specification is the most overlooked part. When the model is uncertain, or when it encounters an input outside the distribution it was trained on, what does the product do? Does it surface the uncertainty to the user? Does it fall back to a non-AI path? Does it refuse to produce output and route to a human? Each of these is a product decision that belongs in the PRD, not in an engineering design doc that the PM may never read.

Writing testable acceptance criteria for probabilistic systems

This is the hardest section of an AI PRD to write well, and the one most responsible for the 68% of engineering re-requests traced back to vague acceptance criteria.

Binary acceptance criteria don't apply to AI features. "The model correctly classifies the input" is not testable in any meaningful sense because "correctly" requires a reference standard that hasn't been defined.

Testable acceptance criteria for AI features have three elements: the condition being tested, the measurement approach, and the acceptable threshold.

For a document summarization feature: "When presented with a 2,000-word legal brief, the model produces a summary that captures all primary arguments as identified by a legal domain expert evaluator, with a minimum coverage score of 0.85 as measured by our rubric-based evaluation protocol."

For a code completion feature: "Suggestions accepted by developers at a rate above 40% on the internal dogfooding cohort before general release, measured over a minimum of 500 suggestion opportunities."

For a fraud detection feature: "False positive rate remains below 0.8% on transactions in the $50 to $500 range as measured on the validation set, with a separate threshold of 0.3% for transactions above $500."

Each of these specifies the condition, the measurement, and the threshold. Each is testable. None requires subjective interpretation to evaluate. That's the bar for an AI acceptance criterion.

Data requirements

Post 9 covered data strategy in depth. In the PRD context, the data section needs to answer four questions that translate the data strategy into a project-specific commitment.

What training data is required, and does it exist? If it doesn't exist, what's the path to creating it and how does that timeline integrate with the engineering schedule? A PRD that specifies a model requiring 10,000 labeled examples but has no data collection plan is a PRD built on an assumption rather than a commitment.

What are the privacy constraints on that data? Which user data can be used for training, under what consent terms, and how is it anonymized before it reaches the training pipeline? These constraints sometimes change the feasibility of the approach entirely, and discovering them after engineering has started is expensive.

What's the feedback loop that keeps the model improving after launch? The training data requirement doesn't end at launch. The PRD should specify how production data flows back into the training pipeline, who owns that process, and what volume of new labeled data triggers a retraining run.

What's the minimum data requirement for launch, distinct from the ideal? The ideal dataset and the launch dataset are different things. Knowing the minimum that produces acceptable quality lets engineering plan around a realistic data acquisition timeline rather than an ideal one.

Launch plan with validation gates

Post 11 covered shadow mode, canary releases, and gradual rollout as deployment strategies. In the PRD, these should appear not as engineering implementation details but as product commitments with explicit success criteria for each gate.

The PRD launch plan should answer: what does the model need to demonstrate in shadow mode before it's eligible for canary release? What metrics need to hold for how long in canary before full rollout proceeds? What triggers automatic rollback at any stage?

Writing these gates into the PRD before engineering starts does two things. It aligns the team on what success means at each stage, rather than making that call under the pressure of a delayed launch. And it gives leadership a clear picture of what the release process looks like, which tends to produce better conversations about timeline than "we'll release when it's ready."

Risk and mitigation

Every PRD has a risk section. Most AI PRD risk sections contain the same generic entries: timeline risk, resource risk, dependency risk. These belong in any project plan. The risks specific to AI features are different, and not writing them down means the mitigation planning doesn't happen until the risk materializes.

Hallucination risk. For generative features, what's the expected hallucination rate, what's the acceptable rate, and what product safeguards reduce user exposure to incorrect outputs? For features where users will act on model outputs, this isn't a technical footnote. It's a core product risk.

Cost scaling risk. What's the projected model cost at 10x current query volume? Has that number been approved as acceptable? The features that get launched without this analysis are the ones that produce the panicked infrastructure conversations six months later.

Drift risk. How will you know if the model's quality degrades after launch? Which metrics serve as early warning signals, and what's the response plan when they fire? Post 11 covered monitoring in depth. The PRD should reference the monitoring plan that will govern the feature post-launch rather than leaving it for the operations team to figure out independently.

Feedback loop failure risk. If the positive feedback loop this feature depends on doesn't develop as expected, what's the contingency? A recommendation feature that assumes users will engage enough to generate training signal needs a plan for the scenario where early engagement is too low to feed the loop.

Bias risk. Which user segments might experience meaningfully different quality? What testing will surface that before launch? What's the acceptable performance gap across segments, and what happens if a segment falls below that threshold?

None of these risks is hypothetical for AI products. Every one of them has materialized in production systems. Writing them into the PRD before engineering starts turns them from surprises into managed scenarios.

The PRD as alignment artifact

The most valuable thing a PRD does isn't capture requirements. It creates a shared reference point for a conversation that would otherwise happen in fragments across a dozen Slack threads, three design reviews, and two engineering standups.

For AI features, the conversation that matters most is about quality. What does good look like? What does acceptable look like? What does unacceptable look like, and what happens when the model produces it? These questions have answers that the PM, the ML engineer, the designer, and the user researcher all hold differently until someone writes them down.

A PRD is a tool for building alignment, not explaining every detail. The spec is what you discuss, debate, refer to, and sync on. For AI products, the quality requirements section is where that alignment either happens or doesn't. A team that has agreed on a precision threshold, an evaluation methodology, a segment breakdown, and a failure behavior before engineering starts is a team that will have a substantively different conversation when the first model results come back than one that hasn't.

The PRD doesn't prevent disagreement. It moves disagreement earlier, when it's cheap, and away from the launch date, when it's expensive.

What comes next

You now have the documentation artifact that captures the product thinking this series has built. The next cluster of posts shifts from execution to responsibility. Building AI products well isn't only about architecture, data, and deployment. It's about building them in ways that are fair, safe, and trustworthy for all the users they affect.

Post 13 covers bias, fairness, and the metrics that protect your product. Not as a compliance exercise, but as a product craft question: what does it mean to build an AI feature that works as well for the users who need it most as it does for the users who are easiest to serve?