Cultivating empathy for internal teams
Empathizing with customers alone isn't enough
Empathy, within the context of product management, typically refers to empathy for the customer.
Over the past five years, as more product managers have come to recognize the importance of “soft skills” in the role, this kind of empathy has become increasingly important and desirable. For good reason: you can’t build a winning solution if you don’t understand customer pain. In order to truly understand that pain, you need to do more than listen to customers. You need to deeply understand their situation, emotions, and point-of-view.
Empathy for the customer has become such an important skill that – in contrast to even five years ago – most product managers I know would rather hear “you’re not data-driven enough” than “you’re not customer-focused enough.”1 The ability to feel with others is a competitive advantage.
Empathy is also, on many product teams, an advantage too often applied selectively or only when it makes sense (read: in user research sessions). In fact, I think that’s somewhat encouraged. As product managers, we’re taught to pride ourselves on our ability to connect with customers and uncover their underlying needs because, frankly, excelling at that helps the business and makes us feel like good PMs. Then, we put our empathetic hat on the shelf and don our analytical or technical or business hat the rest of the time.
I worry about having a limited, rather than holistic, approach to empathy. Something I wonder often is what extending empathy – as a specific lens – to other aspects of our role as product managers might accomplish. What would happen, for instance, if we applied empathy to understanding not just customer pain, but internal team pain as well? (Particularly for internal teams who are customer-facing?)
The world many product managers I know inhabit is one in which they live in dread of Slack DMs about feature requests because it means they’ll have to say “no” for the tenth time this week. They’ve stopped categorizing internal product feedback because the pile has grown taller than Everest – but it’s okay because internal teams have stopped expecting a response from them anyway. Requests for timelines and launch dates trigger them and, when a project is delayed, feel like salt in the wound. When they need to practice that prized customer empathy, they reach out to the customer success manager whose email they ignored last week and, puppy-eyed, ask if they can schedule a research session with their key contact.
Obviously, I’m being hyperbolic to make a point. But not by much: many product managers do in some capacity struggle to empathize, and truly partner, with internal teams. Rather than see their peers as equal collaborators, they see them as a Sales team they need to prevent from overpromising or a Customer Success team with whom they need to constantly set expectations or a Legal team that’s holding back their launch. I’ve seen dynamics like these in enough companies, and met enough product managers who have, to believe that something is out of joint.
What if empathy can help create internal alignment?
The ability to prioritize makes us less empathetic
As product managers, we have the responsibility of prioritizing what our team works on. Prioritization choices aren’t consequence-free: we need to back up our decisions, and changing priorities has tangible costs. Perhaps because of that fact, it’s easy to forget that the ability to prioritize is not just a responsibility but also a privilege. We have to prioritize; we also get to do.
While I certainly wouldn’t call the ability to prioritize the only factor that influences it, I think it’s one of the factors that most affects how we think about everything from customer calls to a backlog of feedback; and, in some ways, it shelters us from certain experiences that other teams regularly encounter.
A common (and easy!) mistake that product managers make when working with internal teams is that they fail to recognize – though they understand those teammates aren’t in the same role – how different customer interactions are when you don’t own the strategy and backlog.
Imagine meeting with one of your company’s largest customers. They’re threatening to churn unless you agree to support three features they’ve been requesting for the past two years. I’m not claiming situations like this are pleasant for product managers, or that we can go back to our team, wave our arms, and magically prioritize the customer’s requests without serious consequences to velocity, team morale, or our goals. However, we’re closest to the product strategy, we know the business and the market extremely well, and technically we have the ability to go back to our designer and engineers and make a case for, say, a subset of the request to pacify the customer who is threatening to churn. Additionally, in the case that they actually do churn, it usually won’t fall directly on our necks (although in some instances it might). Rarely do we consider what that same meeting might feel like if we didn’t have the ability to prioritize or if we were directly responsible for that customer’s happiness rather than general customer happiness.
I’m serious, think about it: recall the last customer escalation you handled and imagine what that meeting might have been like if you did not have the ability – even if a very constrained ability – to adjust the roadmap. Imagine you’re directly responsible for the customer churning. Imagine the one person you need ask for help has a reputation of saying a blanket “no” to feature requests.
Now consider how you responded to the last feature request an enterprise customer success manager or account manager sent your way.
My point isn’t to shame or suggest that we should start building customer requests willy-nilly and fixing every bug raised to make internal teams happy. (Please, for the sake of your product and your career, don’t.)
Rather, my point is that empathy for the customer alone isn’t enough. Empathy should not be a hat we don selectively when it’s time for research, and take off when dealing with our peers. I believe that – just as building for customers begins with truly understanding their pain – working effectively with internal teams involves truly understanding their pain, their world, and how their interactions with customers differ from yours.
What’s more, I believe that being mindful of those differences can lead to a more holistic approach to product management and improved stakeholder alignment.
The difference empathy makes
Empathy is not a process: it won’t help you prioritize or tell you the best way to collect feedback. Instead, it’s a practice: it helps you understand your peers better so that you can work cross-functionally more effectively.
It can also help you to be more curious about your teammates’ perspectives. What do they struggle with? How do they feel about this prospect or customer request? What trends are they seeing?
Getting started: making an effort and building trust
In my experience, cultivating empathy for internal teams is necessarily reactive at first – especially if you’re in an organization where cross-functional trust is strained or non-existent. It looks like asking questions about feature requests and taking them seriously when they arise; it involves understanding what your teammate needs (help communicating a product decision? your strategic framework? a roadmap?). If you receive a high amount of feature requests, you likely won’t have the time or energy to handle every request this way – and that’s okay. Just don’t say “no” automatically or because you don’t have the time (or if you do, at least have the courage to be honest about it.) When you’re getting started, making the effort is what counts.
Another way to cultivate empathy for internal teams is to seek out their expertise. This can help you avoid bad loops (like request -> no) and balance out the relationship. I’m sorry to say, I’ve met too many product managers make the mistake of thinking that, because they work across all customers and do customer research, they know “the customer” best. Shadow your support teammates and invite them to bug bashes. Grab coffee with your Customer Success or Account Management teammates and ask them what they’re seeing across their customers. Get a sales teammate’s opinion on a business idea you have.
Treating your cross-functional peers like this – as partners – has multiple positive effects:
You deepen your understanding of how they feel and think about certain ideas, processes, features, problems, etc.
You challenge your own, limited worldview
You empower yourself to anticipate their needs and solve for them more proactively with time
You increase the likelihood that they’ll accept “no” (when you do have to say it) more gracefully and work with you to find a solution
The more you make an effort to empathize with internal teams and understand what they care about, the more you’ll start to notice themes in the needs within or across different teams.
Building empathetic resources and processes
Let’s say you’re talking to internal teams more regularly and you’ve noticed that many of your teammates are having a hard time understanding the product strategy for your area of the product. Or, maybe you’re picking up on themes in the product feedback you’re receiving.
Identifying and solving for these opportunities is a great way to level up your cross-functional skills as a product manager. You might, say, create a resource walking through your strategy, or work with other teams to regularly discuss common requests and create talk tracks.
A word of caution, however: remember that whatever resource or process you create needs to work for other teams and their needs. If you already have a strategy document, it may not be enough to share that with a customer success manager if what they’re really looking for is help justifying the strategy to a difficult customer. That’s why continuing to check in with teammates is useful – it helps you ensure that the improvements you’re making are truly working.
Elevating cross-functional impact
If you take the time to empathize with internal teams, over time they will come to understand your perspective and needs as well. That cycle is self-reinforcing and can lead to elevated cross-functional impact.
For instance, if you invest in helping your Customer Success teammates understand your product strategy and help them develop talk tracks for common requests that don’t align with that strategy, they’ll be more empowered to set expectations with customers proactively; they’ll also be able to flag certain customers, including escalation risks, as good research candidates. If you collaboratively keep track of trends in feedback to interrogate the strategy and anticipate where it may need to change, you’ll keep the lines of communication open and deepen trust. If you consistently ask questions when feedback is raised, they’ll be able to discuss it more deeply because they’ll anticipate what questions you’re likely to ask. If you own enablement for releases and make sure implications, tradeoffs, and future plans are clear, they’ll become your team’s champions with customers when you release a new feature.
This kind of cross-functional relationship is the end goal of cultivating empathy for internal teams: a partnership in which you anticipate each other’s needs and proactively solve for them.
What’s more, it can result in winning product changes. Some very impactful features I’ve shipped came out of feedback requests or conversations from internal teams. While the end result didn’t necessarily match the original request, the trust developed by taking requests seriously and collaborating on building a solution was a win for everyone – particularly for the customer.
In short: when we ground our relationship with internal teams in empathy, we ultimately build trusting partnerships that improve our lives as product managers, establish strong cross-functional relationships, and drive impact for the customer.
If you enjoyed this post and you’re not already subscribed to the Product in Practice newsletter, consider doing so – it’s free!
Note, however, that “data-driven” and “customer-focused” are neither opposites nor mutually exclusive!