One sure test of any product manager’s resiliency is how she manages unplanned service outages and other types of incidents. I’m referring to events that can risk a company’s reputation, increase costs, and erode client confidence.
In some organizations, the communications manager or product marketing manager–people with experience in communication—are expected to take the reins and communicate when these situations arise.
But when this responsibility falls on product managers, it’s a different story. They find themselves in a trial by fire situation. In my 10+ years as a product manager, I’ve found myself in plenty of stressful situations where I’ve needed to manage through an unplanned interruption or even a data breach.
Incident Communication for Product Managers
Incident communication is an extremely important skill for product managers to hone, no matter how big or small the disruptions they face may be. I’ve learned some things about what and what not to do when you find yourself in the dreaded situation of needing to manage through disruptions.
Hint: Communication is key. Resist the urge to go quiet.
1. Investigate
Here’s the scenario: The client (or internal stakeholder or call center or system) alerts me to a problem, and I immediately go into investigative mode. I begin by trying to learn the severity of the issue from my team, what the impact is at the moment, and what can happen if the issue is left unresolved.
I’ve learned not to spend too much time in this mode because it is my responsibility to communicate as soon as possible. Instead, I can pass the investigation about the root cause to those on my development team who are uniquely qualified to do this work.
2. Respond appropriately
The response—including frequency, channel, and elements of the communication—should match the level of severity of the occurrence. For instance, in one case, we had a temporary system performance issue. The response was appropriately handled by one email sent to the client.
3. Respond immediately
I’ve found it’s better to get something out to users quickly rather than waiting until I have more complete information to share. The goal of the first communication is to acknowledge the situation. Do this by updating the status page, wiki, and social media channels, and/or sending email communication.
Prior to joining Atomic, the product I managed had 150K users at various stages in their application process. And all of the user activity was deadline-driven. If application deadlines were missed, serious consequences occurred. The quicker I reached out to that community to acknowledge the problem, the fewer customer complaints we received.
4. Be transparent
I’ve learned that customers are more likely to trust honest, transparent communication. Share openly what is known about the incident at the time, even if it is bad news for the user. In other words, address it head-on. If you don’t, users will fill in their own narrative, and it will not be positive.
Components of User-friendly Communication
When drafting communication, stick to certain elements, tone, and style. In my experience, these are the approaches that customers appreciate:
- Keep your style honest and factual, and make sure to use terms that the client can understand. State how the issue(s) affected them or their customers. For instance, “A 404 error page displayed for nearly 30 minutes when attempting to access the order page.”
- Your tone should both express concern and convey that you are in control of the situation.
- Include a sincere apology. Sometimes it can be difficult to find a way to word a genuine apology to customers. After all, internet users frequently see apologies and perhaps are becoming desensitized to them. But in my situation, when I took the time to think about what the customer was feeling during the incident, it led to writing an effective apology.
- Include a statement about when the next update will occur and where the user can find the latest information.
Your choice about whether or not to include technical detail should depend on your primary intended audience. Sometimes, I have included a technical explanation of what went wrong as an attachment or at the end of the user-friendly information.
Other Lessons Learned
Don’t forget to communicate with internal teams including developers, sales and stakeholders. In these situations, I have slightly re-purposed some of the client-facing communication and shared it internally so that my team understood the issue and how the issue was described.
Don’t miss the opportunity for updates and follow-up communication. After my company delivered the first communication, we periodically updated the product status page as long as the incident persisted. The update included a date and timestamp. Actual feedback from customers thanked our team for putting out frequent status updates, even when there was nothing new to report.
Finally, don’t procrastinate. Probably the most important lesson I’ve learned in these situations is to make an incident communication plan before unplanned issues arise and share the plan broadly within the organization.
Hopefully, some of what I’ve shared with you here can be helpful as you create your own plan for product incident communications.