# AI-Era PRD Template (LeanX extended edition) > A prototype shows the feature. It can't show why you picked it, how you'll judge success, or when you'll stop. This record keeps those three things. - By LeanX (https://leanx.kr) · Version 1.0 · 2026-10-27 - Companion article (Korean): https://blog.leanx.kr/ai-era-prd-template - Structure inspired by "The 2026 AI-Era PRD Template", published by Sachin Sharma at Product Career Academy on 2026-09-01 (© Product Career Academy), and the expanded version Aakash Gupta shared on LinkedIn in October 2026. LeanX kept the eight-part skeleton and wrote its own wording and examples. This is not a reproduction of either original. - Fields LeanX added are marked `[LeanX addition]`. - Copy and adapt it freely within your team. A credit is appreciated. --- ## How to use it 1. Before writing anything, build several prototypes that take different approaches. (Both source templates suggest five.) 2. Run them against the same criteria and inputs, keep one, and note why the others lost. 3. Write this record for the one you kept. It answers "we decided on this, and here's why", not "may we build this?" 4. Keep appending results and decisions after launch. > **Final check:** could a colleague or an AI agent start work from this page alone, without asking you a single question? Any judgment left unwritten comes back as rework. (Adapted from the "Golden Standard" note in the source template.) --- ## 0. Document info | Field | Value | |---|---| | Feature | | | PM | | | Decided with | (engineering, design, data, legal/security) | | Status | Draft / Decided / Rolling out / Launched / Retired | | **Results dashboard** | (the first link anyone should open after launch) | | Last updated | | --- ## 1. Decision **One sentence.** > We compared [N] versions and are going with [the chosen one], mainly because [one or two reasons]. | Version | Approach | Link | Outcome | Why it won or lost | |---|---|---|---|---| | A | | | Kept | | | B | | | Dropped | | | C | | | Dropped | | **Comparison criteria** (agree on these before looking at the prototypes) - [ ] Does it actually reduce the core problem (reactions from at least 3 users)? - [ ] How does it fail on the hard inputs in section 4? - [ ] Latency and cost per request - [ ] Human time to operate and review it > Tip: an AI demo can look fine while hiding its failure rate. Choose by running every version on the same inputs, not by how good it looks. --- ## 2. Opportunity (one page at most) - **What's going wrong today:** who is affected, how often, and what it costs them - e.g. "HR answers about 80 travel-policy questions a week; people wait about a day for a reply." - **Evidence:** the single most important metric (with source and period) and three short user quotes - **Hypothesis:** "If we [do X], [who]'s [metric] will move by [amount], because [reason]." - **Why now:** which current company goal or bet this supports - **Cost of waiting:** (optional) --- ## 3. Prototype - **Link:** the version you chose. Reviewers should react to the real thing, so don't re-describe it in prose. - **Built with / time spent:** - **How it differs from the release:** what was deliberately left out (real data, permissions, billing…), so nobody mistakes it for the finished product. --- ## 4. Features & behavior contract ### 4-1. Features | Feature | What the user does | What the system does | Priority | |---|---|---|---| | | | | Must / Nice to have | ### 4-2. Edge cases and red team - **Edge cases:** empty input, very long input, other languages, stale data, users without permission… - **Red-team list:** inputs meant to break it: prompt injection, attempts to extract personal data, prompts that push it to invent numbers, requests for disallowed advice… ### 4-3. Tracking | Event | When it fires | Properties to log | |---|---|---| | | | (model ID, prompt version, latency…) | ### 4-4. Behavior contract (AI features) Spell out expected behavior as examples, four columns each. Aakash Gupta recommends 15 to 25 examples spanning good to outstanding responses; that range is his opinion, not a tested standard. | # | Input | Good response | Bad response | Must decline when | |---|---|---|---|---| | 1 | "What's the hotel limit for business trips?" | Cites the policy clause, the amount and the date it was last revised | Makes up an amount or quotes the pre-revision rule | Someone asks about another employee's expense claims | | 2 | | | | | - Mix easy, ambiguous and must-decline cases. - Prefer real requests and logs; strip personal data per 5-3. - Add one line on how it backs off when unsure (hand-off to a person, "let me check", etc.). > **`[LeanX addition]` Don't use the behavior contract as the launch test.** 15–25 examples are enough to agree on behavior but too few to decide a launch. If the true failure rate is 0.5%, a 20-case test shows zero failures about 90% of the time (0.995^20). Decide launches with the golden set in section 5 and live traffic. Anthropic's agent-eval guide suggests starting with "20-50 simple tasks drawn from real failures", and its success-criteria page prefers many automatically graded questions over a few hand-graded ones. --- ## 5. Measurement & evals ### 5-1. Graduation metric and guardrails | Type | Metric | Threshold | Compared with | Period | |---|---|---|---|---| | Graduate | e.g. median time to first answer on policy questions | 50% faster | control group | 2 weeks | | Guardrail | e.g. correction requests to HR | does not rise | control group | same | | Guardrail | e.g. share of answers inventing policy content | below 1% | sampled review | same | ### 5-2. Golden set (AI features) An offline test you run before launch: each input has a correct output or a grading rule. - Size: start with 20–50, grow with automated grading - Sources: real requests % / red team % / synthetic % - Grading: exact match / rule check / model-graded / human-graded - Pass bar: (e.g. 100% of must-pass items, 95% overall) - **Human review rubric:** accuracy, grounding, tone, decline judgment, 1–3 each - `[LeanX addition]` **Owner and refresh cadence:** who adds real failures, and how often. A stale golden set drifts away from real use. ### 5-3. `[LeanX addition]` Personal data - Does the golden set or contract contain real customer or employee data? Yes / No - If yes, how it is de-identified, and by whom: - What is sent to external model APIs, and how long it is kept: - Legal or policy basis for consent and notice: --- ## 6. Scope - **Included in this release:** - **Deliberately left out:** - **Known downsides we accept, and why:** --- ## 7. Rollout & rollback | Step | Who sees it | Duration | Gate to the next step | |---|---|---|---| | 1 | Internal | 1 week | Golden set passes, zero severe errors | | 2 | 5% of users | 1 week | Graduation metric beats control, guardrails hold | | 3 | 25% | 2 weeks | Same | | 4 | Everyone | | | - **Off-switch owner:** a named person and a backup - **Trigger:** a measured threshold - e.g. "Turn it off the same day if sampled review finds more than 1% invented policy answers, or HR correction requests double." - `[LeanX addition]` **What it falls back to:** - `[LeanX addition]` **Who to notify:** > Switching a feature off stops it; it does not undo data already sent or payments already made. Write down a separate recovery step for those. --- ## 8. Release criteria & change log ### 8-1. Done means Checks anyone on the team can answer yes or no: - [ ] Golden-set pass bar met - [ ] Tracking events confirmed in production logs - [ ] Off switch flipped once and restored - [ ] Personal-data items in 5-3 signed off ### 8-2. Change log Start with v1 at launch. Each later entry records the results link, anything unexpected, and whether you'll keep improving, expand, or stop. | Version | Date | What changed | `[LeanX addition]` Model ID · prompt version | Golden-set score | Results link | Unexpected | Decision | |---|---|---|---|---|---|---|---| | v1 | | First release (5%) | | | | | Improve / Expand / Stop | > A new model version or prompt is a product change even when no code changed, so log it here. --- ## Appendix: when you can skip this A small team with shared context may only need the prototype and a short note. In a regulated industry, across several teams, or at a scale where mistakes are expensive, keep a decision record.