InterviewIntermediateEval-Driven Specification / Writing a PRD for an AI feature / #25
Give me the outline of an AI PRD from memory and justify each section.
The direct answer
If I only had time to write two sections of an AI PRD before code starts, I'd write the success-metrics section first, because it's the only section that lets you catch a wrong guess before a real customer does. I'd write the scope section second, because nothing else in the document can be written honestly until you've decided which guesses the AI is allowed to make alone. Every other section can be redone after the code ships. Those two can't.
The outline, ranked by what breaks first if skipped
Write the success-metrics section first, and define what "the wizard got it right" means, not just "did it finish."Why: it's the only thing that lets you catch a bad guess before a real customer lives through it, and once they have, you can't go back and give them a clean first ten minutes.
Lock scope and non-goals second: which guesses the AI may make alone, and which always need a human or a one-tap confirm.Why: nothing written after this can be honest until it's settled, every later section depends on it.
Write the failure-mode and guardrail section third: what happens the moment a guess is wrong, and how someone finds out.Why: a customer who's already had a silently wrong first ten minutes is the hardest thing in this whole list to win back.
Write the concrete AI behavior spec fourth, with real questions, real inputs, and worked examples of right and wrong output.Why: it depends on scope and guardrails already being decided, so writing it earlier means describing behavior for a shape that isn't settled yet.
Write the problem statement and target user fifth.Why: it's still necessary, but by the time you're time-boxed, everyone in the room already agrees there's a problem, so it's cheap to write fast and low-risk to redo.
Write the rollout and phased-launch plan last.Why: it's mostly forced by whatever the guardrail section already decided, so it goes fast once that section exists.
How to answer this, stage by stage
Seven moves, in the order I'd actually say them. The trap in this question is reciting the six-section template like a table of contents. An interviewer isn't asking what's in a PRD. They're asking what you'd protect first if you didn't have time to write the whole thing.
1
Put a real feature and a real deadline in the room
Say it like this
"Let me make this concrete. Say it's Pulseboard, an analytics tool that hooks into a new customer's Stripe and ad accounts and builds their first dashboard automatically. And say I've got one afternoon to write a build-ready PRD for a new AI step in that wizard, not two weeks. The order changes completely once there's a real clock running."
Why this works
A generic PRD outline is a list anyone can recite. A time-boxed one forces you to actually rank, which is the real question.
2
Say your structure out loud
Say it like this
"I'm going to rank the sections by what's hardest to undo if I skip it, not by what order the template prints them in. So: what does this whole document protect, which mistake can't be taken back, what has to be decided before the next part makes sense, what's cheap to check first, and then the actual order."
Why this works
Two seconds of structure tells the interviewer you have a method, not just an opinion about which section you personally like writing.
3
Reframe the question
Say it like this
"'Outline a PRD' sounds like a memory test. It isn't. Every team already knows the six sections. The real skill is knowing which two you'd protect if a review got moved up and you only had four hours, because that's the actual job most weeks."
Why this works
This is where a strong answer splits from a list of headings. It shows judgment instead of recall.
4
Give the ranked order
Say it like this
"Success metrics first: what does 'the wizard got it right' actually mean, not just 'did it finish.' Scope second: which guesses the AI can make alone versus which always need a person. Guardrails third: what happens the moment a guess is wrong. Then the behavior spec, then the problem statement, then rollout, in that order."
Why this works
This matches the direct answer exactly. An interviewer should be able to write this sentence down and grade everything after it against it.
5
Prove it with a failure
Say it like this
"Here's why that order matters. Pulseboard's original wizard PRD wrote success metrics as one line: completion rate above 80 percent. It held for months. Meanwhile about 1 in 6 new signups had a dashboard silently pointed at the wrong currency or leftover test data, and completion rate never once caught it, because it only checked whether the wizard finished."
Why this works
A compressed real failure is worth more than ten abstract reasons. It shows you've felt the cost of writing it the other way.
6
Say what's forced and what's safe to leave loose
Say it like this
"The behavior spec can't come before scope, because you can't write real examples of right and wrong output for a scope you haven't set yet. But the exact wording of the wizard's onboarding questions? Leave that loose. We rewrote it four times after launch and it cost nothing, because nobody's dashboard was wrong underneath it."
Why this works
Naming what you'd leave alone is what separates real judgment from blanket caution about every section.
7
Close on the one line
Say it like this
"So: success metrics first, scope second, guardrails third, the behavior spec fourth, the problem statement fifth, rollout last. If you remember one line: write the section that catches a wrong guess before it writes the section that describes the guess."
Why this works
Ends on the actual ranked decision, in a sentence a reader could repeat back cold.
Let's learn
An AI PRD is the document a team writes before building an AI feature, spelling out what it does, how you'll know it's working, and what happens when it's wrong.
Say Pulseboard is a SaaS analytics tool. New customers connect Stripe, their ad accounts, and a CRM, and Pulseboard builds them dashboards. The "First Dashboard" wizard is the AI step right after signup: it asks three quick questions, guesses which data sources and starter metrics matter most, and wires up a dashboard automatically instead of leaving someone to build one from a blank screen.
Knowledge spark: what a confidence check is
The AI's own guess at how sure it is about a pick, like which currency a Stripe account uses. High confidence, it just does it. Low confidence, it asks the person to confirm with one tap instead of guessing quietly and moving on.
When the wizard's original PRD got written, the team had two days before a launch review. The problem statement and the wizard's three questions got three drafts each, because that was the fun part to design. The success-metrics section got one line: "completion rate above 80 percent." The failure-mode section got one line too: "user can edit manually." Neither said what a wrong guess would look like, or how anyone would find out.
It shipped. Completion rate held above 80 percent for months. Nobody was worried, because the number they'd picked to watch never moved.
Signups with a silently wrong dashboard, before and after the guardrail section got written first
Completion rate stayed above 80 percent the entire time on both sides of this chart. It was never built to see the difference between a wizard that finished and a wizard that finished correctly.
Here is the turn. The extra mistakes were never really the point. A dashboard showing "$0 revenue" for a business that's actually doing fine looks, from the outside, like one confused customer. The real problem is that nobody had defined what "wrong" meant before launch, so nobody was watching for it, and the completion-rate metric had no way to say anything different.
We didn't measure whether the wizard worked. We measured whether it finished.
At its worst, this is not a support-ticket problem. Most customers who saw a wrong number didn't file a ticket. They just quietly decided the tool didn't work for them and stopped opening it. A product that gets someone's first ten minutes wrong, silently, ends up worse than a blank dashboard would have been, because a blank dashboard at least tells the truth about needing setup.
Scope is what everything else in the document is waiting on
The choice I would take back
When the original PRD was written, the team had two days and a launch review already on the calendar. The success-metrics section got one line because completion rate was the obvious, cheap number, and the team wanted the two days for the parts of the wizard people would actually see. That made sense at the time. I'd take it back and swap the order: write down what "right" means before spending a single hour polishing what the wizard asks.
What I would leave alone. The exact wording of the three onboarding questions never needed this kind of care up front. Pulseboard rewrote that copy four times after launch based on what confused people, and each rewrite went out the same day, at zero cost to anyone already through the wizard. Not every section carries the same weight.
The lesson. A PRD's printed order and its real priority order are two different things, and nobody had ever separated them out loud. The sections that are easiest to write are usually not the ones that are hardest to get wrong.
Now here is the same thing as a story
You don't need this to answer the question. Read it slower, when you want to feel why the order matters and not just recite that it does.
Anjali Reddy has owned Pulseboard's First Dashboard wizard for nine months. Before that she spent four years doing customer support at a different startup, which is where she picked up a habit nobody taught her: she reads a product the way a confused new user would, before she reads it the way a builder would.
She wrote the wizard's original PRD in two days, the way most people write a PRD when nobody's told them to do anything different: start at the top of the template and work down. Day one went to the problem statement and three drafts of the onboarding questions, because she could picture exactly how a customer would experience each version. By the afternoon of day two, with the launch review the next morning, she had twenty minutes left for success metrics and failure modes. She wrote "completion rate above 80 percent" for one, "user can edit manually" for the other, and closed her laptop.
For months, that felt like the right call. Completion rate held steady, quarter after quarter, comfortably above 80 percent. Anjali checked it every Monday. It was always fine.
One of these gets fixed by lunchtime. The other doesn't get a second try.
Then, on an ordinary Tuesday, an ops analyst doing a routine account-health pass noticed something odd: a cluster of customers from one quarter, still logging in every week, whose "Revenue" card had read close to zero since the day they signed up. Nothing had crashed. Nothing had errored. Somewhere in the wizard's setup, about 1 in 6 new signups that quarter, roughly 109 out of 640, had ended up with a dashboard quietly pointed at the wrong Stripe currency or leftover test-mode data. Real customers had been staring at numbers that made their own business look broken, for months, and had simply stopped trusting the tool instead of complaining about it.
We didn't lose 109 dashboards. We lost 109 first ten minutes.
Anjali pulled the completion-rate chart she'd checked every Monday. It hadn't dipped once. It couldn't have, because completion rate only asked whether the wizard finished setting something up, never whether what it set up was true. The metric had been healthy the entire time it was failing.
The decision that made sense back then had been made in a room with a launch review already on the calendar and twenty minutes left on the clock. Nobody was careless. The problem statement and the onboarding questions were the parts of the PRD Anjali could see clearly, so that's where the two days went. Success metrics and guardrails were the parts that required imagining failure, which is a harder thing to do well in twenty minutes than in two days.
I would take that back. Not the two days, and not the questions, which were genuinely good. Just the order. Two weeks later, Anjali got handed a real test of it: a roadmap review got moved up, and she had one afternoon, not two days, to write a build-ready PRD for a new step in the wizard, one that auto-detects a customer's time zone from their connected accounts. This time she wrote the success-metrics section first: not "did it complete," but "does the guessed time zone match what's actually true, checked against a sample of real accounts before ship." Then guardrails: any guess below a set confidence gets flagged for a one-tap confirm instead of shipping silently. Scope, the behavior spec, the problem write-up, and rollout all followed in the afternoon's remaining hours, in that order, each one faster than the last because the hard part was already decided.
The next quarter's cohort, about 600 new signups, came in under that version. About 2 percent had a wiring issue anyone had to fix by hand. Nobody found out about it from a customer going quiet. The guardrail found it first.
The thing I'd tell myself, if I could go back to that twenty-minute afternoon: a PRD's table of contents is not a priority list. Writing sections in the order they're printed is not a decision. It's the absence of one.
ORDER, pointed at a PRD instead of a calendar
FLIPS would go looking for a behavior that snaps, but nothing here is a two-setting switch, it's a document with six parts and one afternoon to write it. BOUND would size a number, but there's no estimate to build up. What's actually being ranked is a set of PRD sections by how badly it hurts to write each one last, so the framework is ORDER.
The clock doesn't change the order. It just makes the order visible.
O, outcome. Every section of this document is competing to protect one thing: a real customer's first ten minutes with Pulseboard goes well. Not "the wizard finished." Whether what it built was actually true.
R, reversibility. A wizard question that's worded confusingly is the easy mistake, rewritten and shipped the same day. A silently wrong dashboard that a real customer already lived through, and quietly stopped trusting, is the one you can't undo. Nobody can hand that customer a clean first ten minutes twice.
Knowledge spark: why completion rate hid the problem
Completion rate answers one question: did the wizard reach the end of its steps. It says nothing about whether the thing it built along the way was correct. A metric can stay perfectly healthy while the actual job is quietly failing, if nobody ever pointed it at the right question.
D, dependency. The guardrail section can't be written honestly until scope is settled: which guesses the AI is allowed to make alone, and which always need a human check. Write guardrails before scope and you're describing failure modes for a job that isn't defined yet.
E, evidence. Before writing the failure-mode section from imagination, pull twenty real sessions from a similar AI feature already live and see what kinds of guesses it actually gets wrong. One afternoon of looking at real data turns the guardrail section from a guess into something grounded.
R, rank. Success metrics first: what "right" means, not "finished." Scope second, because it unblocks everything after it. Guardrails third: what happens the moment a guess is wrong. The behavior spec fourth, once scope and guardrails give it something real to describe. The problem statement fifth, cheap and already agreed on by the room. Rollout last, mostly forced by whatever the guardrail section decided.
The check that makes ORDER honest
Swap what's actually at stake and the order should move. If a wrong guess in this wizard only ever produced a slightly odd-looking chart nobody made a decision from, the guardrail section could safely drop lower on the list. It's not the 17 percent alone that earns success metrics the top spot. It's that a customer built real trust, or lost it, on a number that was never checked.
Run it where the mistake is a permit, not a dashboard
A county building department rolls out an AI wizard that helps residents apply for home-improvement permits: upload a photo and answer a few questions, and it guesses which permit type the project needs.
O. Every section here protects one thing: a resident's application gets approved under the correct permit type, the one that actually covers the work being done. Not "the wizard produced an application."
R. A resident whose guessed permit type is wrong at submission is the easy case, caught by a clerk in review before it's ever filed. A resident who gets approved under the wrong permit type and starts building is the hard one: once work begins under an approval that skipped a required setback review, undoing it means real demolition, not a form correction.
D. The guardrail section, which permit guesses always route to a human before approval, can't be written until scope is set: which permit types are simple enough to auto-approve, and which, like anything touching structure or electrical, never are.
E. A clerk spot-checking this week's twenty AI-suggested permit types against the submitted photos costs one morning, and would catch a systematic miss, like decks near a property line getting waved through, before a single resident starts digging.
R. Success metrics first: does the guessed permit type match what a licensed reviewer would have picked, not just whether a form got submitted. Scope second. Guardrails third. The behavior spec fourth. The public-facing problem write-up fifth. The rollout schedule last.
Swap the trigger and it still runs
The county adds three new permit categories overnight for storm-damage repairs. The order doesn't move. Scope and guardrails still get written before the behavior spec, just for a wider set of guesses.
A cheaper photo-review vendor cuts costs by 30 percent but reads blurry photos worse. Same order. Success metrics still comes first, because now it has to catch a worse guesser, not a better one.
A new model version gets meaningfully more accurate at reading the photos. Doesn't reorder anything. Better is a claim until a real sample confirms it, and a resident under the wrong permit costs the same either way.
Where people run it wrong
Treating a healthy completion or submission rate as proof the AI is working, when it only ever measured whether a process finished, not whether it finished correctly.
Writing the behavior spec before scope is settled, so the "real examples" section quietly assumes a scope nobody actually agreed to.
Spending the time-boxed hours on the parts that are easiest to picture, like copy and UX, because they're satisfying to write, not because they're what's riskiest to get wrong.
If you're asked this cold
Say the outcome out loud before naming a single section. "Every part of this document is trying to protect one thing: a real person's first experience with what the AI decided for them holds up." Then rank from there. Every section you name after that has a reason attached instead of sounding like a table of contents read aloud.
Flashcards (click a card to flip it)
1 · THE FRAMEWORK
Which framework fits "give me the outline of an AI PRD and justify each section," and why not SPARK or BOUND?
Tap to flip
ANSWER
ORDER, for ranking a document's sections by what's hardest to undo if skipped. SPARK designs one interface decision, and this question asks about a whole document's order. BOUND sizes a number, and there's no estimate to build up here.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Anjali Reddy, product manager for Pulseboard's First Dashboard wizard, nine months into owning it, with a background in customer support before she moved into product.
3 · THE HABIT
What habit led Anjali to write the wizard's PRD sections in the wrong order?
Tap to flip
ANSWER
Writing whatever was easiest to picture first, the problem statement and the wizard's questions, and leaving success metrics and guardrails as one-line placeholders, because they were harder to write and nothing was forcing the point yet.
4 · THE MISTAKE
What's the ordering mistake this whole story turns on?
Tap to flip
ANSWER
Treating "easy to write" as the same thing as "safe to write last." Completion rate was easy and got written first. The real definition of success, did the guess turn out true, was hard and got skipped, and that's exactly the one that was hardest to catch after launch.
5 · THE OLD DECISION
What decision would you take back, and why did it make sense at the time?
Tap to flip
ANSWER
Writing the success-metrics section as a single line, "completion rate above 80 percent," with twenty minutes left before a launch review. It made sense because completion rate was the obvious cheap number, and the two prior days had gone to parts of the wizard people would actually see.
6 · THE NUMBER
About ___ of roughly 640 new signups in one quarter had a dashboard silently wired to the wrong currency or leftover test data, while completion rate stayed above 80 percent the whole time.
Tap to flip
ANSWER
109, about 17 percent, roughly 1 in 6. Completion rate never dipped, because it only checked whether the wizard finished, never whether what it built was true.
7 · THE REPLAY
Same one-afternoon time box, sections reordered: what changes?
Tap to flip
ANSWER
Anjali writes success metrics and guardrails first. The next quarter's roughly 600 signups drop to about 2 percent with a wiring issue, and the guardrail catches those itself, before any customer notices.
8 · THE TRANSFER
Section 4 runs ORDER again on a different product. Which one, and what plays the role of the success-metrics section there?
Tap to flip
ANSWER
A county building department's AI permit wizard. The equivalent is deciding upfront what "the wizard got it right" means: an approved permit that survives inspection, not just an application that got submitted.
Check yourself Score: 0 / 0
True or false
1. True or false: since Pulseboard's original wizard held a completion rate above 80 percent for months, the success-metrics section of its PRD had already done its job. Say why.
True
False
Show hint
Ask what "completion" actually measures, versus what a customer needed measured.
Show answer
False. Completion rate only checked whether the wizard finished its steps, never whether what it built was correct. It stayed healthy the entire time about 1 in 6 dashboards were silently wired to the wrong data.
Multiple choice
2. If you only had time to write two sections of Anjali's PRD before code starts, which two does this answer say protect the outcome most?
A. Problem statement and rollout plan
B. Success metrics and scope
C. UX copy and problem statement
D. Rollout plan and UX copy
Show hint
One defines what "right" means, the other decides what the AI is even allowed to guess.
Show answer
B. Success metrics catches a wrong guess before a real customer lives through it. Scope has to be settled before any other section can be written honestly.
Fill in the blank
3. Out of about 640 new signups in the quarter nobody was checking, roughly ______ had a dashboard silently wired to the wrong data source.
Show hint
It's the number an ops analyst found during a routine account-health pass.
Show answer
109, about 17 percent. That's roughly 1 in 6 new signups that quarter, and none of it showed up in the completion-rate chart Anjali checked every Monday.
Short answer
4. Would writing the AI behavior spec, the exact wizard questions and worked examples, before the scope section have caught the miswired dashboards sooner? Say why or why not.
Show hint
Ask what the behavior spec needs to already know before it can describe real examples.
Show answer
Model answer: "Not reliably. The behavior spec can only describe right and wrong output once you've decided which guesses the AI is even allowed to make alone. Write it before scope, and you're describing behavior for a job that isn't actually settled yet."
Short answer, apply it yourself
5. Pick an AI feature you use or are building. Which section of its PRD would be hardest to go back and fix after real users had already gone through it?
Show hint
Look for the section that decides whether a mistake is caught in a review or lived through by a real person first.
Show answer
Model answer: "A recipe app's AI grocery-list builder. The hardest section to fix after the fact is the guardrail for when it silently drops an ingredient someone's allergic to, since by the time anyone notices, they've already shopped and cooked with the wrong list."
Short answer, the number question
6. If the miswired-dashboard rate had been 3 percent instead of 17 percent, would the ranked order of PRD sections still put success metrics first? Say what changes and what doesn't.
Show hint
Reversibility is about what happens once a mistake is caught, not about how big the mistake was.
Show answer
Model answer: "The order stays the same. Even a small silent failure rate is just as invisible to a metric that only checks completion, and it's still the hardest thing to undo once a real customer's first ten minutes already happened. What changes is urgency, not order: a smaller number might not justify pulling the whole team off other work, but the section still gets written first, not last."
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
