Using Data to Increase One’s Sphere of Influence

Problem

A couple of years ago, we were witnessing several Severity 1 and Severity 2 support cases. Support, Engineering, and Product Management worked collaboratively on the cases to help resolve them and provide relevant feedback and guidance to the customers. However, what was missing was an analysis of the underlying causes and what could be done from a design standpoint to resolve the problem.

Actions taken

I worked closely with the support team. We built a quick dashboard to provide insight into all Sev1 and Sev2 issues for the product that could be filtered based on a timeframe. I analyzed those cases and categorized them based on the underlying problems that caused them. We wanted to understand better if this was a performance issue or something else. Was this happening due to an external environment, or did out-of-memory situations cause it?

After I categorized the questions like above, the next step was to identify what we should do to avoid those issues from happening again. The lowest hanging fruit was to investigate if they were documented in the first place. Furthermore, was the documentation clear and easy to access? Sometimes the issue is all about educating the customer.

For issues that were beyond documentation, I worked with the Product Management and Engineering stakeholders to identify the next steps. We wanted to establish if those areas were being looked at already and learned how those efforts were being tracked. Many other questions followed from there, such as, Did they track the different symptoms identified? If not, we wondered if we could come up with a plan to do that.

As a result of this investigation, I created a tracker to follow up on the discussions and the action plan. I worked closely with the PM and engineering team to align and get consensus on the various areas we identified. All in all, I was able to increase my sphere of influence by steadily pursuing a data-backed approach and investigating the problem from all different angles corroborating my investigation with solid evidence.

Lessons learned

• Use data to provide insights, and the analysis of the data to derive a plan. Data is factual. Unlike anecdotal insights, data brings credibility. People will accept factual things more likely, so whenever you can, resort to data. Oftentimes, you will not have sufficient data, but the more mature a product is, you will be able to more rely on data.
• Collaborate with stakeholders to formulate the plan and track its progress. You can have all the data in the world and be able to identify problems and gaps, but it will be of no use if you can’t translate it into a plan. If you don’t include all stakeholders who could share valuable feedback, you can end up with a plan that will not be feasible or even accurate. For example, I could ask Engineering to fix some gaps in the next release, but if they have all those other things lined up for the next two releases, that simply won’t be possible. I can come up with a straw man, but I need stakeholders to and their holistic perspective to help me wrap up the plan.