A non-engineer founder does not need to write a spec. They need to write a brief. A spec is an attempt at engineering completeness — and a non-engineer cannot finish one well. A brief is a set of decisions only the founder can make, and an engineer cannot finish one without it. The founder briefing pattern is a reusable five-component structure that unblocks an AI partner in under an hour: a one-sentence outcome, three representative inputs, what “right” looks like in plain English, the no-AI fallback, and what success looks like to a customer. Hand the partner that, and they can start work the same day.
This article extends the founder-AI-partner operating manual, part of the idea-to-product manifesto. Companion reading: the founder’s role in an AI MVP build, what an AI engineer actually does on your MVP day-to-day, and from idea to PRD: what the first 14 days should produce.
The failure mode this pattern fixes
There are two ways a non-engineer founder loses two weeks of an AI partner’s calendar before any code ships. Either the founder writes a spec they cannot defend — twelve pages with user stories, acceptance criteria, and system prompts drafted in ChatGPT — and the engineer spends a week unpicking the assumptions. Or the founder hands over one sentence (“a tool that triages our inbound leads”) and the engineer spends a week guessing what the founder actually meant.
Both failures share one root cause: the founder confused spec authorship with decision authorship. An engineer can write the spec. Only the founder can supply the five decisions that make the spec write itself. The brief records those decisions in the order an engineer can use, and it is reusable across every AI feature a non-technical founder will brief.
Why a brief is not a spec
Most product-spec literature optimises for completeness — more sections, more detail, more edge cases. A non-engineer reading that literature feels overwhelmed and either over-writes or under-writes. The brief flips the optimisation. It optimises for decision clarity — fewer questions, sharper answers, none of them about engineering itself.
BCG’s 2025 analysis of where AI value separates from AI hype names organisational clarity — who decides what, when — as the dominant variable. McKinsey’s The state of AI in 2025 reports 78% of organisations now use AI in at least one business function; briefing volume has exploded while briefing discipline has not.
A good brief is short — often two hundred words. The partner converts it into a PRD inside 48 hours, and the founder signs that PRD before any engineering begins. The brief is the founder’s contribution; the PRD is the partner’s; the eval set is the contract they both live by from week 3 onwards. The piece on from idea to PRD: what the first 14 days should produce shows the conversion.
Component 1: one-sentence outcome
One sentence that names what the customer or user gets when this works. Not the feature description. Not the technology. The outcome.
Shape: “When this works, our customer gets [outcome] in [timeframe], without [the friction this replaces].”
Well-formed examples:
- “When this works, our sales rep gets a prioritised list of three inbound leads to call first thing each morning, without scrolling through 80 raw form submissions.”
- “When this works, our finance team gets a categorised expense report by 9am Monday, without manually tagging 400 receipts.”
- “When this works, our support manager gets a one-paragraph summary of every customer email thread that exceeded five messages.”
A founder who cannot write this sentence does not have a feature — they have a vague hope. A founder who writes “an AI tool that uses GPT-5 to process inbound leads” has named the technology and the input but not the outcome, so the partner cannot tell whether the tool succeeded or failed.
The one-sentence outcome is the eval anchor. Companion pieces on the role of evals in your weekly partner relationship and what production-ready handoff looks like extend this point.
Component 2: three representative inputs
Three real examples of what the AI will receive in production. Not edge cases. Not the worst case the founder is worried about. The three most boring, you-will-see-this-on-a-Tuesday inputs — names, emails, company sizes, free-text fields, intact. Not anonymised in a way that strips signal. Not invented. Pulled straight from the form.
This is the component founders most often skip — and skipping it is the largest single cause of two-week wheel-spinning. An engineer reading “the system should classify inbound leads” cannot tell whether the inputs are 20-word responses or 200-word essays, whether company size is free-text or a dropdown, or whether the email field is always present. Model architecture, prompt structure, eval-set design, and the no-AI fallback all depend on what the input actually looks like.
Three is the right number. One is anecdote. Two is coincidence. Three is a pattern the engineer can prompt against. Anthropic’s public guidance on building effective AI systems and OpenAI’s prompt-engineering documentation both anchor on this: examples drive prompt quality more reliably than verbal description. The founder’s job is to source the examples, because the engineer cannot — the customer data lives behind the founder’s logins.
Component 3: what “right” looks like in plain English
The founder’s gut judgment of correctness, written in their own words. Not prompt-engineering language. Not technical criteria. Plain English, in the form of what a domain expert would say after looking at a model output.
Shape: “If I looked at this output, I would say it was right when [criterion 1], [criterion 2], [criterion 3]. I would say it was wrong when [failure 1], [failure 2].”
For the inbound-lead triage product:
Right when: the top three leads come from companies with more than 50 employees, the “what brings you here” field mentions a budget or a deadline, and the rep can see the company’s revenue range at a glance. Wrong when: the top three are all competitors doing research, all from companies that already booked a call last quarter, or all from the same country when the rep covers four.
This is the eval rubric in plain English. The engineer converts it into an automated eval set — typically 30 to 100 graded examples — that runs against every model version. The founder owns the rubric; the engineer owns the encoding. Regulated-industry founders (legal, medical, financial) should expand this component — what counts as a dangerous answer matters as much as what counts as right.
Component 4: the no-AI fallback
The founder’s decision about what the system does when the model is unavailable, slow, refuses, or returns an obviously wrong answer. This is the most AI-specific component of the brief, and the one most founders forget — because pre-LLM software did not need it.
LLM-based features fail in ways traditional software does not. The model can refuse. It can hallucinate confidently. It can take 30 seconds instead of 3. The vendor can have an outage. The founder owns the customer-facing answer to “what happens then?” — a product decision, not a technical one.
Three common fallback shapes:
- Pass-through: the user sees the raw input in its native order. Works when the AI is a convenience layer over already-working software.
- Cached previous result: the user sees the last successful AI output, clearly marked as stale. Works when freshness is nice-to-have but availability is essential.
- Hold and notify: the user sees a “refreshing” state and gets an alert when the AI catches up. Works when the user can wait but cannot tolerate a wrong answer.
The founder picks one per feature. The partner builds it. The eval set checks the fallback path as a first-class test case.
Component 5: what success looks like to a customer
Observable behaviour — what a customer would notice if they used this tool for a week and it was working. Not metrics. Not a percentage. A description.
Shape: “After a week of using this, my customer would say [observation 1], [observation 2], [observation 3].”
For the inbound-lead triage product:
After a week, my rep would say: “I open the dashboard at 8:55am, the top three leads are pinned, I dial the first one by 9:01, and by lunchtime I’ve spoken to all three. Last quarter that would have taken me until 11am. Twice this week the top lead was someone I’d already pitched — the tool isn’t perfect.”
This is the founder’s contract with the customer. The metrics — open rate, dial-time-to-first-call, conversion rate — are downstream of the behaviour. A founder who writes only metrics gives a target without a story; a founder who writes only the story gives colour without a target. Both belong: behaviour first, imperfection acknowledged, then any leading metric.
The behaviour description doubles as the user-research script for the W5 eval-set validation and the W9 launch-readiness check — companion piece what you should expect from your AI MVP partner in the first 14 days walks through these checks.
Worked example: the inbound-lead triage tool
Take a hypothetical SaaS startup — LeadSorter — with 80 inbound demo-request submissions a week and two sales reps. The founder has hired an AI partner for a 6-week MVP build. Here is the brief, twice.
The bad brief
“We need an AI tool that triages our inbound leads using GPT-5 so reps don’t have to scroll through the form submissions. Should integrate with our CRM. Important: it should be production-ready.”
What the engineer cannot tell: what an inbound lead looks like, what triage means (sorting, scoring, filtering), what a rep does today, what “production-ready” means to this founder, what happens when the model is down, or what the customer would notice if it worked. Two weeks of partner time goes into extracting these answers via Slack.
The good brief (five components)
1. One-sentence outcome. When this works, each of our two sales reps gets a prioritised list of three inbound leads waiting in their inbox by 8:55am every workday, without scrolling through the 15–20 form submissions that arrived overnight.
2. Three representative inputs. Three real form submissions from the past week:
“Sarah Chen”, sarah@midsizeretailer.com, “MidSize Retailer Inc.”, 200–500 employees, VP of Operations — “Budget approved for Q3, looking to evaluate 2–3 vendors this month, your demo came up in a Loom share from a peer at LogisticsCo.”
“Test User”, test@gmail.com, blank company, 1–10 employees, Engineer — “checking out the product.”
“Daniel Okonkwo”, d.okonkwo@oldname-newcompany.com, “OldName (now NewCompany)”, 50–200 employees, Founder — “Left LegacyTool last quarter, already had a call with your CSM Marcus in April, coming back to buy.”
3. What “right” looks like in plain English. Right when: the top three come from companies with 50+ employees, the “what brings you here” field mentions a budget, a deadline, a current tool, or a peer reference, and the rep can see whether this is new or a repeat conversation. Wrong when: the top three are gmail/yahoo addresses, the free-text field is empty or one word, or a known competitor’s domain shows up in the top three.
4. The no-AI fallback. If the model is unavailable or slow (over 30 seconds), the rep sees the raw form submissions in reverse-chronological order with a banner: “AI triage refreshing — showing newest first.” The rep can still work; the AI is a convenience, not a gatekeeper.
5. What success looks like to a customer. After a week, each rep would say: “I open the dashboard at 8:55am, the top three are pinned with a one-line reason each, I dial the first one by 9:01, and by 11am I’ve spoken to all three. Last month that would have taken me until 1pm. Twice this week the top lead was a known competitor that snuck through — the tool is good, not perfect.”
What changes for the partner
The 6-week engagement now has all five anchors by end of day one. The PRD writes itself in 48 hours. The eval-set design is obvious. The architecture decision becomes an engineer-side call the partner can make in an afternoon. The bad brief produces a 6-week engagement that ships at week 8; the good brief ships at week 6 with an eval-set score the founder trusts.
What the founder explicitly does NOT write
A good brief is defined as much by what the founder leaves out. The following belong on the partner’s side of the line:
| Section | Why the founder skips it |
|---|---|
| Model name (GPT-5, Claude Opus 4.8, Gemini 2.5) | The partner picks based on cost, latency, and eval pass rate. The founder ratifies the budget and behaviour, not the model. |
| System prompt drafts | Pasted ChatGPT prompts often anchor the engineer onto a weaker approach. Show the inputs and right-when rules; let the partner write the prompt. |
| Architecture choices (RAG, vector stores, agents, tools) | Engineer decision. The founder cares about the result and the cost. |
| Eval framework selection (promptfoo, Inspect, Langfuse) | Engineer decision. The founder owns the rubric; the engineer owns the encoding. |
| Latency targets in milliseconds | The founder names a customer-felt tolerance (“under 5 seconds feels fine, over 30 seconds breaks the workflow”); the partner converts. |
| Cloud or hosting provider | Engineer decision unless the founder has a hard compliance constraint (HIPAA, FedRAMP) — in which case the brief names the constraint, not the provider. |
| Repository structure, CI/CD, deployment pipeline | Not the founder’s business until handoff. |
The sibling on what an AI engineer actually does on your MVP day-to-day walks through how engineers convert the brief into the decisions above.
How to know your brief landed
The partner’s response in the first 48 hours tells the founder whether the brief did its job. Three signals matter.
Signal 1: clarifying questions about the rubric, not the technology. A partner asking “what counts as a known competitor — can you share a list?” is engaging with the brief on its own terms. A partner asking “should we use GPT-5 or Claude Opus 4.8?” is asking the founder to do the partner’s job — a flag on the partner, not the founder.
Signal 2: the PRD lands inside 48 hours. A 2–4 page PRD that converts the five components into engineering language: outcome → success criteria, inputs → input schema, right-when rules → eval rubric, fallback → degraded-mode behaviour, customer-visible success → acceptance test. Longer than 48 hours signals brief gaps the partner is still working around.
Signal 3: a thin-slice demo by end of week 1. Not the final product. A 10-minute Loom showing the three representative inputs flowing through a prompt and producing outputs the founder can react to. Pair these signals with the cadence in how an idea-to-product engagement actually works week-by-week.
FAQ
How long should the brief be?
Two hundred to four hundred words of prose plus three input examples attached as files. Briefs over 600 words are usually founders accidentally writing the PRD — which slows the partner down, not up.
Can the founder write the brief in a meeting with the partner instead of in advance?
Yes, and that often produces a better brief faster. The pattern works as a written artefact or as a one-hour structured conversation where the partner takes notes. What does not work is writing a long document alone and waiting for the partner to react.
What if the founder genuinely does not know what “right” looks like yet?
That is a sign the feature needs a discovery sprint before a build sprint. A founder who cannot describe right-vs-wrong in their own words is ready for a 1-week discovery engagement to find the rubric, not a 6-week build.
Does this pattern work for non-AI features?
The five components map cleanly onto any product brief, with one change: the no-AI fallback collapses into a more general “edge-case behaviour” component. The AI-specific value of component 4 is that LLM failures are common enough to deserve their own slot.
Should the brief reference the model name?
No. Today’s SOTA is GPT-5, Claude Opus 4.8, and Gemini 2.5. By the time the engagement ships, the SOTA may have moved. The partner chooses and re-chooses; the brief should outlast the model.
Should the founder specify a per-call cost budget?
The founder specifies a monthly cost ceiling and a customer-facing tolerance (“we charge customers $50/month per seat — this feature cannot cost us more than $5 per seat per month at full usage”). The partner converts that into a per-call budget.
How does the brief change for a regulated industry?
Component 3 expands. In legal, medical, or financial domains, the right-when/wrong-when rubric should name the regulatory boundary explicitly — what counts as dangerous, what counts as out-of-scope, what counts as a referral case. The other four components stay the same shape.
Who signs off on the brief — the founder alone, or the whole team?
The founder alone, for a non-engineer-founder-led company. Briefing-by-committee adds delay without improving the brief. Run co-founders or customer-success leads through it as a 30-minute review after the founder writes it.
What if the partner says the brief is not enough?
A useful conversation, not a failure. The partner should name which of the five components is too thin and propose a 30-minute working session to thicken it. A partner who says “we need more detail” without naming which component is being lazy — push back.
Can the brief be reused across multiple features in the same engagement?
Component 4 (no-AI fallback) and parts of component 5 (customer-visible success) often carry across features within the same product. Components 1, 2, and 3 should be re-written for every feature — the outcome, inputs, and right-when rules are feature-specific by definition.
The briefing pattern is the discipline that lets a non-engineer founder ship AI features without ever writing a spec. The five components map to the five decisions only the founder can make. Everything else is the partner’s job — which is what the founder hired them for.
Arthur Wandzel
