Writing
Naming the problem before the fix
When teams jump to fixes too early, you get motion without alignment. In customer-facing roles, I have learned to pause and ask: what would “fixed” look like for the customer? and what signal are we seeing more than once?
A short, agreed description — who is affected, what broke, and what outcome we need — saves hours in Slack threads and keeps Product, Engineering, and CS on the same page.