glossary · general
Product requirements document (PRD)
A living document that defines the problem, target users, success metrics, scope, and acceptance criteria for a product or feature before engineering begins.
A PRD forces clarity on three questions before a single line of code is written: Is this problem worth solving? Who has it? How will we know when we have solved it? In 2026, that framing matters more than the template. When agentic coding tools can produce a working demo in hours, the PRD is no longer a feasibility contract with engineering. Feasibility is largely free. The document now exists to prove the problem is viable and that the solution will earn genuine use. The most important sentence in a modern PRD is the hypothesis, and most PRDs do not have one.
The 8 sections a modern PRD contains
Classic waterfall PRDs ran to 30 pages. Modern teams use leaner, living versions with eight sections:
- Overview. One paragraph: what this covers, what feature or product, who owns it.
- Problem statement. Specific pain, specific user, evidence. Not a market trend paragraph.
- Target users. One or two segments, named with specificity. “SMB finance teams on month-end close” is useful. “Users” is not.
- Goals and success metrics. Where the hypothesis lives: “We believe [user] has [problem] and will [behavior change] if we [intervention], measured by [metric].” Every metric needs a threshold, not just a direction.
- Scope. Capabilities, not UI descriptions. Short enough to read in five minutes.
- Out of scope. Explicitly what is excluded and why. This section signals PM judgment more than the scope list does. What you exclude is a decision; what you omit is a deferral.
- User stories and acceptance criteria. The behavioral definition of done. For AI features, criteria must be probabilistic, not binary.
- Assumptions, constraints, and open questions. The bets that could be wrong. A PRD with no open questions has moved the hard questions to the parking lot.
A PRD longer than four pages for a single feature is a red flag.
How AI products change the format
Probabilistic output breaks binary AC. A feature that “works” in deterministic software maps to “performs at or above X% accuracy across Y test distribution” in AI. Miqdad Jaffer, Product Lead at OpenAI, published an AI PRD template with a dedicated section covering hallucination rates, bias audits, model drift monitoring, and accuracy thresholds. His concrete example: at least 90% accuracy on labeled test sets as a measurable PRD requirement.
For AI products the PRD must also answer: What is the acceptable output quality floor? What is the fallback when confidence drops below threshold? What does model drift trigger? What is the latency SLA at p95?
In 2026, PRDs are parsed by AI coding agents (Cursor, Copilot) alongside human engineers. Vague scope produces the wrong feature when consumed by an agentic tool with no clarifying loop.
PRD vs PR/FAQ vs user story
A user story is a single unit of work with AC; it lives inside the PRD. A PR/FAQ precedes the PRD entirely: a structured argument that the product is worth building. A PR/FAQ answers “should we build this?” A PRD answers “here is what we are building and how we will know it is done.” Using one as a substitute for the other signals the candidate does not understand the working-backwards sequence.
The LLM-bloat failure mode
22% of PMs now use AI tools for spec writing, up from 4% in 2024, saving 6 to 9 hours per week. The risk: drafts that cover every section at length and say nothing specific. An out-of-scope section with 10 items, no rationale. Goals with no thresholds. A problem statement about an industry instead of a user. Time saved writing is lost on engineers reading documents that don’t answer the one question that matters.
Use the swap test: can this paragraph appear in a PRD for a different product and still read correctly? If yes, it is not finished.
What interviewers are testing
“Walk me through your PRD process” is not a question about section names. It checks whether you understand the document’s job is to force judgment, not capture information. At AI-native companies, the additional signal is whether your AC handles probabilistic output.
strong
"I start with the hypothesis: what user behavior am I betting will change, and what number will tell me I won? The out-of-scope section is where I show judgment: I name what we are not building and the reason, because exclusions are decisions, not defaults. For AI products I add output quality thresholds, fallback behavior when confidence drops below the floor, and latency SLAs at p95. Binary pass/fail AC doesn't work for probabilistic systems."
weak
"A PRD lists the features we are going to build and what success looks like." No hypothesis, no exclusion rationale, no answer for AI features. The tell is "lists the features" rather than "defines the problem and the bet." Interviewers read this as template recall, not product thinking.
For the document that precedes the PRD in Amazon’s process, see PR/FAQ. For how AC must adapt for AI features, see acceptance criteria. For the argument on why viable and lovable are now the scarce resources the PRD must prove, see feasibility is free.