Complaint Storms
A team ritual to see your own product with fresh, critical eyes — by first ripping apart someone else's.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
Power users of their own product (like Slack or Figma employees) lose the ability to empathize with new users who care less and know less. A complaint storm is a group session where the team walks a customer journey on one shared screen and surfaces every point of confusion and friction. The key trick: start on an ADJACENT product first, which is emotionally easier and calibrates the team's critical eye, before turning that same lens on your own software.
Origin
Started at Slack around 2019–2020 by Noah Weiss and Stewart Butterfield. Weiss notes it reaches a similar place to Stripe's 'friction logging' practice, with the added nuance of starting on someone else's product.
Core principles
- 01Deep familiarity with your own product destroys your empathy for the next million customers who've never used it
- 02Critiquing a competitor's or adjacent product first is less painful and generates ideas you can try on your own
- 03One shared screen, projected, so the whole team fills in issues together in real time
- 04The output is calibration on product pace and quality that the team develops collectively
How to run it
- 1
Assemble the team and pick a starting product
Get the team together (often with a senior leader) and begin with an adjacent or competitor product in a similar space, not your own.
Pro tip Starting elsewhere lets the team realize 'everyone has this much opportunity' rather than 'we suck', which unlocks honest critique.
- 2
Walk the whole customer journey on one screen
Go from landing on the website through account setup, onboarding, and reaching the point of value — one screen at a time, projected for everyone.
- 3
Log every point of confusion and friction
Everyone fills in every issue, every confusing moment, every pain point — the things that would stop a user in their tracks — not bugs, but craft failures someone who cares would fix.
- 4
Turn the lens on your own product
Once the team is calibrated, run the same critical walkthrough on your own software.
Pro tip Use it whenever a team gets stuck or reaches a dead end — it reopens the creative view of the problem space.
Watch out This part is painful — like watching a usability test of your own baby — but that discomfort is the point.
In the wild
Whenever a Slack team got stuck or felt it had reached a dead end in a direction, it would run a complaint storm on its own product area or on adjacent products purely for inspiration.
→ The exercise unlocked more creative views of the problem space and became a reliable go-to when teams plateaued.
Common mistakes
Starting the critique on your own product
Going straight at your own software makes the session feel like 'we suck' and triggers defensiveness; starting on an adjacent product calibrates the eye and makes self-critique bearable.
Confusing complaints with bug reports
The goal is craft and confusion points ('what would stop you in your tracks'), not technical defects — logging only bugs misses the empathy insights that drive redesign.
Is it for you?
Best for
Product teams who are deep power-users of their own tool and are losing empathy for new, less-sophisticated users.
Not ideal for
Brand-new products with no user base yet, or teams that need quantitative prioritization rather than qualitative friction-finding.
From the transcript
“we get a team together often Stewart or myself would also join and we'd actually start off with other products first like an adjacent spaces”
“people are going to fill in every issue everything that's confusing every pain Point not buzz but ways in which if you care about and…”
“It's similar to a process that I learned stripe has called friction logging but I love I love the Nuance here of starting with someone…”
From the episode
The 10 traits of great PMs, how AI will impact your product, and Slack’s product development process
Noah Weiss (Slack, Foursquare, Google)