Bad vs Sad Quality Tiers
Classify every failure as bad (irrecoverable) or sad (recoverable pain) so teams triage quality across many surfaces.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 90%
When throughput explodes and you own many different product surfaces, raw performance and reliability dashboards stop telling you whether a number is good or bad. Fiona Fung's fix is a shared two-tier vocabulary: 'bad' is a very bad, irrecoverable error where the user loses work; 'sad' is a recoverable pain point. Each team gets agency to define what constitutes bad and sad for its own surface, then focuses on eliminating bads while watching whether stacked sads are trending toward bad.
Origin
Introduced by Fiona Fung on the Claude Code team at Anthropic as a lightweight quality framework layered on top of standard reliability dashboards.
Core principles
- 01A metric is only useful if you know whether the number is good or not — a severity framework supplies that judgment
- 02Irrecoverable, work-destroying errors (bad) get priority over recoverable annoyances (sad)
- 03Many small sads compound and can escalate into a bad, so track their trend
- 04Give each team high agency to define bad and sad for the surface they own
How to run it
- 1
Define the two tiers
Establish 'bad' as a severe, irrecoverable error where the user loses work, and 'sad' as a recoverable pain point or friction.
Pro tip Anchor 'bad' to concrete losses like a CLI crash that destroys in-progress work.
- 2
Let each team map their own surface
Because surface areas differ, have each team decide what a bad and a sad look like for their service — e.g. crash rate is bad, UI flickering is sad.
Watch out Do not impose one global definition; a bad on the CLI is not the same as a bad in a rendering surface.
- 3
Prioritize bads, monitor sads over time
Focus remediation on bads first, then watch sad trends because stacked sads can generally roll up into a bad.
Pro tip Use the framework to zoom out to an overall theme of experience instead of drowning in per-surface load-time metrics.
In the wild
On the CLI, a crash is classified as bad because you lost work, while a flickering UI is a sad because it is recoverable. Each team sets these thresholds themselves under a high-agency model.
→ The team can zoom out from disparate dashboards to a single, comparable read on experience quality across surfaces.
Common mistakes
Staring at raw metrics with no severity lens
With many product surfaces, load-time and reliability numbers alone don't tell you if a value is acceptable; without a bad/sad framing you can't see the overall theme of the experience or prioritize.
Ignoring accumulating sads
Treating recoverable pain points as harmless misses that stacked sads generally escalate into a bad over time.
Is it for you?
Best for
Engineering or product leaders overseeing many product surfaces with high shipping velocity who need a shared quality vocabulary
Not ideal for
A single, simple product where standard SLO/error dashboards already make quality legible
From the transcript
“let's have a concept of what's bad versus what's sad.”
“knowing that bad is like a really bad irrecoverable error. We enable each team”
“on CLI could be crash rates. Like a crash is pretty bad. You lost work.”
“constitutes a bad and what's a sad and then what's the goal that um, each team wants to take.”
From the episode
What happens after coding is solved?
Fiona Fung (Manager of the Claude Code and Cowork Teams)