Why do AI PMs spend disproportionate time on failure cases relative to happy paths?
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"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.
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
More on AI PM vs traditional PM vs technical PM
- #1 List four responsibilities an AI PM holds that a traditional PM does not.
- #2 Which parts of the classic PM toolkit transfer unchanged to AI products, and which do not?
- #3 Explain why an AI PM often owns the evaluation set while a traditional PM would not own a test plan.
- #4 How does the discovery phase differ when feasibility is genuinely unknown until you build?
- #5 Describe the difference between an AI PM and an ML PM at a company that has both.
- #6 Why does the AI PM role pull the PM further into the technical stack than most PM roles?