Report a Bug — Start a Conversation

Today at Automattic, I gave a presentation called Life Cycle of a Bug Report. Ostensibly, it was about the elements of an effective bug report and what happens to a bug report after it is opened. Ultimately, though, it was about how Happiness Engineers fit in to the rest of Automattic (or, more generally, how a support team fits in to the rest of a company), and how reporting bugs and other feedback can lead to better communication between support and product teams.

Here’s how customer support can sometimes look:

1. The product team launches a product to the users.
2. The users use the product, and when they have questions they reach out for support.
3. Folks in support help users solve their immediate problems.

Ideally, however, there is a complete feedback loop:

1. The product team launches a product to the users.
2. The users use the product, and when they have questions they reach out for support.
3. Folks in support help users solve their immediate problems and communicate bugs, pain points, and other feedback to the product team.

In that complete loop, the people who spend the most time talking with users can advocate for those users and help set priorities for addressing pain points. Support folks also get an opportunity to connect more with the people who spend the most time creating and improving the product, to better understand existing priorities and resources.

When I write a bug report, I’m not just dumping a problem on someone else’s lap or giving someone a hard time for the product they created. I am pointing out a source of pain for the product’s users and starting a conversation about how to address it, in the context of everything else a product team is working on. In the process, I develop stronger relationships with our product teams and, as a result, can provide better, more informed support to our users.