complaint-storming-for-product-polish

name	complaint-storming-for-product-polish
description	A two-part workflow to diagnose product friction through collective empathy and resolve it via dedicated "Love Sprints." Use this when the team has lost empathy for new users, when "UX paper cuts" are accumulating, or when the roadmap is too focused on 1% metric shifts at the expense of delight.

Complaint-Storming for Product Polish

Complaint-storming is a tactical ritual to combat "owner's delusion"—the bias where builders assume users care about their software as much as they do. It transforms abstract "UX debt" into a high-momentum "Customer Love Sprint" that raises the craft bar and improves user activation.

The Complaint-Storming Workflow

1. The External Calibration

Before looking at your own product, conduct a "storm" on an adjacent or competitor product. This lowers the team's defensive barriers and calibrates their "taste."

• Pick a Journey: Choose a specific flow (e.g., "The first 30 minutes" or "Setting up a new project").
• Live Walkthrough: One person shares their screen and goes through the flow in real-time.
• The Documentation: The rest of the team fills a document or Slack thread with every single point of confusion, friction, or visual "ugh" moment.
• Goal: Identify what makes a product "unpleasant" vs. "pleasant" without the bias of ownership.

2. The Internal Complaint-Storm

Repeat the process with your own live software. Do not use static mocks or Figma files; you must "smell the software" to feel the latency, awkward transitions, and copy issues.

• Adopt the Beginner’s Mind: Specifically look for "comprehension" (Do they know what this is?) and "desirability" (Why should they care?).
• Audit for Principles:
  • Be a Great Host: Are we "putting clean towels on the bed," or is the user hunting for basic features?