A PRD is estimable when a senior engineer can read it once and write a 14-day plan with calibrated confidence. Not whether the document covers every generic-template section; not whether legal signed off. A PRD is either an estimation input or it is decoration. Seven sections, in order, are what convert a hunch into an input the dev team can price.
This is the engineer-facing counterpart to the founder-facing Idea-to-PRD framework within the idea validation playbook and the idea-to-product manifesto. The framework produces the answers; the AI PRD explained describes the artifact; this article structures the answers into the seven sections an AI dev team needs.
Why estimability is the only PRD test that matters
Generic PRD templates measure completeness. That worked in the 2018 SaaS era because the unit of estimation was the feature. In 2026 the unit is the AI capability the feature depends on, the eval set that bounds correctness, and the fallback when the model is wrong. None of these have a decade of pattern-matching behind them, and an AI engineer asked to estimate from a feature-list PRD pads two-to-three times.
McKinsey’s State of AI in early 2025 tracks about 78% organizational adoption against a much smaller share capturing measurable value. The gap is upstream — most AI builds start from PRDs the dev team could not estimate.
Section 1: One-sentence outcome
The PRD’s first paragraph names a user, a task, a context, and a success criterion the user can verify themselves — in one sentence. Strip any one and the estimate widens.
Estimable.
Solo independent consultants who triage email manually want their inbox prioritized within five minutes of opening their laptop, so they spend the first hour on the three messages that matter rather than scrolling fifty.
A senior engineer reads that and can start drafting the data model, naming the latency budget, and sizing the eval set.
Vague. “An AI email assistant” names a category. “Help busy professionals manage email” names a market. “Build a smart inbox” names a feature. Each costs the engineer two days of clarification before estimation.
Founder self-check. Read it to a non-AI friend. Ask: who, what, when, how do they know it worked? If they cannot answer all four after one read, the sentence is not yet estimable. Procedure in the Idea-to-PRD framework, Question 1.
Section 2: Capability dependency
Once outcome is locked, the PRD names the single AI capability the build depends on. Frontier models have very different ceilings across families. A PRD that says “the product uses AI” forces the engineer to estimate every family — 3x inflation, avoidable.
The seven families:
| Capability | Example tasks | 2026 frontier posture |
|---|---|---|
| Classification | Triage email by urgency. Tag a clause as risky. | Excellent on short clean inputs. Cheapest family to ship. |
| Extraction | Pull party names and dates from a contract. | Strong when the schema is small and bounded. |
| Generation | Draft an NDA. Write a customer reply. | Fluent. Factual reliability depends on grounding. |
| Planning | Book a meeting across three calendars. | Inconsistent beyond five steps without scaffolding. |
| Dialog | Coach a salesperson live during a call. | Weakest at long multi-turn dialog with strict state. |
| Tool-use | Call an API to read a CRM record, then write a draft. | Strong when tools are well-described. Brittle when schemas drift. |
| Multi-modal | Read a screenshot, propose a UI change. | Improving fast on Claude Opus 4.8, GPT-5, Gemini 2.5 Pro. |
Estimable. A primary capability, named. A secondary if needed. One sentence from a 20-to-40 input feasibility probe naming the model and the hit rate.
Primary: classification (priority bucket 1–5 given email body and 30-day reply context). Secondary: generation (one-sentence rationale). Probe: 33 of 40 useful-or-better on Claude Opus 4.8.
Vague. “It uses AI” forces an estimate across every family. “It uses LLMs” names a tool category. “It uses RAG” names an architecture pattern. None answer the capability question.
Founder self-check. If you name a model, architecture, or vendor before the capability, you are solving the wrong problem first. Feasibility procedure in the AI feasibility check.
Section 3: Task taxonomy
The engineer needs to know what the AI must actually do — broken into 5 to 15 named sub-tasks, each estimable on its own. Most founder PRDs collapse this into “the AI triages email,” which the engineer cannot estimate.
Estimable. Each row names a task ID, a one-sentence description, the capability it pulls from, and upstream dependencies.
| Task ID | Description | Capability | Input depends on |
|---|---|---|---|
| T01 | Bucket each new email into priority 1 to 5. | Classification | T00 (raw inbox poll). |
| T02 | Generate a one-sentence rationale per bucketing. | Generation | T01. |
| T03 | Detect insufficient context and abstain with a null bucket. | Classification | T01. |
| T04 | Tag urgency drift across a 30-day window. | Classification | T01 plus T00 history. |
| T05 | Re-bucket the inbox when a thread updates. | Classification | T01 plus T00 delta. |
| T06 | Roll up a 9 a.m. priority digest. | Generation | T01, T02. |
The estimate composes: T01 gets six days of eval-driven prompt iteration; T02 is a thin wrapper at a day; T03 is the abstention policy at two days.
Vague. “The AI reads the inbox and tells the user what’s important.” Is “reads” classification, extraction, or both? Is “important” rubric-defined or vibes?
Founder self-check. Fewer than 5 rows, the tasks are too coarse. More than 15, the founder has not decided what to cut from the MVP. Companion frame in the AI MVP map.
Section 4: Eval set
The 2026 AI PRD’s load-bearing artifact is the eval set — a frozen list of representative inputs paired with a rubric that defines correct output. Without it, “the AI works” is a vibes claim, not a contract.
Estimable. A 50-to-150 row set covering the task taxonomy in proportion to user impact, plus a 1-to-5 anchored rubric two independent reviewers could apply and agree on within one point.
Eval set V1, frozen for the 14-day build: 80 emails across 8 verticals graded priority 1–5; 40 edge cases (short, signature-only, auto-replies, non-English, ambiguous); 30 abstention cases where the correct output is the null bucket. 150 total rows, version-controlled, hash-signed.
Rubric anchors (T01): 5 = bucket matches grader with a defensible rationale. 4 = off by one with an acceptable rationale. 3 = off by one with a weak rationale. 2 = off by two-plus or misleading rationale. 1 = confidently wrong; the user would act and regret.
Shippable now has a definition: scoring 4-or-better on 85% of rows, with no 1-score on the abstention subset.
Vague. “Accuracy above 90%” — against what set? “Users are happy” — outcome metric, not rubric. “We’ll write the eval set during the build” — scope creeps every revision.
Founder self-check. Run 10 realistic inputs through Claude Opus 4.8 or GPT-5. Hand-grade 1-to-5. If you cannot describe in writing why each grade is what it is, the rubric is not yet a contract. Structural argument in stop scoping AI projects in features, scope them in evaluations.
Section 5: Failure budget
AI products fail probabilistically. A PRD that does not name acceptable failure rates targets perfection by default — which guarantees the build ships late or compromised.
Estimable.
| Failure mode | Tolerable rate | Policy when exceeded |
|---|---|---|
| Confident misclassification on the critical subset | 0% | Block deploy. Roll back. |
| Confident misclassification on the long tail | 2% | Investigate. Iterate prompt. Re-run eval. |
| Refusal when none warranted | 5% | Log. Flag for prompt iteration. |
| Hallucinated rationale text (T02) | 1% | Block deploy. Iterate or shorten output. |
| Latency above 5 seconds | 5% of requests | Investigate model choice and retry policy. |
| Cost above 4 cents per email | 10% of requests | Investigate prompt length and model choice. |
The build plan now has six numeric gates instead of one fuzzy “ships when good enough.”
Vague. “High accuracy” is not a budget. “Reliable” is a wish. “Errors should be minimized” — which ones, how much budget? The Stack Overflow Developer Survey 2025 reports about 75% of developers using AI tools alongside lingering trust concerns; the failure budget turns ambient distrust into a contract.
Founder self-check. Force-rank the modes. Which would you tolerate at 10% before pulling the product offline? Which at 0.1%? A flat budget is a non-estimable budget.
Section 6: No-AI fallback
The model errors, refuses, times out, or the vendor is unavailable. A 2018 SaaS PRD implicitly answered “the feature does not work today.” That answer was fine for a CRUD form, unacceptable when the model is the product. The fallback is four concrete decisions:
- User-visible behavior. Banner, null state, stale-but-shown last result?
- Background behavior. Re-queue, retry, drop? At what intervals?
- Cost ceiling on retries. Per-request spend cap before the system stops retrying.
- Rollback target. Which prior model-and-prompt combo, signed off in the eval suite?
Estimable.
No-AI fallback (T01): User-visible: null bucket plus a banner reading “Triage unavailable. Review manually.” Background: re-queue with exponential backoff (5s, 30s, 5m, 30m); drop after four failures with a daily aggregate report. Cost ceiling on retries: 5 cents per email per 24 hours. Rollback: last 7-day-stable model-and-prompt combo signed off in eval suite V1.
The fallback is a one-day task, not a two-week post-launch fire drill.
Vague. “Shows an error message” — what error, where? “Retries” — how long, at what cost? “Graceful degradation” — a label, not a behavior.
Founder self-check. Describe behavior under five named failures: API 500, rate limit, refusal, latency above 30 seconds, model deprecation. Same answer for all five means the fallback is not designed.
Section 7: Observability minimum
The PRD names the signals logged from day one and the on-call window the dev team holds post-launch. Most founder PRDs treat observability as a post-launch concern — which is why so many AI builds ship without the telemetry to debug the first incident.
Estimable.
| Signal | What is logged | Where it lives |
|---|---|---|
| Inference event | Request ID, user ID, task ID, model, prompt hash, tokens in/out, latency, cost, output text. | OTel trace plus Postgres event table. |
| Rubric grade (sampled) | 5% of events sent to a hand-grading queue, scored 1–5, fed back into eval V2. | Eval queue plus version-controlled CSV. |
| Eval drift | Daily re-run of eval V1 on production. Alert if score drops more than 5 points week-over-week. | CI job plus Slack alert. |
| Fallback trigger | Count and category of fallback invocations per hour. | Dashboard tile. |
| Cost per user per day | Aggregated spend per user. | Dashboard tile. |
| On-call window | Founder plus senior engineer Mon–Fri 9–6 PT for first 30 days. After-hours ack within 4 hours. | PRD-signed agreement. |
The observability estimate is now two to three days, not the typical “we’ll add logging later” black hole.
Vague. “We’ll add logging” — which signals, what schema? “Standard monitoring” — a label, not a list. “Figure out on-call after launch” — the dev team cannot estimate the window the founder will demand.
Founder self-check. If the production model breaks at 2 a.m. on a Saturday, who gets paged, how long to ack, what dashboard do they open? Build discipline in the eval-first build playbook.
Putting the seven sections together
| Section | What the engineer extracts | What the founder commits to |
|---|---|---|
| 1. One-sentence outcome | Data model and success metric. | User, task, context, measurable outcome. |
| 2. Capability dependency | Risk floor and model shortlist. | The single AI capability the build bets on. |
| 3. Task taxonomy | The decomposition the 14-day plan is built from. | 5 to 15 named sub-tasks. |
| 4. Eval set | The shippability test the build is bound to. | A frozen 50-to-150 row set plus a 1-to-5 rubric. |
| 5. Failure budget | The gates the build must pass to ship. | Error modes, tolerable rates, breach policies. |
| 6. No-AI fallback | Behavior when the model is wrong. | Four decisions: user-visible, background, cost ceiling, rollback. |
| 7. Observability minimum | Telemetry and on-call commitment. | Signals logged, dashboards built, on-call window agreed. |
A PRD with all seven is an estimable input — a senior engineer reads it in 90 minutes and produces a 14-day plan with confidence intervals tight enough to price. A PRD missing one is non-estimable in proportion. Skip Section 2, the estimate inflates 2-to-3x. Skip Section 4, the build window has no end. Skip Section 6, the first vendor outage becomes a two-week fire drill.
Want a fill-in template? The AI MVP Scoping Worksheet walks all seven sections with prompt fields, anti-pattern checks, and a one-page PRD scaffold a dev team can read and estimate from.
Frequently Asked Questions
How long does writing a PRD with all seven sections take?
Six to ten working hours across three sessions, for a founder who has validated demand and run a feasibility probe. Sections 1–3 in session one (three hours), Sections 4–5 in session two (four hours, mostly the eval set), Sections 6–7 in session three (two hours).
Why seven sections and not twelve to twenty?
Everything beyond these seven is downstream. Integration surface, acceptance criteria, out-of-scope, GTM, pricing — all derivable once the seven load-bearing sections exist.
Can I cut Section 4 if the build is small?
No. Section 4 is the shippability test. Without it the build window has no end. A 50-row eval set is the minimum and takes about three hours to assemble.
What if the founder cannot write Section 7 yet?
Estimate without it and call out the gap. The dev team can scope a 10-day prototype that exercises Sections 1–6, but the production estimate stays open until Section 7 is signed.
Does this PRD shape work for internal AI tools?
Yes, with one adjustment. Section 1’s success criterion is usually a process metric (cycle time, queue length, error rate). Sections 2–7 are identical. The build is often shorter because Section 6’s fallback can be “the analyst does it manually.”
How does an AI dev team actually estimate from this PRD?
For each task in Section 3, the engineer estimates days for prompt-and-eval iteration (Section 4 sets the target), days for fallback (Section 6), days for the observability slice (Section 7). Sum, add 20% buffer for integration, produce a 14-day plan with one or two named risks. Detail in the AI MVP economics playbook.
My PRD has all seven sections but the dev team padded the estimate. What went wrong?
Section 2 is the most common silent failure: founders name a capability but skip the probe result, so the engineer cannot calibrate feasibility risk. Section 4 is the second most common: rubric written but eval set not frozen.
Should the eval set live in the PRD or in a separate repo?
Both. The PRD names the row count, rubric anchors, and V1 hash. The rows live in a version-controlled CSV or YAML alongside the build code.
How often does an estimable PRD update during the 14-day build?
Once, at the midpoint, by exception. A mid-build change triggers a rescope conversation, not a silent edit.
Closing
Seven sections, in order: outcome, capability dependency, task taxonomy, eval set, failure budget, no-AI fallback, observability minimum. A PRD with all seven is an estimation input a senior AI engineer can read once and write a 14-day plan from. A PRD missing any of them is a wish list the dev team prices defensively — and the build pays the difference. Companion reads: the AI PRD explained, the Idea-to-PRD framework, and stop scoping AI projects in features, scope them in evaluations.
Arthur Wandzel
