The Idea Validation Playbook: from AI hunch to defensible PRD

Most AI ideas die in the gap between “we have a hunch” and “we have a spec a senior engineer can estimate”. The hunch is cheap. The spec is hard. In between sits a one- to two-week stretch of work that decides whether the project ships at quality or burns six figures on a feature pile that nobody wants and no engineer will sign their name to. The 2018 SaaS playbook called that stretch discovery and gave it four weeks of customer interviews. The 2026 AI playbook calls it validation and gives it nine numbered stages, an artifact at each one, and a clear kill-criterion at the end. This is that playbook.

This article is the cluster anchor for idea validation → PRD within the broader idea-to-product manifesto. Where the manifesto names what idea-to-product is as a service category, this playbook names what the founder and partner do in the first 1–2 weeks of the engagement — the operating sequence that produces a PRD a senior engineer can estimate, a founder can operate, and a vendor cannot bait-and-switch on.

Why Most AI Ideas Die Before the PRD
The Nine Stages
A Worked Example: Inbox-Triage Agent for Solo Consultants
The Nine-Question Idea-to-PRD Self-Test
Frequently Asked Questions
Closing

Why Most AI Ideas Die Before the PRD

The death-zone has a recognizable shape. A founder shows up with a hunch — “every solo consultant is drowning in email; an agent could triage it.” The hunch is plausible. The market exists. The technology can plausibly do it. The founder talks to five friends, gets five “I’d use that,” writes a one-page brief, and goes shopping for a vendor. Twelve weeks and $180K later, the demo works on the founder’s inbox, breaks on every other inbox, and produces an inference bill that would make any unit-economics-conscious operator wince. The product never reaches paying users. The founder concludes that AI is hard.

AI is not the problem. The problem is that the brief was not a spec. A one-pager that says “the agent triages email” does not tell a senior engineer how to estimate the build, does not tell the founder how they will know it works, and does not tell either party how the product will pay for itself at scale. The first 1–2 weeks of any AI build should be spent closing that gap.

Three structural reasons make this stretch the single most consequential period of the engagement.

First, AI products are non-deterministic by construction. A SaaS PRD can say “when the user clicks Save, the row is persisted” and that statement is testable in one assertion. An AI PRD that says “when the user clicks Triage, the agent labels the email correctly” needs a fixed evaluation set, a quality threshold, an escalation policy, and a regression check — because correctly is a distribution, not a boolean. The validation work that produces those artifacts cannot be skipped.

Second, the model layer changes underneath the product. Frontier models update on cycles of weeks. OpenAI shipped GPT-5 and the GPT-5.4 update over the past year; Anthropic shipped Claude Opus 4 through Opus 4.6; Google shipped Gemini 3.1 Pro; the open-weights frontier moved from Llama 3 to Llama 4 Scout (Artificial Analysis LLM Leaderboard). Each transition silently changes the behavior of any system pinned to a model alias. A PRD that does not specify the eval contract is a PRD that cannot survive its first model migration.

Third, the pilot-to-production gap is the dominant failure mode. Gartner’s 2024 and 2025 CIO surveys consistently report that roughly 85% of AI pilots stall before reaching production at scale. McKinsey’s State of AI in early 2025 found that while 78% of organizations now use AI in at least one function, only a small fraction capture meaningful enterprise value. BCG’s Where’s the Value in AI? traces roughly 70% of that value capture to people and process change — work the PRD must anticipate. The 85% that stall are the projects that skipped the validation playbook below.

A non-engineer founder who runs the nine stages that follow does not guarantee a shipped product. They eliminate the failure modes that kill the most projects before week 3.

The Nine Stages

Each stage below is written in five parts: name, output artifact, time budget, role (who runs it), and failure mode prevented. Run them in order. Skipping the first three because “we already know our user” is the single most common reason a validation effort fails — the validation that confirms what you already believe is the validation that taught you nothing.

Stage 1. Frame the Hunch

The first stage is to write the hunch down in a constrained format that surfaces what you do not yet know. The format is intentionally narrow: one sentence for the user, one for the trigger, one for the desired outcome, one for the existing alternative. Four sentences. No more. If the founder cannot compress the hunch to four sentences, the hunch is not yet an idea — it is a mood.

The constraint matters because most founders, asked to describe their idea, will produce a feature pitch (“the agent will read your inbox, classify each email, draft replies, schedule meetings…”). A feature pitch is a solution masquerading as a problem statement. The four-sentence frame forces the founder to start at the user and end at the alternative, which is where every honest validation begins.

The frame also produces a falsifiable artifact. “Solo consultants spend the first 90 minutes of every workday on inbox triage; they currently triage manually” is a sentence either true or false in the population. “Our agent will revolutionize inbox management” is neither.

Output artifact: one-page hunch frame (user / trigger / outcome / current alternative).
Time budget: 60 minutes. If the founder cannot finish in 60 minutes, the hunch needs more thinking, not more writing.
Role: founder writes, partner facilitates.
Failure mode prevented: solution-first framing. The founder commits to building a thing instead of solving a problem and discovers in week 10 that the thing solves nobody’s problem.

Stage 2. Falsify the Problem

Once the hunch is framed, the next stage is to try to kill the problem statement with five to eight user conversations. The discipline is borrowed from Rob Fitzpatrick’s The Mom Test: ask about the user’s life and past behavior, not about your idea. The questions are not “would you use this?” — they are “walk me through the last time you did this”, “what did you do in the 60 minutes before opening your laptop today”, “show me the tools you actually use to manage this”.

The goal is asymmetric. If the problem is real, the conversations will produce specific, painful, repeated stories that converge across people. If the problem is not real — or is real but not painful enough to pay for — the conversations will produce a polite “yeah I guess that’s annoying” five times in a row. A founder who treats polite-ness as confirmation is a founder building a product nobody will buy.

The conversations also surface the existing alternatives the user is already paying for. If solo consultants are already paying $30/month for SaneBox and $20/month for Superhuman, the wedge for a new agent is narrower and the pricing ceiling lower than the founder assumed. That fact belongs in the PRD, not at the post-launch demo.

Output artifact: conversation log (5–8 interviews, raw notes, named alternatives, common phrases).
Time budget: 5 to 8 days of calendar time, 6 to 12 hours of work time.
Role: founder runs the conversations; partner reads the transcripts and flags pattern breaks.
Failure mode prevented: confirmation bias. The founder hears what they wanted to hear and builds the product they already wanted to build.

Stage 3. Feasibility Probe

Stage 3 is the AI-specific stage that has no analog in the 2018 SaaS playbook. Before any further validation work, the founder and partner must answer a single question: can current models actually do this?

The probe is a one-day exercise. Take the hardest concrete capability the product needs — for the inbox-triage example, “given an email plus the user’s last 30 days of replies, classify the email into one of seven priority buckets with calibrated confidence” — and build the smallest possible test. A prompt, 30 to 50 representative inputs harvested from stage 2 conversations, a frontier model, an evaluator. Run the test. Read the failures. Form a view on whether the capability is at the model’s current ceiling, below it, or above it.

The probe is decisive in three ways. First, if the capability is comfortably below the ceiling — modern frontier models handle it consistently above the founder’s threshold — the project moves forward with confidence. Second, if the capability is at the ceiling, the PRD must specify the eval threshold tightly and the escalation policy seriously, because every model update could move the floor. Third, if the capability is above the ceiling — the model cannot reliably do the thing — the project is either scoped down to what the model can do or paused until the field catches up. SWE-Bench Verified — the most-watched benchmark for autonomous coding — moved from roughly 12% in early 2024 to consistently above 65% in late 2025 (arXiv 2310.06770, Anthropic SWE-Bench coverage). The relevant benchmark for the founder’s capability is rarely SWE-Bench specifically; it is some benchmark, somewhere on arXiv or on the Artificial Analysis leaderboard, that tells the founder where the floor is today.

Output artifact: feasibility memo (capability spec, 30–50 test cases, observed pass rate, ceiling assessment).
Time budget: 1 day for the probe build, 1 day for the test + memo.
Role: senior engineer (or founder with sufficient tooling) runs the probe; founder reads the memo.
Failure mode prevented: scoping above the model’s ceiling. The team commits to a build the underlying technology cannot do today and discovers in week 8.

Stage 4. Draft the Eval Cases

The eval suite is not a QA artifact. The eval suite is the spec. Once stages 2 and 3 have produced a real problem and a feasible capability, the next stage is to draft the eval cases that define what good means — before any further architectural work.

The eval cases come from three sources. The first source is the raw conversation log from stage 2: the actual scenarios users described, transcribed into model inputs. The second source is the feasibility probe from stage 3, which surfaced the model’s failure modes; each failure becomes an eval case. The third source is the founder’s domain knowledge: edge cases the founder knows the product must handle even if no user mentioned them.

The output is typically 50 to 150 cases. Each case has an input (the email, the document, the user query), an expected behavior class (correct classification, refuse, escalate to human), and a quality threshold (a binary pass/fail, a 1–5 rubric score, or a comparison against a reference output). Tooling matters less than the existence of the suite — Promptfoo, LangSmith, Ragas, or a hand-rolled harness all work.

The discipline that scopes AI projects in evaluations rather than features is the operating core of the eval-first build playbook, and it is the reason every editorial we publish argues to stop scoping AI projects in features and scope them in evaluations.

Output artifact: eval-suite seed file (50–150 cases, input / expected behavior / threshold, checked into version control).
Time budget: 2 to 3 days, parallel with stage 5.
Role: founder authors the cases (because the founder owns the domain knowledge); partner formats them into the eval harness.
Failure mode prevented: ship-and-pray. The team ships software with no way to tell whether the next deployment is better or worse than the last.

Stage 5. Map the Workflow

A defensible PRD describes a workflow, not a feature list. The workflow map shows every step from the user’s first touch to the system’s final action, every system the product calls into, every place a human is in the loop, and every place the LLM is in the loop. The artifact is a single diagram — Excalidraw, FigJam, a whiteboard photo — supplemented by a numbered description.

The map’s purpose is to surface the integration surface, which is where most AI MVPs balloon in cost. An inbox-triage agent that reads Gmail is a different product than one that reads Gmail, Outlook, Fastmail, and Front. A workflow that calls one model is a different product than one that orchestrates three model calls with retry logic, a tool-calling layer, and a vector store. The workflow map is the document where the founder and partner agree on which integrations are in scope for the MVP and which are explicitly out.

The map also surfaces the human-in-the-loop decisions. Where will the agent ask the user to confirm? Where will it refuse and escalate? Where will it act autonomously? Each of those is a product decision, not an engineering detail, and each belongs in the PRD signed by the founder.

Output artifact: workflow diagram + numbered step description, integrations listed in/out of scope, human-in-the-loop policy.
Time budget: 2 days.
Role: partner drafts; founder reviews and signs off.
Failure mode prevented: scope creep. The team agrees verbally on scope, the engineer interprets it broadly, and the build doubles in size by week 6.

Stage 6. Model the Unit Economics

A 2018 SaaS MVP could ignore unit economics until traction; a 2026 AI MVP cannot. The inference bill is real money from the first user. Stage 6 produces a one-page unit-economics model: cost per request, cost per active user per month, cost per document processed, cost per agent run.

The math is mechanical. For each LLM call in the workflow from stage 5, multiply input tokens by the model’s input price, multiply output tokens by the output price, sum across the user’s typical day. Add the vector-store query cost, the embedding cost, the orchestration overhead. Multiply by expected daily usage per user. Subtract from the price the founder believes the user will pay. The remainder is the per-user margin at scale.

If the remainder is positive at reasonable scale, the project moves forward. If it is negative, the workflow must be redesigned — by routing cheap operations to smaller models, by caching, by reducing context window, by moving expensive steps offline. The redesign happens now, in validation, not in week 10 when the product is already built around the expensive architecture. The full economics shape, including the typical numbers, expands in the AI MVP economics playbook.

Output artifact: unit-economics worksheet (per request, per user per month, per document, vs. expected price).
Time budget: 1 day.
Role: partner drafts; founder reviews the assumptions.
Failure mode prevented: economically unshippable architecture. The team builds a product whose per-user inference cost is higher than the price the user will pay.

Stage 7. Stress-Test the Risk Surface

Every AI product has a risk surface: prompt injection, data exfiltration, hallucination in high-stakes contexts, regulatory exposure, model deprecation, vendor outage, runaway agent loops, IP infringement in generated content. Stage 7 is a one-day exercise in writing down which risks apply to this product and what the policy is for each.

The exercise is not a security audit. It is a triage. For each risk, the founder and partner answer three questions: Does this product expose us to this risk? If so, what is the mitigation? What is the policy if the mitigation fails? The answers go into the PRD as numbered constraints, not as a separate “security” document that nobody reads.

The risks that matter most for a non-engineer founder’s MVP, in our observation:

Prompt injection: if the agent reads user-supplied content (emails, documents, web pages), what stops a malicious sender from instructing the agent to exfiltrate data or take destructive action?
Hallucination in high-stakes outputs: if the agent generates a customer-facing reply, what is the policy when the model is confident and wrong?
Regulated data: is any PII, PHI, or financial data in scope? If so, which models can process it and which cannot?
Vendor lock-in: if Anthropic doubles the price of Opus tomorrow, what does the founder do? (See model-agnostic by construction.)
Agent autonomy: where in the workflow can the agent take an irreversible action? What confirmation pattern gates it?
Output artifact: risk register (named risks, applicability, mitigation, policy on failure).
Time budget: 1 day.
Role: partner drafts; founder reviews; legal counsel reviews if regulated data is in scope.
Failure mode prevented: post-launch surprise. A risk the team did not name in validation becomes the incident that takes the product offline in week 14.

Stage 8. Set Kill Criteria

Every validation effort needs an explicit answer to the question how will we know this idea is dead? Without that answer, the team will not kill a dying idea — they will keep iterating, keep moving the goalposts, and keep burning runway. The kill criteria belong in the PRD because the alternative is a project that quietly fails to launch and quietly costs everyone six figures.

The criteria fall into three categories. The first is demand criteria: a stage 2 finding that nobody actually has the problem at the intensity required. The second is feasibility criteria: a stage 3 or stage 4 finding that the model cannot hit the eval threshold at acceptable cost. The third is economic criteria: a stage 6 finding that the per-user inference cost exceeds the price the user will pay. Each criterion has a numeric threshold and a date by which the project is paused or killed if the threshold is unmet.

The discipline of setting the kill criteria in advance is what separates a founder who can ship from a founder who keeps “iterating”. The founder who set kill criteria at the start of validation can hear in week 6 that the eval pass rate is stuck at 58% against a 75% threshold, and can act on that fact. The founder who did not set the criteria will rationalize the 58% as “close enough” and ship a product their users do not trust.

Output artifact: kill-criteria list (3 to 5 numeric thresholds, each with a date and an action).
Time budget: 90 minutes, after stages 1–7 are complete.
Role: founder owns; partner facilitates.
Failure mode prevented: zombie projects. The team ships nothing while quietly burning budget on a hypothesis nobody is willing to falsify.

Stage 9. Write the Defensible PRD

Stage 9 assembles the artifacts from stages 1–8 into a single document that meets three tests: a senior engineer can read it and produce a credible estimate, a founder can read it and operate the resulting product, and a vendor cannot bait-and-switch on the scope mid-build. A PRD that fails any of the three tests is not defensible.

The minimum sections, in our observation:

Problem statement — from stage 1, refined by stage 2.
User and workflow — from stages 2 and 5.
Capability spec and eval contract — from stages 3 and 4. This is the section the SaaS-era PRD did not contain.
In-scope and out-of-scope integrations — from stage 5.
Unit economics target — from stage 6.
Risk register and policies — from stage 7.
Kill criteria — from stage 8.
Acceptance criteria for each milestone — the planning, build, and hardening milestones each end with a checkable list of deliverables.

The document is typically 8 to 20 pages. It is short because the eval suite, the workflow diagram, and the unit-economics worksheet are attachments, not prose. The PRD points at them. A 60-page narrative PRD with no eval contract is a worse artifact than a 10-page PRD with one — and is also the dominant artifact in the 2010s consulting industry.

The defensible PRD travels with the project. It is checked into the same repository as the code, versioned, updated when scope changes, and re-read at every milestone review. The founder owns it. The partner contributes to it. Neither party can change it unilaterally.

Output artifact: PRD (8–20 pages) + attached eval suite, workflow diagram, unit-economics worksheet, risk register.
Time budget: 2 days of writing, distilling the artifacts from stages 1–8.
Role: partner drafts; founder edits and signs; senior engineer reads and produces estimate.
Failure mode prevented: the bait-and-switch. The vendor agrees to a vague scope, builds whatever is cheapest, and bills the founder for “additional work” when the founder objects.

A Worked Example: Inbox-Triage Agent for Solo Consultants

The nine stages above land more honestly when walked through a single hypothetical idea. Below is one idea — an inbox-triage agent for solo consultants — pushed through every stage.

Stage 1 output (hunch frame)

Solo independent consultants (10–40 client engagements active at a time) spend the first 60 to 90 minutes of every workday triaging email. The trigger is opening the laptop in the morning. The desired outcome is a triaged inbox with a prioritized action list. The current alternative is manual reading plus a mix of SaneBox, Superhuman, and Gmail labels.

Stage 2 output (conversation log, summarized)

Seven interviews with solo consultants in management consulting, design, and tech freelancing. Findings:

Six of seven describe the morning triage as painful; one delegates it to a virtual assistant.
The pain peaks during proposal-cycle weeks, not steady-state.
All seven already pay for at least one tool; four pay for Superhuman ($30/mo).
The dominant pain is not classification — it is deciding which client thread to act on first given the active engagement context.
A polite “yeah I’d try that” from three; a specific “I would pay $50/mo if it actually reduced my morning by 30 minutes” from two.

Pattern break: the hunch assumed “classification” was the pain. The conversations show that prioritization given engagement context is the pain. The PRD will reflect this.

Stage 3 output (feasibility memo)

Capability under test: given an inbound email plus a 30-day rolling context of the user’s reply patterns and active engagement list, output a priority bucket (1–5) with a 1-sentence rationale.

Probe build: 40 representative inputs harvested from stage 2 transcripts (with permission), Claude Opus 4.6 evaluating against a founder-graded rubric.

Result: 33 of 40 cases scored “useful or better” by the rubric. 5 cases marginal. 2 cases the model misranked confidently and incorrectly. Conclusion: capability is comfortably below the model’s ceiling for the priority bucketing; the confident-wrong cases will need an escalation pattern.

Stage 4 output (eval suite seed)

80 cases drawn from the conversation log + probe failures + founder edge cases. Each case: input email, 30-day context summary, expected priority bucket, expected rationale class, expected confidence. Threshold: 75% pass rate on the bucket, 90% pass rate on the escalation behavior (the agent must refuse to act when confidence is below 0.6).

Stage 5 output (workflow map)

The MVP workflow has six steps: ingest email via Gmail API → fetch user context from prior 30 days → call LLM for priority bucket + rationale → if confidence is below 0.6, escalate to user with a 2-option choice → write priority label to Gmail → log to inference-cost dashboard. Outlook is explicitly out of scope for MVP. Calendar integration is out of scope. Reply drafting is out of scope.

Human in the loop: every escalation. Autonomous: every above-confidence classification.

Stage 6 output (unit economics)

Per email: ~2K input tokens (email + context), ~200 output tokens. At Anthropic Claude Sonnet 4.6 pricing, roughly $0.012 per email. A typical user receives 80 emails per day, 60 of which trigger the agent. Daily cost per active user: ~$0.72. Monthly cost per active user: ~$21.60. The interviews suggest a $50/mo price ceiling. Gross margin at scale: ~$28/user/month before serving and overhead. Sustainable. (Routing low-stakes emails to a cheaper model would compress this further.)

Stage 7 output (risk register, top 3)

Prompt injection via inbound emails: high applicability. Mitigation: treat all email content as untrusted; the LLM is instructed to never act on instructions embedded in email bodies; the agent’s only authority is to label and escalate.
Hallucinated priority on a high-stakes thread: applicable. Mitigation: the confidence threshold; the escalation pattern. Policy on failure: the user can override any label, and overrides are logged into the eval suite as future test cases.
PII handling: applicable. Mitigation: data processing agreement with the model provider; no email content is logged outside the user’s own deployment.

Stage 8 output (kill criteria)

If fewer than 4 of 7 interviewed consultants confirm specific willingness-to-pay above $30/mo by end of stage 2, pause.
If eval pass rate is below 60% on the priority bucket after the feasibility probe, pause and reconsider scope.
If per-active-user-per-month inference cost exceeds 50% of expected revenue per user, redesign before build.

Stage 9 output (PRD shape)

The PRD is 14 pages, with attached eval suite (80 cases), workflow diagram, unit-economics worksheet, and risk register. A senior engineer reads it and produces a 6-week build estimate at ~$80K with confidence. A founder reads it and can name every behavior the product is committed to. A vendor cannot bait-and-switch because the eval contract pins the quality bar and the workflow map pins the integration scope.

The worked example is hypothetical, but the shape of the artifacts is the shape we would expect from any disciplined first 1–2 weeks of an idea-to-product engagement. The point is not the inbox-triage product. The point is that every stage produces an artifact, every artifact pins down a decision, and every decision the team makes in this window costs ten times less than the equivalent decision made in week 8 of the build.

The Nine-Question Idea-to-PRD Self-Test

A founder can run this self-test in under 30 minutes, alone, before any vendor conversation. A “no” or “I don’t know” on any question is a stage of the playbook that has not been done. If three or more answers are weak, the idea is not yet validated and the founder should not yet be shopping for a vendor.

Can you compress your hunch into four sentences — user, trigger, outcome, current alternative — without writing a feature? If no, you are still in solution-first framing. Return to stage 1.
Have you had 5+ user conversations in which the user described their actual past behavior, not their reaction to your idea? If no, you have opinions, not evidence. Return to stage 2.
Have you built a one-day feasibility probe that ran 30+ representative inputs through a frontier model and produced a pass rate? If no, you do not know whether the technology can do this. Return to stage 3.
Do you have 50+ written eval cases, each with an input, expected behavior, and quality threshold, in version control? If no, you have no spec — you have a vibe. Return to stage 4.
Have you drawn the end-to-end workflow with every integration explicitly in or out of scope, and named every place a human is in the loop? If no, the scope will balloon. Return to stage 5.
Do you have a per-user-per-month inference cost estimate, compared against your expected price? If no, you may have an economically unshippable architecture. Return to stage 6.
Have you written down the top 3–5 risks for this product, with a mitigation and a policy on failure for each? If no, the post-launch incident is already booked. Return to stage 7.
Have you set 3–5 numeric kill criteria with dates, beyond which the project is paused or killed? If no, you will not kill a dying project — you will burn runway. Return to stage 8.
Could a senior engineer read your PRD and produce a credible estimate within 60 minutes — and could you, the founder, read it and name every behavior the product is committed to? If no, the PRD is not defensible. Return to stage 9.

Score 8 or 9 of 9: you are ready to ship the planning milestone and quote the build. Score 5 to 7: you are 3 to 5 days of disciplined work away from defensible. Score 4 or below: do not commission a build. The vendor will quote whatever they can sell and the resulting project will join the 85% that stall.

For founders who have run the self-test and want to know what the next 6 to 12 weeks should actually look like with a partner in the room, anatomy of an AI agency engagement: what the first 14 days should look like is the natural next read. For founders unsure whether to hire a partner at all, the DIY-with-AI manifesto walks the decision tree. For founders entering vendor conversations, the AI discovery call playbook tells you which questions to ask.

Frequently Asked Questions

What is the difference between a 2018 SaaS PRD and a 2026 AI PRD?

A 2018 SaaS PRD is a feature list. A 2026 AI PRD is a workflow plus an eval contract. The SaaS PRD said “the user can filter by date”; the AI PRD says “given these 80 representative customer queries, the assistant must produce a useful answer on at least 75 of them, must refuse on the 4 designated edge cases, and must escalate to a human on the 1 ambiguous case — checked on every commit.” The eval contract is the load-bearing addition. Without it, the team has no way to detect a regression caused by a model update, a prompt change, or an upstream behavior shift. Every other section of the AI PRD — the unit-economics worksheet, the risk register, the kill criteria — exists because the underlying technology is non-deterministic and updated outside the team’s control.

How long should idea validation take for an AI product in 2026?

One to two weeks of focused work, distributed over 5 to 8 calendar days. The nine stages compress to roughly 8 to 12 working days of total effort, parallelized between the founder and partner. A validation effort that runs longer than three calendar weeks usually means the team is avoiding stage 2 (the user conversations) or stage 3 (the feasibility probe) because one of those is going to deliver bad news. The honest pattern is to time-box validation at two weeks and act on whatever the artifacts say at the end of it — including pausing the project.

Can a non-engineer founder run this playbook alone?

Most stages, yes. Stages 1, 2, 4, 6, 8, and 9 are founder-led — they are about the user, the domain, and the economics. Stages 3 (feasibility probe), 5 (workflow map), and 7 (risk register) benefit from partner support because they require sufficient familiarity with the model stack to run a probe, draw a workflow that an engineer can implement, and name the risks that actually apply. A non-engineer founder with access to Cursor, Claude Code, and a senior engineer for 8 to 12 hours of pairing can run the full playbook for under $5K of consulting cost — and should, before committing to a build.

What does a defensible PRD look like in 2026?

It is short and dense — typically 8 to 20 pages — with attached eval suite, workflow diagram, unit-economics worksheet, and risk register. It meets three tests: a senior engineer can read it and produce a credible estimate, a founder can read it and operate the resulting product, and a vendor cannot bait-and-switch on the scope mid-build. The eval contract is the section that distinguishes a defensible 2026 AI PRD from a 2018 SaaS one. A 60-page narrative PRD with no eval cases is not defensible — it is consulting deliverable theater.

How big should the eval suite be at the validation stage?

Fifty to 150 cases is the working range. Below 50, the suite cannot distinguish a regression from a flake; above 150, the team is over-investing in test cases before the product is built. The right number depends on the workflow’s surface area: a single-step classification task needs 80 to 100 cases; a multi-step agent with tool calls and retry logic may need 200 to 400 by the time it ships. The validation-stage suite is a seed; it grows with the product. The key discipline is that the seed exists before code is written.

What is the most common reason an AI idea fails at the PRD stage?

Skipping stage 3 (feasibility probe). Founders and partners want to move forward quickly, the demo on the founder’s data looked promising, and the team assumes the technology will work across the broader case set. It often does not. The feasibility probe — 30 to 50 representative inputs, one day of work, an honest read of the pass rate — is the cheapest insurance against committing to a build the model cannot do. The second most common reason is skipping stage 6 (unit economics), which produces a product architecturally married to an inference bill that exceeds the user’s price tolerance at scale.

What is the difference between idea validation and the build?

Idea validation produces a PRD a senior engineer can estimate. The build produces the shipped product. The two are separate phases with separate budgets, separate deliverables, and separate kill criteria. A 2026 idea-to-product engagement typically structures them as the planning milestone (2–3 weeks, ~$30K, idea validation playbook) and the build milestone (6–8 weeks, ~$80K, the engineering work). The hardening milestone (2–3 weeks, ~$40K) follows the build. Conflating validation and build is the source of most scope drift — and most of the projects that join the 85% that stall before production.

Should I write the eval suite myself or let the vendor write it?

You write it; the vendor formats it. The eval suite is a domain artifact — what good means for your users is your knowledge, not the vendor’s. A vendor who writes the eval suite without your input is writing a suite the model can pass, not a suite that protects your users. The right pattern: you draft the cases in plain prose (input, expected behavior, why it matters), the vendor translates them into the harness format and wires them into CI. You sign off on the cases. You retain the right to add cases at any time during the build.

How do I know the model can actually do what my idea requires?

Run the feasibility probe in stage 3. Take the hardest concrete capability in your workflow, build the smallest possible test (a prompt, 30 to 50 representative inputs harvested from your user conversations, a current frontier model), and grade the outputs against your quality bar. Read the failures, not just the pass rate — failure modes tell you whether the capability is at the model’s ceiling, below it, or above it. For reference points beyond your own data, the Artificial Analysis LLM Leaderboard, recent arXiv submissions, and Anthropic’s and OpenAI’s public eval reports give a current floor. If the probe shows the capability is above the model’s ceiling, scope down or wait — do not commission a build.

What happens if I commission a build without running this playbook?

The dominant outcome is that the project joins the 85% Gartner tracks as stalled before production. Specifically: the scope drifts because there is no workflow map, the team disagrees on quality because there is no eval contract, the inference bill surprises everyone because there is no unit-economics worksheet, and the project ends in a six-figure write-off because there are no kill criteria. The vendor blames the founder for vague requirements; the founder blames the vendor for poor execution; both are correct. The playbook above is designed to prevent that exact failure mode by closing each of the gaps it depends on.

Closing

The first 1–2 weeks of any AI build are not the throat-clearing before the real work. They are the real work. Every stage above produces an artifact that costs ten times more to fix in week 8 than to write in week 1. The nine artifacts together — hunch frame, conversation log, feasibility memo, eval suite, workflow map, unit-economics worksheet, risk register, kill criteria, defensible PRD — are what separate the AI products that ship from the ones that join the 85% that stall.

The founder is the protagonist of all nine stages. The partner facilitates, drafts, and pressure-tests. The senior engineer reads the PRD at the end and tells the founder whether the build is estimable. If the engineer hedges, the playbook is incomplete. Return to whichever stage produced the weakest artifact and do that stage again.

The cost of running the full playbook is in the order of a planning milestone — about three weeks of calendar time, a small five-figure budget if a partner is in the room, and roughly 20 hours of focused founder work. The cost of skipping it is the entire build budget. The arithmetic is one-sided.

Validate first. Specify second. Build third. In that order, with discipline, the project ships.

— Arthur Wandzel, CEO, SFAI Labs