The direct answer
For every failure mode, write down what the affected person will actually hear or see when it happens, right next to the internal metric, not instead of it. "Accuracy may drop on complex cases" tells an engineer something. It tells a reader nothing they could ever catch themselves. Then give that person a real door to say "this was wrong," one that reaches someone who knows what the bug sounds like, and split your accuracy numbers by the kind of case before you trust the average.
Do this, in order
Write the user-visible signal for every failure mode, next to its internal metric.Why: without it, "may be inaccurate" and "definitely inaccurate" read the same on the page, and nobody can build a test for what the failure actually sounds like.
Split the accuracy number by the kind of case before you write the risk down.Why: an overall average can sit comfortably on top of one badly failing slice for months without moving.
Build a door the affected person can actually use to say something was wrong.Why: right now there's nothing to push back on, because there's nothing telling them a failure is even possible.
Route anything that mentions the feature by name to the team that knows what a bug in it looks like.Why: a report that lands in a general queue with no one who recognizes it is the same as no report at all.
Add the detection method itself as a line in the PRD, not a promise for later.Why: a failure mode with no way to catch it in production is a sentence on a slide, not a spec.
Leave the low-stakes cases at the default bar.Why: not every mismatch costs the same. Spend the review budget where a wrong output actually erases real information.
How to answer this, stage by stage
Eight moves. The middle four are where the actual writing happens; the rest is scoping it and closing it out.
1
Pin it to one screen before you write a single failure mode
Say it like this
"Say we've got a news site that uses AI to write the alt text for every photo it publishes, so a screen reader can tell someone what's in the picture. Before I write the failure modes section, I want one real screen in front of me, the article page a photo sits on, and how a reader's screen reader actually gets to it."
Why this works
Grounds an abstract PRD requirement in one real feature before you name any framework, so you're never reciting a definition.
2
Say your structure out loud
Say it like this
"I'd use GUARD here, because a failure modes section is a risk document, not a feature list. Who reads it and who lives inside a failure, where the harm lands unevenly, who can't tell it happened, what I'd actually change, and how I'd catch it once it's live."
Why this works
Two seconds that prove you have a plan before the interviewer starts wondering if this is going to be a grab bag of edge cases.
3
Name who reads this section, and who never will
Say it like this
"Two groups. The people who read this document, engineering and product, and decide what counts as documented. And the reader on the other end, someone who never sees the PRD, never sees the photo, and only ever hears one sentence."
Why this works
This is GUARD's G step. It sets up exactly why the rest of the section matters, before you've written a single risk.
4
Write the failure mode as a sound, not a score
Say it like this
"The lazy version of this line says 'alt text may occasionally be inaccurate on complex images.' True, and useless. I'd write it as: on a chart or a map, the model tends to describe the shape instead of the numbers, so it reads like 'a bar chart with several bars,' not 'the challenger leads sixty two to thirty eight.' That's a sentence someone can actually test for."
Why this works
This is the whole answer to the question. A failure mode has to name the words the person will hear, not just a percentage behind the scenes.
5
Say where the harm doesn't land evenly
Say it like this
"Split the accuracy number by what's actually in the photo before you write the risk. Plain photos matched a sighted description ninety six percent of the time. Photos with a map, a chart, or a screenshot in them, the ones actually carrying the news, matched fifty one percent. The average sat at eighty nine and hid both numbers."
Why this works
This is U. It turns "might be uneven" into a number the interviewer can check, instead of a hedge.
6
Say who can't tell it happened, and give them a door
Say it like this
"A reader can't check a description against a photo she can't see. So this is a silent failure by default, unless we give her a real way to say 'that didn't sound right,' one that reaches someone who actually knows what an alt text bug looks like."
Why this works
This is A, GUARD's hardest step, and the one most answers skip. It's what turns a QA note into a real product decision.
7
Write the detect line right next to the risk line
Say it like this
"Every week, I'd pull a sample of AI descriptions, split by photo type, and re-check them against a person, blind to the model's own confidence score. And anything that mentions 'description' or 'caption' in a reader's message gets routed straight to that team, not the general queue."
Why this works
This is D. A risk with no way to catch it in production stays a sentence in a slide deck.
8
Say what you'd leave off the list, and close
Say it like this
"I wouldn't spend this budget on a stock photo or a staff headshot. Getting one a little off costs nothing, there's no story information in it to lose. So: name the sound of the failure, split the number by what's actually in the photo, and give the reader a door that leads somewhere. That's what the section is actually for."
Why this works
Shows judgment instead of blanket caution, and ends on the one line the interviewer will remember.
Let's learn
The description is one sentence. It plays in a synthetic voice, in the second before a screen reader moves on to the next line of the page.
Say a news site builds a tool that looks at every photo it publishes and writes the sentence a screen reader will say instead of it, so someone who can't see the picture still knows what's in it.
Knowledge spark: what is alt text
A short written description attached to a picture, so a screen reader can read it out loud. It's the only way someone who can't see the photo gets any of the information sitting inside it.
Before the tool, a small photo desk wrote that sentence by hand. There wasn't time to do it for every picture, so they covered the ones that mattered most, about 240 of the 1,200 photos the site ran in an average week. The rest published with nothing, or with whatever the system defaulted to: the word "Photo."
Now the AI writes a description for all 1,200, in under a second each. Every photo gets a real sentence instead of one word or nothing.
Here's the part that matters. The extra sentences are not the problem. The problem is what happens the day one of those sentences is wrong, because nobody who hears it can tell.
A wrong description doesn't sound wrong. It sounds like a photo, described.
At its worst, this ends up behind the product that was never built at all. A reader who gets no description knows she's missing something. A reader who gets a full, confident, wrong sentence thinks she has the story, and doesn't.
The decision I would take back
The failure modes section said: alt text may occasionally be inaccurate, particularly on complex images. That sentence is true. It's also useless, because it never says what a wrong description sounds like, so nobody built a way to test for it, catch it, or hear about it when it happened.
What I would leave alone. Not every photo needs this. A stock photo behind a lifestyle piece, a staff headshot, a generic shot of a courthouse. Getting those a little off costs nothing, because there's no real story information sitting inside them to lose.
The lesson. I used to think a failure modes section was a place to admit a model isn't perfect. It isn't. It's a place to say exactly what imperfect will sound like to the one person who can't check it against the picture, and what happens right after she hears it.
Now here is the same thing as a story
Read the short version above if you want it fast. Read this one when you want to feel why the fix matters, not just know what it is.
The 7:40 bus into town is when Deepa Krishnan catches up on the news. She's been listening to the Ridgeline Courier every weekday morning for four years, one earbud in, phone in her coat pocket, the screen reader running at a speed most sighted people can't follow at all.
Levon Sargsyan has run the accessibility side of the Courier's product for three years. He built the alt text tool himself, mostly, with a small team, after years of the photo desk covering maybe one photo in five.
For the first eight months, it was honestly the best thing the product team had shipped in years. Every photo got a real sentence. Levon used to sit down most Fridays with his own headphones and listen to a dozen of that week's descriptions against the actual photos, just to hear how they sounded. They always sounded fine.
By month three he was down to one Friday a month. By month five it was whenever he remembered. By month seven he genuinely couldn't recall the last time he'd listened to one.
Then, in a planning meeting about adding alt text to video thumbnails too, a new engineer on the eval team asked a plain question: "Okay, but if one of these is wrong, how would we actually know?" Levon opened his mouth to answer and realized he didn't have one. Just the number. Eighty nine percent.
That question sent him digging. About two weeks in, he found an email. It had sat for nineteen days in the general contact-us inbox, one of about four hundred that week, filed under nothing in particular. It read: "Something about the picture description on the election story doesn't make sense, can someone check?" It was from Deepa.
On election night, the Courier had run a district map, colored by which way each precinct had gone, next to a headline that just said the town had flipped. A sighted reader took one look and had the whole story. Deepa's screen reader read her one sentence: "a map with several colored regions." No count. No direction. No winner. She sat on the bus the next morning not knowing, still, which way her own town had gone, and she had no way of knowing the sentence she'd heard was even missing anything. It sounded finished.
Same photo, same outcome, only one of them has a hand on anything
We didn't lose accuracy that night. We lost the one thing that would have told Deepa something was missing: a reason to doubt it.
Levon pulled that week's sample, split by what was actually in the photo instead of averaged across all of them. Plain photos, portraits, generic action shots, scenery, matched what a sighted person would say ninety six percent of the time. Photos carrying a map, a chart, a screenshot, or a sign, the ones actually carrying the news, matched fifty one percent. The eighty nine percent on the sprint deck had been sitting on top of both numbers the whole time.
Levon was in the room, over a year earlier, when the failure modes section got written. Someone typed "alt text may occasionally be inaccurate, particularly on complex images," and everyone nodded, because it was true, and because the template already had a line shaped like that for every AI feature they'd ever shipped. Nobody asked what "inaccurate" would actually sound like coming out of a phone speaker on a bus.
I would take that back. Not the sentence exactly. What we let the sentence get away with. I'd have it say what a low confidence description actually sounds like: a phrase with no numbers and no direction in it, on a photo that's supposed to carry both. Write that down, and someone on the eval team can go test for that specific, checkable thing, instead of trusting a percentage that had already forgotten it had a bad slice inside it.
And the contact form. Deepa did the one thing we ask people to do. She wrote in. It sat unrouted for nineteen days because nothing about her sentence told anyone in that inbox it was an alt text bug at all, just one more message in a queue built for billing questions and typos.
Run that election night again, with the fix in place. The failure modes section already told the eval team what a bad map description sounds like, so a sample of that night's maps gets checked before six a.m., not nineteen days later. And the word "description" in a reader's message gets routed straight to Levon's team, same day. Deepa still might hear a bad sentence sometimes. But she hears about the fix within a day, not three weeks, and by the second election night the map reads: "a district map, most of downtown shifted to the challenger's color, sixty two percent to thirty eight."
The thing I'd tell my own team, a year back: we wrote down that the model could be wrong. We never once wrote down what wrong would sound like, and that's the only version of that sentence that was ever going to be useful.
The five letters, aimed at a paragraph instead of a launch
This is a risk question, so the framework is GUARD. A failure modes section is a risk decision wearing a template's clothes, which is exactly why "alt text may occasionally be inaccurate" gets typed into a PRD without anyone asking what that would sound like out loud.
G, groups. Two groups, and only one of them ever sees this document. Levon's team reads the failure modes section and decides what counts as documented. Readers like Deepa never see it. They get one sentence, read out loud, and that's the entire interface they have to the model's mistakes.
U, unequal. The harm doesn't land evenly across photos. Split the real match rate by what's actually in the picture and the gap shows up in the numbers, not just in Deepa's one bus ride.
Match rate with what a sighted reader would say, by photo type
A weekly sample, checked blind against a person, not the AI's own confidence score.
Plain photos, portraits, scenery, generic action
96%
Maps, charts, screenshots, or signs
51%
Almost double the gap, and the overall figure never showed it. It sat near eighty nine percent for eight straight months, because it was always measured across every photo type at once.
A, ability to contest. Deepa can't check a description against a photo she can't see. When she did the one thing available to her, wrote in, it sat unrouted for nineteen days in a queue nobody had built to recognize an alt text complaint.
The step that should sit fourth in this list and doesn't
R, reduce. Two build items, not a policy. Every failure mode names its user-visible signal, the exact shape of what a bad output sounds like, right next to its internal number. And any message mentioning "description," "alt text," or "caption" routes straight to the accessibility team's queue, not the general one.
D, detect. Every week, sample AI descriptions by photo type and re-check them against a person, blind to the model's own confidence score, watching the gap between plain and text-heavy photos specifically, not the average. That's the number that would have caught this before an election night, not after one.
Where this answer would fail
If the fix here is a style guide for prompt writing, or a review committee, none of it counts. Naming the exact sound of a bad description, and routing three words in an inbox to the right queue, are both build tickets. Somebody can ship them this sprint, and you can check whether they did.
And if you want to be sure it really works, try it somewhere else
A city permit office uses AI to read building permit applications and draft the rejection letter when something's missing. Different building entirely, same five letters, same trap.
G, groups. The reviewers who read the failure modes section and can see every past rejection, and the homeowner or small contractor whose application gets the letter and nothing else.
U, unequal. Applications submitted as hand-drawn sketches or in a language other than English get vaguer, more generic rejection reasons than clean digital submissions, and the misses cluster on the applicants least likely to already know how to fight one.
A, ability to contest. An applicant reading "does not meet code" can't tell if that's the real reason or the model reaching for the nearest boilerplate line, and resubmitting blind costs another filing fee.
R, reduce. Every failure mode names the actual boilerplate pattern to watch for, a rejection reason with no code section attached, and the appeal path gets a plain phone line, not just a resubmission form.
D, detect. Track the overturn rate on appealed rejections, split by submission format, hand-drawn, translated, or digital, watching for one format's overturn rate spiking against the others, not the office-wide average.
Swap the trigger and it still runs
- Speed: the tool rolls out to five more city departments in a month, and the one generic failure line everyone copy-pasted into their own PRD ships five times over, unedited.
- Cost: the city cuts the reviewers who used to double-check the roughest ten percent of letters by hand, because the accuracy number never told anyone which ten percent that was.
- The model gets better: overall match on rejection reasons climbs to 95 percent, and that's exactly when nobody proposes splitting the number by format anymore, because the deck already looks finished.
Where people run it wrong
- Writing "may occasionally be wrong" once, in one line, and treating that as covering every way it could be wrong.
- Testing the fix against the overall accuracy number instead of the one slice that's actually failing.
- Building an appeal path that exists on paper but isn't routed anywhere a person actually reads it that week.
If you're asked this cold
Ask who a failure modes section actually gets written for. If the honest answer is "whoever signs off on the PRD," not the person on the other end of the output, say that out loud, then fix it live, by naming the one sentence a reader would actually hear.
Flashcards (click a card to flip it)
1 · THE FRAMEWORK
Which framework fits documenting the failure modes section of an AI PRD, and why?
Tap to flip
ANSWER
GUARD, for risk, safety and fairness. The real question isn't what could go wrong technically, it's who reads the list and who lives inside a failure, exactly what GUARD is built to find.
2 · THE TWO GROUPS
Name the two groups this answer names, and which one can see the PRD.
Tap to flip
ANSWER
Levon's team, who write and read the failure modes section, and readers like Deepa Krishnan, who never see the document and only ever hear one sentence.
3 · THE HABIT
What did Levon quietly stop doing, and over how long?
Tap to flip
ANSWER
Listening back to a sample of AI descriptions himself with headphones on. He went from every Friday, to once a month by month three, to not at all by month seven.
4 · THE JUMP
What coverage jump made this failure possible in the first place?
Tap to flip
ANSWER
Before AI, the photo desk hand-wrote alt text for about 20 percent of the week's photos, the ones judged most important. After AI, every photo gets a description, all 1,200 a week. Full coverage also meant a bad sentence could now reach every reader, not just the missed 80 percent.
5 · THE OLD DECISION
What old decision does this answer take back, and why did it make sense at the time?
Tap to flip
ANSWER
The failure modes section said "alt text may occasionally be inaccurate, particularly on complex images," with no user-visible signal attached. It made sense because every AI feature's PRD already had a line shaped like that, and nobody had needed more from it before.
6 · THE NUMBER
Fill in: plain photos matched a sighted description ______ percent of the time. Photos with a map, chart, or screenshot matched ______ percent.
Tap to flip
ANSWER
Ninety six percent, dropping to fifty one percent. The overall average never showed this split, it sat near eighty nine percent for eight months.
7 · THE REPLAY
Same election night, new PRD. What changes, and by when?
Tap to flip
ANSWER
The failure mode already names what a bad map description sounds like, so that night's maps get checked before six a.m. And any message mentioning "description" routes straight to Levon's team, so Deepa hears about a fix in a day, not nineteen.
8 · TRANSFER
Section four runs GUARD again on a different product. Which one, and what does the reduce step become?
Tap to flip
ANSWER
A city permit office's AI rejection-letter tool. Reduce: name the actual boilerplate pattern to watch for in a bad rejection reason, and give applicants a plain phone line to appeal, not just a resubmission form.
Check yourself Score: 0 / 0
Short answer
1. Why wouldn't just telling the team to "write better prompts" or "watch the confidence score more closely" fix the risk here?
Show hint
Ask what the reader can actually detect, not what the internal number says.
Show answer
Model answer: "Because the risk isn't accuracy, it's that a wrong description sounds exactly like a right one to someone who can't see the photo. A better confidence score still gets read aloud the same way if nobody's told the reader what a shaky one sounds like. The fix has to change what she hears, not just what engineering sees on a dashboard."
Multiple choice
2. A teammate says the alt text feature is fine because "if it's wrong, someone will report it." What's the actual flaw in that reasoning?
- A. Reporting a bug always takes too long to matter.
- B. A reader can't tell a description is wrong without seeing the photo, so there's usually nothing for her to report.
- C. Bug reports should go to the photo desk, not engineering.
- D. The model's accuracy is already too low to fix with reports.
Show hint
Think about what Deepa would need to already know before she could report anything.
Show answer
B. A, C, and D all worry about process or accuracy. The real flaw is detection: you can't report a mismatch you have no way to notice, and a description that sounds complete gives no reason to doubt it.
True or false
3. True or false: because the AI's overall match rate stayed near eighty nine percent the whole time, the failure modes section didn't need to call out any one kind of photo by name.
Show hint
Ask what an average across every photo type can, and can't, show you.
Show answer
False. A number averaged across plain and text-heavy photos alike will look stable even while one slice of it is failing badly. Stability on an unsplit number is exactly what a hidden gap looks like from the outside.
Fill in the blank
4. On plain photos, the AI's description matched what a sighted reader would say ______ percent of the time. On photos with a map, chart, or screenshot, that dropped to ______ percent.
Show hint
It's the pair of numbers behind stage 5 of the walkthrough.
Show answer
Ninety six percent, dropping to fifty one percent. Same model, same week, split by what was actually in the photo instead of averaged across all of it. The gap between the two is the whole story.
Short answer
5. Name a kind of photo on this same site you'd leave off the extra review budget, and say why that one's safe to leave alone.
Show hint
Look for a photo that carries no unique story information to begin with.
Show answer
Model answer: "A staff headshot or a generic stock photo behind a lifestyle piece. Getting the exact wording wrong there costs the reader nothing, because there's no real story detail sitting inside the photo to miss in the first place."
Short answer, apply it yourself
6. Pick an AI feature you've used yourself. What would its failure modes section need to say the user actually hears or sees when it fails, not just an internal accuracy number?
Show hint
Picture the exact moment it goes wrong, and what you personally would notice, or wouldn't.
Show answer
Model answer: "Auto-generated captions on a video call. The failure mode shouldn't just say 'transcription accuracy may drop on cross-talk.' It should say a wrong caption reads as a complete, confident sentence attributed to the wrong speaker, so a listener who wasn't watching closely has no reason to doubt it, and needs a way to flag it after the fact."
