Phase 4: Writing AI Product Requirements · 40 min · Product Compass AI PRD template · Markdown

The AI PRD

If your problem statement says 'AI', you've written a solution statement wearing a problem statement's clothes.

Hiring signal: AI PM postings at frontier labs and AI-native startups (base $150k-$238k, total comp $214k-$427k per Levels.fyi) consistently test one thing in the writing sample or take-home: can the candidate produce a PRD whose problem statement survives having every mention of 'AI' deleted from it. Reviewers read a PRD's first paragraph and its success-criteria section before anything else — a problem statement that describes a technology instead of a user problem, or a success section with only lagging business metrics and no leading indicator, is the single most common reason a take-home PRD gets rejected before the technical sections are even read.

What you will learn

Explain why an AI PRD's problem statement should be written without ever using the word 'AI'
Structure an AI PRD's core sections: problem statement, success criteria, leading indicators, and the fine-tune-vs-prompt decision
Distinguish a leading indicator (predicts future success) from a lagging indicator (confirms past success) in an AI feature's metrics section
Generate a complete AI PRD skeleton for a real feature idea using a structured template

The Problem

A PM at a mid-size e-commerce company drafts a PRD titled "AI-Powered Product Description Generator." The opening paragraph reads: "We will use a large language model to automatically generate product descriptions, reducing manual copywriting effort." Engineering builds it. Three months later, adoption is near zero. When the PM finally talks to the merchandising team who was supposed to use it, she learns the actual problem: merchandisers spend six hours a week writing descriptions for a long tail of low-volume SKUs that never get written at all, so those products sit live with a blank description field and never sell. The AI generator she shipped writes fine descriptions — for products merchandisers were already going to write descriptions for anyway, because those are the ones anyone remembered to open a ticket for. It solved a technology story, not the actual problem.

This is the single most common failure mode in AI PRDs, and it has a specific, teachable fix: the problem statement should never mention AI. Miqdad Jaffer, a PM at OpenAI, formalized this as the first rule in his widely-used AI PRD template — if you can't state the user's problem without referencing the technology you plan to use to solve it, you haven't found the problem yet, you've found a solution and back-filled a justification. "Merchandisers can't keep up with description writing for long-tail SKUs, so 40% of those products go live with no description and a 60% lower conversion rate" is a problem statement. "We need an AI description generator" is not — it's an implementation detail masquerading as a business case, and it will not survive contact with an actual user's actual workflow the way this lesson's opening example didn't.

The AI PRD's Structure

A traditional PRD and an AI PRD share a skeleton — problem, users, success metrics, scope, requirements — but an AI PRD needs sections a deterministic feature never requires, because the system's behavior is a distribution, not a fixed output. The structure this course uses, synthesized from Jaffer's Product Compass template and Reforge's generative-AI PRD guide, has seven load-bearing sections:

Problem statement — written with zero mentions of AI, ML, or the specific model. States the user's problem and its cost in a business metric.
Success criteria and leading indicators — the lagging business metric the feature is meant to move, plus the leading indicators that will show progress toward it long before the lagging metric has enough data to move.
Fine-tune vs. prompt decision — an explicit, justified call on whether the feature needs a fine-tuned model, a prompted foundation model, or a RAG pipeline, with the tradeoff reasoning written down, not left implicit in an engineering Slack thread.
Non-deterministic acceptance criteria — covered in depth in Lesson 2, but scoped here: what "correct" means for a system that won't produce the same output twice.
Data provenance and freshness — where the system's inputs come from, how current they need to be, and what happens when they're stale.
Cost projection table — covered in depth in Lesson 5: queries/day × tokens/query × $/month at launch, growth, and scale.
Guardrails and feedback loops — what the system must never do, and how usage data gets back into improving it.

The rest of this lesson focuses on sections 1 and 2, because they're the ones that determine whether the other five sections end up solving the right problem at all.

The "no AI in the problem statement" rule has a simple test
Delete every occurrence of "AI," "ML," "LLM," "model," and the specific product name from your problem statement's first paragraph. If what's left still clearly states a user's problem and its cost, you passed. If what's left is vague, circular, or doesn't make sense without the technology reference, you wrote a solution statement. This test takes thirty seconds and catches the majority of first-draft AI PRDs, including ones written by experienced traditional PMs new to AI features — the instinct to lead with the exciting technology is strong and needs to be actively suppressed.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Success Criteria: Leading Indicators, Not Just Lagging Ones, The Fine-Tune-vs-Prompt Decision Belongs in the PRD, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.