ConceptFoundationalModel Fluency & the AI PM Role / AI PM vs traditional PM vs technical PM / #18

Why do AI PMs spend disproportionate time on failure cases relative to happy paths?

TRACE · a churn-model roadmap that quietly turned into a repair crew, at Duskvale Wireless

Ebbline is Duskvale Wireless's early-warning churn score: every night it ranks each subscriber's risk of cancelling or porting their number out inside the next 30 days, and the riskiest accounts land at the top of the retention desk's call queue. Amaranth Stanhurst owns the product. Wynifred Yardley runs the desk that calls off the queue. Fourteen weeks after launch, a team that had shipped new features every single week for a month had shipped almost none since week four, and nobody could point to the day that changed.

The direct answer
A model's happy path is one behavior to get right. Its ways of being wrong are not one thing, they're many, and each one needs its own detection before it reaches a customer. So scope failure handling as its own tracked workstream from day one, one line per failure type, not a single "exceptions" epic sized like a rounding error. A confidently wrong score costs more trust than an obviously broken one, which is why this work becomes the majority of the build, not the tail.
Do this, in order
  1. Scope failure handling as its own tracked workstream from day one, one line per failure type, not one "exceptions" epic.Why: a single lumped bucket hides that failure handling, not the happy path, becomes most of the work.
  2. Track eng and design hours by failure category, not a "misc" bucket.Why: the recut is the one move that shows a slice already cratering, weeks before a launch date slips.
  3. Compare the ratio against a recent non-AI feature's own exception hours before blaming the team's planning.Why: rules out sloppy scoping and shows whether the imbalance is structural to the AI feature.
  4. Give each failure mode its own detection before a wrong score reaches an agent.Why: a confidently wrong score burns more trust than one that's obviously broken.
  5. Protect the top of the queue first, since that's where trust breaks.Why: failure cases are where trust gets lost, and losing it costs more than earning it did.
  6. Leave loudly-broken, cheap failures on the normal bug queue.Why: a screen that visibly errors doesn't need its own detection system, only the quiet, confident, or expensive misses do.

How to answer this, stage by stage

Nobody is grading whether you can say "AI features need edge-case handling." They're grading whether you can name the actual reason the ratio flips, and the one check that proves it isn't just this team being bad at planning.

1
Ground it in one real product, one real team
Say it like this
"Let's make this concrete. Ebbline is Duskvale Wireless's churn score, it ranks every subscriber's risk of cancelling in the next 30 days, and it feeds the retention desk's call queue. Amaranth Stanhurst owns it. Fourteen weeks after launch, her team was spending three-quarters of its time patching the score, not building it."
Why this works
A named product with a real number is something an interviewer can follow. "Failure handling takes longer than planned" isn't a story yet.
2
Say your structure out loud
Say it like this
"I'll run this as TRACE. Timeline, then recut the hours by failure type instead of one bucket, rule out poor planning, name the real causes, then give the one check that proves it."
Why this works
Two seconds of structure tells the interviewer you have a method, not a pile of guesses arriving as you think of them.
3
Reframe the question before naming a single fact
Say it like this
"The real question isn't why the team is bad at scoping. It's whether one clean scoring behavior, and the many ways that behavior can be wrong, were ever the same size job. They're not, and the roadmap priced them like they were."
Why this works
This line is the whole answer in miniature. Skip it, and the rest sounds like a complaint about a slow quarter instead of a real pattern.
4
Lay out the timeline
Say it like this
"Week one, the roadmap sets aside two of fourteen weeks for exceptions, one Jira epic, called Model Exceptions and Cleanup. Week five, the first real failure lands, a stale billing flag. Week nine, Wynifred tells me agents have started skipping the queue. Week twelve, I pull the hours for my own review slide and find we've shipped almost nothing new since week four."
Why this works
Naming exactly when the ordinary weeks stop and the patching weeks start keeps this from sounding like a sudden, unexplainable slide.
5
Recut the hours by failure type, not by week
Say it like this
"Split by category instead of by sprint. Stale-data flags, fifteen percent of all hours. A segment the model never trained on, twenty-four percent. Confidently wrong scores, twenty percent. Real churn the model missed completely, fifteen percent. That's seventy-four percent of the whole team's time, and 'misc' never would have shown it."
Why this works
This is the move most candidates skip. A single bucket hides exactly the split that explains everything.
6
Rule out the boring explanation first
Say it like this
"Before I blame the model, I check the ordinary suspects. Headcount held steady. No new process slowed anyone down. And a bill-pay redesign that shipped the same quarter, no model in it at all, kept its own exception work at nine percent, exactly where it was planned. Only Ebbline's number kept climbing."
Why this works
Naming this out loud shows you checked the plain explanation before reaching for the interesting one.
7
Name the three real causes
Say it like this
"Three things, all real, all at once. One, a clean score is one behavior, but wrong is a dozen different doors, stale data, a new segment, a combination the model never saw, and each needs its own catch. Two, a score that says ninety-four with total confidence, and is wrong, costs more than a screen that visibly breaks, because the agent acts on it. Three, trust doesn't average. Three bad calls in a row and an agent stops trusting the whole queue, even though most of it was right."
Why this works
Three specific, checkable reasons beat one vague line about "AI being unpredictable."
8
Give the evidence test, and close on the one line
Say it like this
"The check that confirms it: track eng and design hours by category for any AI feature, against the same hours for the last non-AI feature the team shipped. If the AI feature's failure share stays high release after release while the non-AI one stays low, that's structural, not sloppy planning. So: happy paths are one behavior, failure is many, and a confidently wrong answer costs more than a broken one. That's why this work is never the small tail we price it as."
Why this works
Leaves the interviewer with a concrete, repeatable check, not just a warning to "expect some edge cases."

Let's learn

Before Duskvale's retention desk had a churn score at all, the team called back about one in five people who'd already said the word cancel.

Ebbline is Duskvale's early-warning score. Every night it looks at each subscriber's usage, billing, and support history, and gives them a number from 0 to 100 for how likely they are to cancel or port their number out inside the next 30 days.

Knowledge spark: what does a score of 70 actually mean? Ebbline flags an account once its 30-day risk clears 70 out of 100, a cut-off tuned against 18 months of real cancellations. It isn't a promise the model is right at that line, it's a bar picked because, on past data, most accounts above it really did leave.

Before Ebbline, the retention desk worked a "contract-expiry list," reactive, mostly customers near the end of a contract, or people who'd already called in to cancel. Win-back rate on that list: 19 percent. Most calls landed too late to matter.

With Ebbline, agents work a sorted queue instead, riskiest accounts first, often days before a customer has even decided to leave. In the first six weeks, win-back rate on correctly flagged accounts hit 44 percent, more than double the old number.

Hand sketched horizontal timeline titled Duskvale's 14-week Ebbline build. Five milestones. Roadmap set, caption 2 of 14 weeks budgeted for exceptions. First stale-flag ticket, caption week 5, billing feed lag. Agents skip the queue, caption week 9, three bad calls in a row. QBR, this milestone emphasized in teal, caption week 12, 74 percent of hours on failures. Still holding, caption week 14, failure share near 71 percent.
The roadmap priced two of fourteen weeks for exceptions. Nobody re-priced it until the QBR slide came up nearly empty.

Here's the turn. A few wrong flags were never the real problem. The real problem was what happened to the roadmap once those wrong flags needed fixing: the team stopped building anything new and spent almost the whole build on patches.

Share of eng and design hours spent on failure handling, week 1 to week 14
100% 50% 0% Bill-pay redesign, same window: 9% Wk5: first stale flag Wk12: QBR, 74% Wk1 Wk5 Wk9 Wk12 Wk14
Ebbline, failure-handling share of hoursNon-AI feature, same-quarter reference
Ebbline's line never comes back down toward the reference line. The non-AI feature's own exception work held flat near 9 percent the entire quarter.
We didn't lose a handful of wrong flags. We lost a quarter's worth of roadmap, one unrelated failure at a time.

Split by category instead of by week, at week twelve, the picture gets sharper. Stale-data flags, a segment the model never trained on, confidently wrong scores, and real churn missed outright, none of them the same problem, all of them eating the same calendar.

Where the hours actually went, week 12
30% 15% 0% 26% Happy path 15% Stale data 24% Untrained segment 20% Confident wrong 15% Silent misses
Happy path (new features)Stale dataUntrained segmentConfidently wrongSilent misses
Four unrelated failure types, not one "misc" bucket, add up to 74 percent of the week. New feature work is the smallest slice on the chart.
Hand sketched metaphor scene titled One door in. Many doors to watch. Left panel, a gauge icon labeled The Happy Path, caption one score, one behavior to get right. Right panel, a question mark icon on a red square labeled The Failure Modes, caption stale data, new segments, silent misses, each its own door.
One clean scoring behavior on the left. A hallway of unrelated failure types on the right, priced like they were one door.
The choice I would take back We scoped all failure handling as one epic, Model Exceptions and Cleanup, sized at two of fourteen weeks. That made sense when we assumed the score's wrong answers would be rare and similar to each other. It stopped making sense the moment the wrong answers turned out to be four separate, unrelated problems, each needing its own fix.

What I would leave alone: the in-app "couldn't load this account's usage" error screen never needed a special detection system. It fails loudly, the agent sees it, skips that account, and moves on. Nothing hidden about it, nothing confident about it, so nothing about it needed the same care as the quiet failures.

The lesson: a team doesn't need to be bad at planning for this to happen. It just needs one clean behavior to ship next to several different, unrelated ways of being wrong, priced as if they were one small thing instead of four separate jobs.

Now here is the same thing as a story

The short version above is what you actually say in the room. Read this one when you want to feel exactly how a full calendar can hide a hallway of failures, and why nobody named it sooner.

Amaranth can read a churn dashboard the way most people read a weather forecast, not for the number on the screen, but for what it's about to do to somebody's Tuesday. She'd run product on three features at Duskvale before Ebbline, and she was good at the part everyone expects: writing the spec, running the pilot, getting a skeptical team to actually use the thing.

Ebbline shipped in March, after a fourteen-week build. The roadmap doc, agreed months earlier, gave the core loop, the score, the queue, the call screen, twelve of those fourteen weeks. It gave "Model Exceptions and Cleanup" two weeks, a single Jira epic, sized the way you'd size a rounding error.

For the first month, that pricing looked exactly right. Wynifred's team stopped working the old contract-expiry list and started working Ebbline's queue top down instead, riskiest accounts first. Win rate on correctly flagged accounts hit 44 percent by week six, more than double the old list's 19. Amaranth's Friday updates were full of new things: a save-offer button, a call-outcome log, a weekly digest for her VP.

Then, without one single afternoon she could point to, the updates stopped being about new things.

Hand sketched flow diagram titled Wynifred's desk, week 1 to week 9. Four sequential boxes connected by arrows. Calls the reactive list. Trusts the queue. Three bad flags, this step outlined in red as the turning point. Re-checks by hand.
No single bad call did it. Three of them, close together, and the desk quietly went back to the old way.

Week five: the first stale-flag ticket, an account whose overdue balance had cleared three days earlier, still showing 91 risk because the nightly billing feed hadn't caught up. A one-day fix. Nobody worried.

Week seven: a second, different kind of ticket. Five-line business accounts kept scoring strangely, high one week, near zero the next, because Ebbline had trained almost entirely on single-line consumer plans, and a shared business bill didn't look like anything in its training data. Also not urgent, on its own.

Week nine, Wynifred mentioned something in a hallway, not a report, not a ticket. Three of her best agents had quietly stopped working the top of the queue. One had called a nineteen-year customer with a save offer, based on a 94 score, only to learn the woman was renewing early for a new phone. The agent didn't file a complaint. She just started opening every flagged account's history herself before calling, the way she used to.

Amaranth didn't flip anything that week either. There wasn't a moment for that. There was just, over about six weeks, a team that had quietly become a repair crew for a product it thought it had already built.

The moment that actually cracked it open was ordinary: her quarterly review slide. Amaranth went to list what Ebbline had shipped since week four, and the list was close to empty. Almost everything since then carried the same three-letter epic code. MEC. Model Exceptions and Cleanup.

Hand sketched numbered icon list titled What we ruled out before blaming the model. Four rows. One, headcount held steady, nobody left the team. Two, no new process or tool slowed the sprint. Three, a same-quarter, non-AI feature kept its planned 9 percent exception share. Four, this row in red, only Ebbline's failure share kept climbing past week 8.
None of the ordinary explanations moved. That's what made the real one worth digging for.

She pulled the hours that night. Nobody had left the team. No new process had slowed anyone down. A bill-pay redesign the design team had shipped that same quarter, no model anywhere in it, had kept its own post-launch exception work at nine percent of its build hours, right where it was planned. Only Ebbline's number had kept climbing, past half the team's time by week eight, past seventy percent by week twelve.

Split by type, not by week, it stopped looking like bad luck and started looking like four separate, unrelated jobs that had all been priced as one. Stale billing flags. A segment the model had never trained on. Scores that were wrong and completely sure of it. And underneath all of that, quietly, the thing nobody had been chasing: real churn the model missed outright, because "stopped autopay after two billing disputes" wasn't a pattern in its training data. Only slow usage decline was.

She thought back to the meeting where MEC got its two weeks. Someone had asked, reasonably, whether exception handling needed its own line item, or whether it could ride along inside the main build. Two weeks felt generous at the time. Nobody could name more than one kind of thing that might go wrong. Nobody was careless to ask it that way. There just wasn't yet a reason to think "wrong" would turn out to be four different things wearing one name.

What Amaranth would tell that room, if she could: the epic wasn't undersized because anyone was lazy. It was undersized because a happy path and its failure modes look like the same kind of scope right up until you actually count the doors.

The next feature Duskvale shipped, a usage-spike alert for the network team, priced four named failure modes on day one instead of one shared bucket. By its own week twelve, failure-handling hours sat at 31 percent, not 74, and every one of the four modes had an owner before a single customer ever saw a flag.

The thing Amaranth would want to tell her earlier self isn't "plan for more edge cases." It's that a clean score is one door. Its failures are a hallway of them, and she priced a hallway like it was a door.

TRACE: the method for finding out why a clean score became four unrelated jobs

Not a way to catch a bad score. TRACE is what you run once the team already looks busy and productive, because that's exactly how a hallway of failure modes hides inside a full calendar.

TTimeline. When the shift actually started, and what the roadmap assumed.
Roadmap: two of fourteen weeks priced for exceptions, treated as one epic, because the team assumed the happy path was "the product" and failure handling was a small tail. Week five, the first real failure lands. Week nine, agents quietly start working around the queue. Week twelve, the review slide comes up nearly empty.
Puts a real clock on the six weeks between "the pattern started" and "someone actually named it."
RRecut. Slice hours by failure type, not by week.
Stale-data flags: 15 percent of all hours. A segment never in training: 24 percent. Confidently wrong scores: 20 percent. Real churn missed outright: 15 percent. Seventy-four percent total, and "misc" would have hidden every point of it.
The strongest move here: a single "exceptions" bucket would have looked like a rounding error surviving fine, right up until someone finally opened it.
AAssume nothing. Rule out poor scoping before calling it structural.
Headcount held steady. No new process slowed the sprint. A same-quarter, non-AI bill-pay redesign kept its own exception work at nine percent, exactly as planned. Only Ebbline's share kept climbing.
This is where a weak answer jumps straight to "AI is just hard." Checking a real non-AI feature first is what makes the structural claim credible instead of convenient.
Hand sketched labeled parts diagram titled Why failure ate the roadmap. A gauge icon at the center labeled The tail became the map, with three callouts. One behavior, many doors. Confident wrong beats broken. Trust breaks, it doesn't average.
Three separate reasons, all real at once, none of them a story about a careless team.
CCause candidates. Three real reasons, not one complaint.
One: a clean score is one behavior, but wrong is many doors, stale data, an untrained segment, a combination never seen, each needing its own catch. Two: a score that's confidently wrong costs more than one that's visibly broken, because an agent acts on the first and skips the second. Three: trust doesn't average, three bad calls sink the whole queue even though most of it was right.
Three specific, checkable habits beat one line about "AI work being unpredictable."
Hand sketched comparison diagram titled Broken is cheap. Confident is expensive. Left panel, a green box icon labeled Obviously broken, caption screen errors, agent skips it, no harm done. Right panel, a gauge icon labeled Confidently wrong, caption score reads 94, agent calls a loyal customer with a save offer.
Same size mistake on paper. Very different size of damage once an agent acts on it.
EEvidence test. The one check that confirms it.
Track eng and design hours by category for the AI feature, against the same tracking for the last non-AI feature the team shipped. Ebbline: 74 percent failure-handling by week twelve. The bill-pay redesign, same team, same quarter: 9 percent, exactly as planned. That gap is the whole diagnosis.
Turns "this feels like a lot of bug fixing" into a number a roadmap meeting can actually act on.

The recap, one line per letter: two weeks priced for exceptions, and a hallway of four unrelated jobs behind that door. Recut by type, not week, and the average splits into a real story. Headcount and process never moved, only the ratio did. Three habits, not one mystery, explain where the hours went. One comparison, run against a feature with no model in it, confirms it's the shape of the work, not the team.

Three things worth stating directly, since this is where the real judgment sits. The alternative Amaranth's team considered, and dropped: raise Ebbline's flag threshold from 70 to 85, so fewer borderline accounts ever reached an agent. It lost, because it doesn't fix any of the four actual failure types, it just quietly drops real catches to make the false-positive problem less visible, trading a measurable harm for an invisible one. The AI-specific failure worth naming by name is distribution shift: the five-line business segment, and later a new prepaid plan called RoamFree, behaved nothing like the single-line postpaid subscribers Ebbline trained on, so its scores were silently miscalibrated the moment each one launched. The guardrail is calibration monitoring: track predicted risk against real 30-day outcomes broken out by plan type and account type, not just overall, and alert the moment any one segment's calibration drifts from its own eval baseline. And the trade-off Duskvale accepted on purpose: a new "hold for review" state for low-confidence scores, instead of sending every flag straight to an agent. The queue covers fewer accounts each day at first, but almost everything that reaches an agent is a real, checkable risk, and that's the trade Duskvale chose over a bigger queue full of noise.

And if you want to be sure it really works, try it somewhere else

Same five letters, a veterinary triage line instead of a phone company, and this time the doors nobody priced are about a symptom, not a subscriber.

Sortwell, built for Pinehollow Veterinary Group's call centre, listens to a symptom description an owner types or reads out and scores how urgent the case is, so the on-call vet sees the riskiest animals first instead of a first-come queue. Torbin Baxendale runs triage ops there, and Sortwell's build broke the same way Ebbline's did, on a different kind of doorway.

Pinehollow's roadmap priced one and a half of ten weeks for "model exceptions," the same shared-bucket shape Duskvale used. By week eight, failure-handling hours sat at 68 percent. Recut by type: breed-specific presentations outside the training data, 22 percent. Ambiguous free-text symptom descriptions, 19 percent. Confidently wrong "routine" calls that masked a real emergency, 17 percent. Cases that aged without follow-up, a silent miss, 10 percent.

Hand sketched decision tree titled Sortline's new rule for a symptom call. Root box reads A new symptom call comes in, branching into four outcomes. Clear match to trained patterns leads to score it, agent trusts top of queue. Breed or symptom outside training data leads to flag for manual triage, do not auto score. Score is high but history reads routine leads to hold for vet review before calling. A case ages without contact leads to escalate automatically, do not wait on the score.
Same shape of fix as Duskvale's, built as a rule the whole team can apply to the next case, not just this one.
The decision Pinehollow would take back Sortwell launched with the same shape of roadmap Ebbline started with: one shared "exceptions" line, no separate scoping for each way the model could be wrong. It made sense for a small pilot with a handful of odd cases a month. It stopped making sense once breed-specific and ambiguous-text cases became a real share of every week's calls.

Mapped straight onto TRACE: the timeline is a roadmap that priced exceptions as one small line, then watched failure-handling hours climb past half the week by week six. The recut splits an average that looked survivable into four separate, unrelated categories. Assume nothing rules out under-staffing and a rushed launch, both held steady while the mix of failure types shifted. The cause candidates are the same three habits in new fur: whether a breed's presentation matches anything the model has seen is a feasibility unknown, not an effort estimate; a "routine" label that turns out wrong costs more than a call that visibly drops; and trust breaks the same way, one bad urgent-case miss and a vet stops trusting the whole queue. The evidence test is identical in shape: track hours by category, compare against a non-AI feature from the same clinic group, no argument needed once it's on the table.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: recut the hours by failure type, and compare the AI feature's share against a non-AI feature from the same quarter, full stop.
Cost: no time this sprint to build new tracking. Add one tag to tickets you already file, AI-related or not, that's nearly free, then compute the split from data you already have.
The model got better, for real: say Ebbline's calibration on the RoamFree segment improves close to the postpaid baseline after a retrain. Keep tracking failure hours by category anyway, because "many doors, one path" doesn't stop being true just because today's doors got easier to walk through. The next segment will open a new one.

Where people run it wrong.
They double the size of the "exceptions" epic instead of splitting it into named failure types with owners.
They blame the individual engineer's estimate instead of the shape of the work.
They keep sending every low-confidence score straight to an agent because holding some back feels like giving up coverage, instead of accepting fewer, more trustworthy flags.

How to use it live. When an interviewer asks why an AI team seems to spend all its time on bugs, ask one thing back before answering: "is failure handling tracked as its own line, or is it hiding inside one shared bucket next to the happy path?" That question alone is usually the exact distinction being tested.

Flashcards (tap any card to flip it)

1 · THE METHOD
What framework fits a "why does the team spend so much time on failure cases" question?
Tap to flip
ANSWER
TRACE: lay out the timeline, recut by category, assume nothing about scoping, name the real causes, then run the one evidence test.
2 · THE PEOPLE
Who is this answer about?
Tap to flip
ANSWER
Amaranth Stanhurst, who owns Ebbline, Duskvale Wireless's churn score, and Wynifred Yardley, who runs the retention desk that calls off its queue.
3 · THE HABIT
What habit did the retention desk build, then partly abandon?
Tap to flip
ANSWER
They stopped working the old reactive contract-expiry list and started calling straight from Ebbline's risk queue, until three bad calls in a row made agents start opening every account's history by hand again.
4 · THE RECUT
What does slicing the build hours by failure type show that one "misc" bucket hides?
Tap to flip
ANSWER
Four separate, unrelated failure categories, stale data 15%, untrained segment 24%, confidently wrong 20%, silent misses 15%, adding up to 74% of all hours, not one small tail.
5 · THE OLD DECISION
What decision would this answer take back?
Tap to flip
ANSWER
Pricing all failure handling as one epic, Model Exceptions and Cleanup, sized at two of fourteen weeks, as if every way the model could be wrong was one small, similar problem.
6 · THE NUMBER
Fill in the blank: failure-handling hours grew from ___% in week one to ___% by week twelve, while a same-quarter, non-AI feature held steady at ___%.
Tap to flip
ANSWER
8% to 74%, while the non-AI feature held at 9%.
7 · THE EVIDENCE TEST
What's the one check that confirms the imbalance is structural, not sloppy planning?
Tap to flip
ANSWER
Compare tracked hours by category for the AI feature against the same tracking for a recent non-AI feature. If the AI feature's failure share stays high while the non-AI one stays low, it's structural.
8 · CROSS-PRODUCT TRANSFER
Section 4 runs this same question again for a different product. Which one, and what's the equivalent doorway that broke it?
Tap to flip
ANSWER
Sortwell, Pinehollow Veterinary Group's AI triage line. The equivalent doorway is breed-specific symptom presentations the model never trained on, plus ambiguous free-text descriptions.

Check yourself Score: 0 / 0

True or false
1. True or false: the real fix here is for engineers to work faster so the "Model Exceptions and Cleanup" epic finishes on schedule.
  • True
  • False
Show hint
Look at what the recut chart actually shows: one bucket hiding four unrelated jobs.
Show answer
False. Working faster doesn't fix a missing structure. The epic was mis-scoped as one bucket for four separate failure types, each needing its own line, owner, and detection plan.
Multiple choice
2. Why did a bill-pay redesign, shipped the same quarter with no model in it, matter to this diagnosis?
  • A. It proves Duskvale's engineers are equally skilled on both features.
  • B. It's the comparison that shows the high failure-handling share is about the AI feature's own shape of work, not this team being bad at planning.
  • C. It shows non-AI features never have bugs.
  • D. It was cancelled, which freed up time for Ebbline.
Show hint
Look at the "assume nothing" step in the TRACE recap.
Show answer
B. Same team, same quarter, same build discipline. The only real difference is the model. That's what makes the 9 percent versus 74 percent gap mean something.
Fill in the blank
3. By week twelve, failure-handling hours reached ___% of the team's time, versus a planned share of about ___% in the original roadmap.
Show hint
Check the timeline diagram and the line chart in "Let's learn."
Show answer
74%, versus about 14% planned (2 of 14 weeks). The roadmap priced failure handling as a small tail. It became the majority of the work instead.
Short answer, name the reversal
4. What old decision does this answer take back, and why did it make sense when it was first made?
Show hint
Look at the key point box titled "The choice I would take back," in Let's learn.
Show answer
Model answer: Pricing all failure handling as one epic, sized at two of fourteen weeks. It made sense before anyone could name more than one kind of thing the model might get wrong, before the wrong answers turned out to be four separate, unrelated problems.
Short answer, apply it yourself
5. Think of an AI feature you've used or built. Name one failure mode it has that would need its own detection, separate from just "the model got something wrong."
Show hint
Look for a way the feature could be wrong that a different failure mode wouldn't catch, the way a stale-data flag and an untrained segment need different fixes.
Show answer
Model answer: A resume-screening tool might handle "typo in a skill name" fine but need a separate detection path for "candidate from a country whose degree names never appeared in training data," since that's a different kind of blind spot, not the same bug wearing a new label.
Fill in the blank, work the number
6. If Duskvale had launched RoamFree with three times more subscribers than planned, would you expect the "untrained segment" share of failure hours to rise, fall, or stay flat, and why?
Show hint
Think about how much of the live queue would fall into a segment the model was never calibrated for.
Show answer
Rise. A bigger RoamFree base means more of the daily queue lands in a segment the model has no real calibration for, so more of its scores fall in the miscalibrated range, and more of the desk's time goes to catching them.
Before you close the answer
Why this works
Tests whether you can tell the difference between "this team plans badly" and "a model's failure surface is structurally bigger than its happy path." Most candidates either blame the team or say "AI is just harder," without ever running a real comparison to check which one is true.
Follow-up traps
"Couldn't Duskvale have just estimated the exceptions epic bigger, say six weeks instead of two?" Response: a bigger flat number is still one number for four unrelated jobs. It buys time without buying the thing that was actually missing, a separate line, owner, and detection plan per failure type.

"Isn't comparing to a random bill-pay redesign a stretch, apples to oranges?" Response: no, that's the point of picking it. Same team, same quarter, same build discipline, the only real difference is that one feature has a model in it. That's what makes the nine percent versus seventy-four percent gap mean something.
If pressed
The four failure-hour percentages weren't self-reported. They came from Jira time-tracking, hours logged against tickets tagged by failure category, not a team's gut sense of "this feels like a lot." The same tagging scheme now runs on every AI feature Duskvale ships, checked at week four, eight, and twelve.
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.

  • A live AI agent you actually shipped
  • A launch decision you can defend under pressure
  • An interview-ready portfolio, not more flashcards
Know more