Six questions, asked in order, convert any AI hunch into a PRD a senior engineer can estimate. That is the entire claim. Skip one and the build estimate becomes a guess; reorder them and the founder ends up shopping for capabilities instead of solving for users. Six questions a non-engineer can hold in their head and run through in a single working session.
This is a spoke under the idea validation playbook within the idea-to-product manifesto. The playbook describes the 1-2 week validation sequence; the AI PRD explained describes the artifact the answers populate; this article is the conversation that produces them.
Why six questions, and why this order
Most AI MVP scoping fails because the founder starts with the capability instead of the user. The conversation opens with “we want an AI agent that does X” and works backward to a user. By the time a user shows up, the capability has hardened into a feature and the eval set is impossible to write because nobody knows what good output looks like.
The framework inverts that. Q1 fixes user, task, context. Q2 names the single AI capability the combination depends on. Q3 forces a written rubric. Q4 sets which failures are tolerable. Q5 names the off-ramp when the model is wrong or unavailable. Q6 forces the founder to articulate why this product survives the next frontier-vendor release.
Each constrains the next. McKinsey’s State of AI in early 2025 tracks 78% organizational adoption against a much smaller share capturing real value — the gap is mostly builds that started before these six answers existed.
Question 1: User, task, context, success criteria
The one-sentence test. Every part is mandatory: a specific user, a single verb-noun task, the situation that triggers it, and an outcome the user can verify themselves.
Good answer.
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.
The sentence names the user, task, context, and success criterion. A senior engineer can start drafting the data model.
Vague answer signals. “An AI email assistant” names a category. “Help busy professionals” names a market. “Make email better” names a wish. Each says the founder is one or two layers above the implementation — and that gap is paid in scope-creep weeks.
Diagnostic. Write the sentence three times for three segments. If two sound nearly identical, the segments are not different enough. If all three sound completely different, the founder is solving for three products and must pick one. See how to validate an AI product idea before you write a single prompt.
Question 2: What AI capability does this depend on?
Once user-task-context is locked, name the single AI capability the product bets on. Frontier models have very different ceilings across capability families. Classification is almost certainly feasible at 2026 frontier; long-horizon planning across more than five steps is borderline.
The seven families:
| Capability | Example tasks | 2026 frontier posture |
|---|---|---|
| Classification | Triage email by urgency. Tag a clause as risky. | Excellent on short clean inputs. |
| Extraction | Pull party names and dates from a contract. | Strong when 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 and generate a UI change. | Improving fast on Claude Opus 4.8, GPT-5, Gemini 2.5 Pro. |
Good answer. A primary capability, named, plus any secondary capability. A one-line ceiling reference from a 20-to-40 input feasibility probe — procedure in the AI feasibility check.
Primary: classification (priority bucket 1-5 given email body plus 30-day reply context). Secondary: generation (one-sentence rationale per classification). Probe: 33 of 40 “useful or better” on Claude Opus 4.8.
Vague answer signals. “It uses AI” — the founder has not thought about which AI. “It uses LLMs” — thinking in tools. “It uses RAG” — an architecture pattern, not a capability. If the answer names a model or architecture before the capability, the founder is solving the wrong problem first.
Question 3: What does right look like, written down?
If the founder cannot describe correct AI output in writing, the build cannot ship. The 2026 AI PRD’s load-bearing artifact is the eval set, and its load-bearing component is the rubric — what good means for this user, task, context.
Good answer. A 1-to-5 anchored scale two independent reviewers could apply and agree on within one point.
Rubric — priority classification (T01) 5 = bucket matches founder-graded ground truth exactly with a defensible rationale. 4 = off by one with an acceptable rationale. 3 = off by one with a weak rationale. 2 = off by two or more, or misleading rationale. 1 = confidently wrong; the user would act on it and regret doing so.
A reviewer knows what 4 versus 3 hinges on (rationale quality). The founder can hand it to a senior engineer without ambiguity.
Vague answer signals. “The output is good.” — not a rubric. “Users are happy with it.” — outcome metric, not rubric. “The classification is accurate.” — accurate against what? Fast fix: run ten realistic inputs through Claude Opus 4.8 or GPT-5, hand-grade 1-5, then reverse-engineer the rubric from the grades.
The structural argument for treating the rubric as the spec is in stop scoping AI projects in features, scope them in evaluations.
Question 4: What is the failure budget?
AI products fail probabilistically. A PRD that does not name acceptable failure rates implicitly targets perfection — which guarantees the build misses. The budget makes the founder’s tolerance explicit and forces the asymmetry between failures that matter and those that do not.
Good answer. A table naming each failure mode, the tolerable rate, and the policy when the budget is breached.
| Failure mode | Tolerable rate | Policy when exceeded |
|---|---|---|
| Confident misclassification on the critical subset | 0% | Block deploy. Roll back to last passing model and prompt. |
| Confident misclassification on the long tail | 2% | Investigate. Iterate prompt. |
| Refusal when none warranted | 5% | Log and flag for prompt iteration. |
| Hallucinated rationale text | 1% | Block deploy. Iterate prompt. |
| Latency above 5 seconds | 5% of requests | Investigate model choice and retry policy. |
Vague answer signals. “We need high accuracy.” — not a budget. “It should be reliable.” — wish, not a contract. “Errors should be minimized.” — every system minimizes errors; the question is which errors get how much budget.
Diagnostic. Force-rank the failure modes. Which would the founder tolerate at 10% before pulling the product offline? Which at 0.1%? A flat budget is a sign the founder has not thought about which errors hurt users most. The Stack Overflow Developer Survey reports about 75% of developers using AI tools alongside lingering trust concerns about output quality — the failure budget turns ambient distrust into a concrete contract.
Question 5: What does the product do when the model fails?
The no-AI fallback. When the model fails, errors, refuses, or is unavailable, what does the product do? A 2018 SaaS PRD implicitly answered “the feature does not work today.” That answer is unacceptable in 2026 — the model is the product, and a vendor-level outage is a product outage at the user level.
Good answer. Four decisions: what the user sees, what the system does in the background, the cost ceiling on retries, and which prior model-and-prompt combo the system pins to under rollback.
No-AI fallback. User-visible: null bucket with a banner reading “Triage unavailable; review manually.” Do not silently default to bucket 3 — null is the correct signal. Background: re-queue for retry. Cost ceiling on retries: $0.05 per email per 24 hours. Rollback: last 7-day-stable model-plus-prompt combo signed off in the eval suite.
Four lines of PRD that prevent the product from becoming useless during a two-hour vendor outage.
Vague answer signals. “It shows an error message.” — what error, where? “It retries.” — for how long, at what cost? “The user does it manually.” — does the system tell the user, or pretend it never tried?
Diagnostic. Describe behavior under five named failures: API 500, rate limit, refusal, latency above 30 seconds, model deprecation. If the founder gives the same answer for all five, the fallback is not designed — one error handler standing in for five distinct cases.
Question 6: What is the moat against a frontier-vendor feature?
Anthropic, OpenAI, and Google ship native versions of common AI features on a roughly quarterly cadence. A founder who cannot articulate what stops a vendor from shipping their product as a native feature in six months is building on borrowed ground.
Three durable moat categories:
- Proprietary data. Data the vendor does not have and cannot easily get — customer historical operational data, a domain-specific corpus the founder has labeled, or workflow artifacts that exist only inside a specific user category.
- Distribution. Access to a user segment the vendor cannot reach efficiently — a regulated industry, a niche professional community, an embedded position in an existing workflow tool.
- Trust. Compliance, certification, contracts, or relationships that mean a user will buy from the founder but not from a generic vendor product — typical in legal, medical, financial, and government segments.
Good answer. A named moat with a falsifiable claim about why the frontier vendor will not enter that surface in the next 24 months. A hypothetical founder running the inbox-triage scenario might write:
Moat: proprietary data plus distribution. 80 solo independent consultants onboarded and 4,000 historical email triage decisions labeled across 14 verticals — a dataset the frontier vendors cannot replicate without operating an email client. Distribution: a member directory in the UK and Ireland, a segment the vendors do not currently address.
Vague answer signals. “We have a better UI.” — the vendor can match it in a quarter. “We focus on a specific industry.” — verticalization is a hypothesis, not a moat. “We move faster than the big vendors.” — speed is a feature.
Diagnostic. Open a chat with Claude Opus 4.8 or GPT-5 and ask the model to play product manager at Anthropic. Describe the product. Ask “in 24 months, what is the cheapest way to neutralize this?” If the answer is “ship the same feature in the next model release,” the moat is too thin. See the AI idea evaluation playbook.
Putting the six answers together
The six answers produce a four-page PRD scaffold. The mapping:
| Question | PRD section |
|---|---|
| 1. User-task-context-success | One-sentence idea and user-and-task taxonomy. |
| 2. AI capability | Capability dependency and ceiling reference. |
| 3. What does right look like | Eval rubric and threshold per task. |
| 4. Failure budget | Failure-mode budget table. |
| 5. No-AI fallback | Product behavior under model failure. |
| 6. Moat | Competitive defensibility section the SOW will reference. |
The remaining PRD sections — integration surface, observability minimum, acceptance criteria, out-of-scope list — are mostly deterministic given those answers. They are described in the AI PRD explained; the estimation mechanics are in how to write a PRD that an AI dev team can actually estimate.
Want a fill-in template? The AI MVP Scoping Worksheet walks each question with prompt fields, anti-pattern checks, and a one-page PRD scaffold a partner can use as an intake artifact.
Frequently Asked Questions
How long does it take to answer the six questions?
For a founder who has validated demand, three to five working hours across two sessions. Q1 and Q6 are the slowest — they require committing publicly to a position. Q2 through Q5 are mostly mechanical once user-task-context is locked.
Do I need a partner or engineer in the room?
Q1, Q3, Q4, Q6 are founder-led. Q2 and Q5 benefit from a senior engineer’s review — eight to twelve hours of pairing. The founder-partner split is in the founder-AI-partner operating manual.
What if I cannot answer Q6?
Stop the build. A founder who cannot articulate a moat against frontier-vendor encroachment is building a feature, not a product. Go deeper on the user segment, or shelve until the moat is real.
Is six questions enough? Most PRD frameworks have twenty.
Six produce the load-bearing decisions. A 20-question framework asking for “user personas” and “competitive landscape” separately is usually the same question in different words.
Should I answer them in order or in parallel?
In order. Q2 before Q1 is the most common mistake — the founder shops for capabilities and back-fits users. Q4 before Q3 is the second most common.
What if my answer to Q2 changes after Q3?
Re-answer Q2. Capability and rubric are coupled — writing the rubric often surfaces a capability the founder did not name initially. Revising now costs hours; at build-week-eight it costs weeks.
Do these questions apply to internal AI tools?
Yes, with one adjustment. Q6 becomes “what internal-process moat does this build, and what is the build-versus-buy reasoning against the off-the-shelf alternative?” See build, buy, or fine-tune.
Don’t I need user research before answering these?
Yes — before answering Q1 honestly. The framework assumes three to five user conversations are already in the bank. Procedure in how to validate an AI product idea before you write a single prompt.
Closing
Six questions in order: user-task-context-success, AI capability, rubric, failure budget, no-AI fallback, moat. A founder who answers all six in writing has a PRD scaffold a senior engineer can estimate; one who skips any of them has a wish-list and a build estimate with an asterisk. The artifact is in the AI PRD explained; the build discipline is in the eval-first build playbook; the case for why the rubric and failure-budget answers matter most is in stop scoping AI projects in features, scope them in evaluations.
Arthur Wandzel
