Keeping zen and solving client requests

As a product manager, I receive lots of client requests. It’s overwhelming to receive tens of requests in the middle of eight hours of back-to-back meetings and when my engineering team has a full roadmap.

In a moment of panic, it’s easy not to respond or say it’s not possible, and I can’t focus on adding that feature right now.

But, each of those requests comes from a client and has information to improve the adoption of my product. And product adoption, not building pretty products, is always the goal as a product manager.

I’m a product manager and don’t receive every client request. Instead, I often receive a filtered list from client-facing teams of the most urgent — and sometimes least specific — client requests. Although valuable, I find it hard to see these as “gifts of feedback” due to time and resource constraints.

Recently, a coworker asked what was important to know as a product manager. My inbox top of mind, I shared the below strategies — and struggles — finding solutions to client issues.

Note: Most client requests don’t need triaging and responses by a product manager. It’s essential to set up processes to manage requests by internal teams. And also, it’s critical to have documentation and training to make information self-serve by client-facing teams or clients themselves. Setting up processes, documentation, and training is not the focus of this article. Instead, I’m focused on the edge cases where a client-facing team loops in a product manager. In these cases, I use the below tactics to remain zen and solve the underlying issue.

Responding fast and with a timeline

As a product manager, a top priority is responding to client requests. Being timely ensures clients feel heard. Responding fast doesn’t mean I need to know the answer. It does mean acknowledging the request and providing a clear timeline on the next steps.

The first step is to see whether I can point to a document, solution or another internal person. If that’s not possible, I ask more questions or offer to set up a call to get more information, and then I state what next steps I’m taking (e.g., talking to my technical lead). If I don’t have time to read through the request, I just give a timeline of when I will have a chance to respond.

Timelines are critical — even if it’s “we’ll look into prioritizing this in next quarter’s roadmap” or “I won’t be able to look at this till tomorrow.” Timelines level-set expectations across all parties and enable any individual to escalate.

It took me time to internalize how to respond. One helpful mindset shift was viewing the client’s product journey as all the steps that lead to a successful product run, which includes sales and technical support. Thus, when client requests require product support, I need to ensure my small part is exceptional.

Listening & empathizing

The #1 thing I do is listen and make sure to feel the pain. Urgency and great solutions come from understanding what a user is doing and feeling.

Even if I can’t fix the problem, I try to learn about the use case and build a better relationship with the client.

Empathy and active listening are essential even when a client doesn’t voice the friction point. And in fact, most requests I receive are from client-facing teams acting as a proxy. I find that if my team knows I will listen and respond with urgency, that translates to confidence in the product and how they sell to clients.

I think most product managers make clients feel heard. But sometimes when it comes to internal client-facing teams, product managers fail to act similarly empathetic, which hurts adoption.

I try to listen, ask questions, emphasize good points (e.g., nod, “that’s a good point”), and summarize back what I’ve heard. These tactics ensure I correctly understood the information and show the client I’m actively listening. These active listening strategies help me, but what’s important is to listen and show you are listening.

Thinking outside the box

Lastly, most feedback doesn’t have an obvious solution. To combat this, I start by asking questions to understand the client’s needs and ensure I’m solving the root issue. For example, a client says they need a REST API, but the client actually needs to call your application from their REST API.

I often feel overwhelmed at this point by the lack of a clear solution. To ground myself, I try to remind myself that I have spent the most time thinking about my product, and a simple solution may still exist.

While I often need to prioritize a complete solution on my roadmap, in the meantime, the client still needs a fix. Here, I ask myself: is there existing or new documentation I can provide? Is there a snippet of code to fix their problem? Is there a feature on another version of my product that can solve the problem? Is there an internal person who could spend a couple of hours building a feature and doing a one-off flow?

I force myself to iterate through possible solutions that may be wacky but help.

— -

I’m still working on not freaking out and saying, “we just can’t do that.” I try to stay calm and remind myself to think outside the box. I also try to remember that each request is a chance to make my product better.

Originally published at https://serenagupta.substack.com on December 3, 2021.