Take Opportunities to Think Like a Product Manager

Problem

"I wanted everything to go faster and found it cathartic to find ways to unlock performance that wasn't there previously."

Years ago when I was working as a software engineer, what motivated me was the raw speed of computers and software. I wanted everything to go faster and found it cathartic to find ways to unlock performance that wasn't there previously. There wasn’t a tremendous appetite for UI/UX performance enhancements (faster page loads, snappier user interfaces) from those who prioritized the product development backlog. Many didn't see the value of a quicker product experience when no customer was specifically asking for it. I searched for a way to incorporate performance into a higher-quality and more useful product.

Actions taken

"The bottom line is that faster solutions are better in customer service."

My interest in speed and performance led me to a search for a way to articulate the value that I perceived, in a manner that non-engineers would appreciate. Our company and our software was focused on customer service and satisfaction. As a B2B2C company, we provided our customers with the means to provide a great customer support experience for their consumers. People who need help with a purchase want to get help with their products quickly, whether through online chat, calling somebody, or finding the answers with a search engine. The bottom line is that faster solutions are better in customer service.

It turned out that not everyone understood that faster software was essential to providing that great customer experience. Nearly all customer support software was purchased to drive cost savings. Companies wanted their customer support to be so streamlined or automated entirely so they could hire fewer people and save money. So, I began looking into how I could tie together the performance that I cared about and the bottom-line revenue impact that these companies cared about.

I asked myself what did customer support directors and managers find important? There is a well-known metric in the customer support space called ticket deflection. Ticket deflection, roughly explained, is when someone attempts to submit a support ticket, initiate an online chat, or call a support agent, but then is presented with relevant solutions to their problem before completing the process. If these presented solutions prevent the individual from continuing the support ticket process, then the ticket is deflected. This was something our customers loved, as less support tickets meant a less burdened staff. For some of our customers, they appreciated not having to hire more staff. Others who were dedicated to providing a great customer experience further realized that they could dedicate staff to spend more time on the support tickets that were actually filed. These support tickets that could not be deflected often represented more complex issues that required a human touch, so by focusing support staff on these tickets, they provided better service to their consumers.

Once it was positioned as having a direct impact on one of the key metrics our existing customers, and potentials in the market, use to judge their customer support software, our product managers understood the value. We mutually agreed to invest in speed and performance and later used it as an advantage over our competitors.

Lessons learned

• As an engineer, you shouldn't presume that performance and other technical aspects are accepted or important concepts to other teams. This surprised me because I valued it highly from a technical standpoint. It is important to understand that others will care about technical concepts if it is tied to metrics they care about, in this case, customer need and their desire to spend money to fulfill that need
• You have to be very patient when communicating as an engineer. Do not use the same technical language that you use with your peers when discussing a topic with the product leadership team. They more often care about the value, benefits, and people-oriented approach to problems rather than the tech, speed, and how you solved it.