The Users Having a Bad Day Chart
Emit a log line every time a user hits pain, stack them in a bar chart, and burn the bars down
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
A default answer to 'what should we measure?' when you have no idea. Brainstorm — or simply listen for — everything that would ruin a user's day, emit a log line every time one occurs, and render them as a stacked bar chart of bad-day reasons by frequency. It becomes a background noise-counting system for where the pain actually is, and anyone in the company can add a new bar. The frequencies are usually eye-opening.
Origin
Used at Stripe; Weinstein is explicit that he doesn't know whether Stripe invented it or borrowed it ('I don't know if we stole it from somebody else or if we came up with internally'). He credits its usefulness to operating at Stripe's scale, where you genuinely cannot know what is happening until you emit the log line and count it.
Core principles
- 01You don't know what's happening to your users until you emit the log line and count it — intuition badly under-counts frequency.
- 02A bad day is defined from the user's felt experience (a 404, a payout a day late, ten declines in a row, an unnecessary 2FA prompt), not from a system-health perspective.
- 03It scales understanding across a team: anyone with a hypothesis about user pain can add their own bar, no permission needed.
- 04A known, counted bad day is acceptable; an uncounted, surprising bad day is the emergency.
- 05The goal is to eradicate bad-day reasons, not merely minimise them.
How to run it
- 1
Brainstorm the bad days
Ask, for a real user: what would cause you to personally have a bad day with this product? Or just listen to customers. Examples from Stripe: hitting a 404, a payout arriving a day after its ETA, more than ten payment declines, a slow-loading dashboard, being asked for 2FA again when you were just here yesterday.
Pro tip Ask an actual customer to name their bad days on a call and then sit in silence. Weinstein does this to Lenny live on the episode and Lenny names three of Stripe's existing bad-day charts unprompted.
- 2
Emit an event every time one occurs
Instrument each bad-day reason as a log line fired at the moment the user experiences it. No aggregation, no judgement, just count the occurrence.
- 3
Render a stacked bar chart of bad-day reasons by frequency
Put every reason on one stacked bar chart. This makes the relative scale of each pain visible and comparable — which is where the surprises live.
Pro tip Make it trivially easy for anyone to add a new bar. This is what turns it from a PM's chart into the team's shared understanding of users.
- 4
Choose which bars to burn down
Over time, deliberately pick bad-day reasons to eradicate rather than shave. The chart gives you an informed basis for comparing this pain against every other pain when deciding where to invest.
Pro tip This does not have to be your team's goal metric. It can just be a background system you watch — the value is in what it surfaces.
- 5
Treat an uncounted bad day as immediate action
When an incident or customer issue arrives, the first question is: do we have a bad-day reason for this? If yes, you already knew and can weigh it. If it's a surprise, the priority action is not necessarily to fix it — it's to figure out how to count it and get it on the chart.
Pro tip Weinstein calls a newly-surfaced bad day 'product catnip' — celebrate the person who brings you one.
Watch out The failure state isn't a high bar on the chart; it's a pain that has no bar at all, because you cannot make an informed investment decision about something you don't count.
In the wild
Weinstein asks Lenny, a Stripe customer who checks his dashboard daily, what a bad day would look like for him. After a pause, Lenny lists: the numbers not loading, charts taking a long time to appear, something being completely off, not being able to log in. Weinstein confirms he knows the URL of each of those charts — including the 2FA one, because he feels it himself ('come on I have the same cookie I was just here yesterday').
→ The exercise demonstrates that customers will hand you the chart list in under a minute if you ask and then stay quiet — and that the ones you already track are usually the ones you personally feel.
Common mistakes
Waiting for a strategy before instrumenting
Weinstein's framing is explicitly 'if you are bored one day and you're not sure what to measure' — the chart is a cheap default, not a strategic commitment. Teams that defer instrumentation until they've agreed on a north star simply stay blind for longer.
Minimising instead of eradicating
The aim is to remove bad-day reasons from the chart entirely. Treating a bar as something to shave a few percent off each quarter turns it into bean-counting rather than a burn-down.
Owning the chart as a PM
The leverage comes from anyone in the company being able to add a bar on their own hypothesis. Gatekeeping what counts as a bad day kills the mechanism that lets the team scale its understanding of users.
Is it for you?
Best for
Any product team, at any scale, that has live users and no confident answer to 'what should we measure?' — especially where support and incidents feel like a series of unrelated surprises
Not ideal for
Products with no usage yet, or as a substitute for a single customer-value north-star metric — Weinstein positions it as background noise-counting, not the goal
From the transcript
“just users having a bad day where we will just emit a log line anytime we think that a user bumped into a problem so…”
“then just emit an event when that occurs and then you could just make a bar chart a stacked bar chart of all the bad…”
“what we can choose over time which bad day reasons we want to burn down and hopefully just like eradicate them not just like minimize…”
“when we didn't know about that bad day and it's a surprise to us too that is like to for me is immediate action it's…”
From the episode
Building product at Stripe: craft, metrics, and customer obsession
Jeff Weinstein (Product lead)