Great PMs are always on the lookout for ways to create and capitalize on new points of leverage.
In other words — they work smarter, not harder.
In a product-led organization, one huge point of leverage PMs can cash in on is a deep understanding of your customers’ problems. Yet having your finger on the pulse can also be very time consuming.
Fortunately, many organizations are sitting on a gold mine of customer insights — a group of coworkers that are fully immersed in the customer experience: customer service.
Product and customer teams are traditionally not well-integrated, though. But they could be.
If your company can shift its perspective to view customer service as an extension of the product organization, the benefits compound to allow both teams to better accomplish their goals — and improve customer satisfaction overall.
In this post, I’ll share insights from my experience leading product and strategy to demonstrate these key points:
How the relationship between product and customer service usually goes wrong
Three ways to better integrate these teams: share the workload, create a common language, and establish a culture of joint objectives
What happens when you begin to think of customer service as an extension of the product organization
How you can apply the same dynamics to improve collaboration between other functions at your organization
About the Author:
Erika Warren is Head of Growth at Change.org and a Reforge EIR on Retention + Engagement. Erika is the former VP of Product & Strategy at Wyzant, a tutoring marketplace that supports millions of students with their learning goals. Prior to Wyzant, she was a founding member of the product team at Grubhub.
How the Relationship Between Product and Customer Service Usually Goes Wrong
Customer service (CS) professionals interact with customers daily, and the majority of their time is spent face-to-face with customers, documenting their pain points and problems.
(And only rarely compliments — think of the last time you, as a customer, interacted with a support person just to sing the praises of the product. Most times, praise is shared via word of mouth, or WOM, and problems and complaints are directed to the CS team.)
Yet CS agents often feel like their work generates little customer value. Logging tickets, bugs, and feedback takes a lot of time and slows down the agent’s ability to handle more volume — a core metric that most agents are measured against. And the whole process is complicated by the fact that it’s unclear how their tickets are being used across the broader organization.
It’s a vicious spiral: After hearing negative feedback and doing a bunch of work to catalog it, the agent finds necessary change arrives too slowly (if at all), which leads to feeling demotivated and undervalued — and eventually to employee turnover, or dejected or stressed agents directly interacting with customers.
Bad for business either way.
On the other side of the wall, busy product teams don’t want to spend time on low-leverage work, like decoding CS tickets or having to constantly defend their roadmap and prioritization decisions. PMs are responsible for deciding what gets built and when, what gets deprioritized and shelved, and what the scope and complexity of features will be. In order to do the job, PMs have to operate from an ordered list — ruthlessly prioritizing and focusing efforts.
When product teams receive input through CS about unhappy customers or bugs, they have to either pause their work and context-shift to determine priority, or they have to ignore the feedback and stay heads-down on existing commitments. Saying no or ignoring coworkers takes a similar emotional toll.
This leaves the two teams frustrated — and a lot of value on the table.
CS teams feel like their expertise isn’t getting used. Their problems only grow as the company scales. Product folks feel that their prioritization decisions are not respected. Their problems only grow as the company scales. And ultimately, neither team being able to effectively focus their energy harms the bottom line of customer satisfaction.
But it doesn’t have to be this way.
Understanding customer problems is at the core of building a good product. The Feedback River Template in Reforge’s Mastering Product Management program helps you track your feedback management systems and know your user.
3 Ways You Can Help Product and Customer Service Work Better Together
There’s clearly room for improvement when it comes to how the product and CS teams collaborate to inform the customer experience. But what does it actually look like when you consider customer service an extension of the product team?
It boils down to three key cross-functional improvements:
Sharing the workload of improving the customer’s experience
Creating a common language to talk about customers, problems, and the resulting work meant to address them
Establishing a culture of joint objectives, aligning product’s roadmap with CS’ day-to-day logging efforts
Let’s explore each benefit and ways to create them within your organization.
Benefit #1: Share the Workload
By introducing more touchpoints between the product and CS teams, you can build intuition and a customer-obsessed mindset, allowing both teams to share the workload of customer empathy and research across an even broader audience.
Shadow CS to Build Empathy and Trust
Before they can collaborate effectively, teams need to feel a sense of trust and respect. And because product has more decision-making power over the CS work that gets prioritized, the onus is on the product team to spend more upfront time improving that relationship.
The same way you’d conduct usability research by studying your customer, your product team can begin to understand the CS team by shadowing their work internally.
Shadowing agents not only builds customer intuition as you’re exposed to customer feedback and issues, but it also fosters empathy, conversation between agents and PMs, and visibility into other workstreams.
Wyzant is a US-based tutoring marketplace that connects educators with learners looking for help and support across 300+ subjects for Kindergarten to Career learners. With the breadth of topics and age ranges, the customer support issues are vast and varied.
At Wyzant, everyone on the product team shadowed CS reps for a few hours at least once a month — but because of how helpful the practice was, many spent more time shadowing. In fact, shadowing became something everyone in the company did quarterly. It was a great way for employees who do not regularly interact with customers to be reconnected with the mission and vision of the company.
Setting up a shadowing program may seem overwhelming or uncomfortable, but it’s not, in my experience. Here are the steps we took to get it off the ground:
As a product leader, I connected with Wyzant’s CS leadership and explained the benefits and goals for a shadowing program.
Together, we created a schedule — picking time slots with moderate volume, not the busiest time slots so that there would be time for dialog between calls or chats, but with enough volume that people would see a variety of issues.
CS agents opted into the slots and then product members joined.
At that time of the meeting, folks would sit together and listen to the calls. (Salesforce and Zendesk offer call monitoring features that you can use to shadow remotely.)
After each monthly shadowing session, the product team would come together with CS managers and debrief the top insights from the experience.
The debrief was one of the most critical parts: It created accountability for busy PMs to actually complete the shadowing, and CS managers were included to provide perspective on the insights and to learn what and how product members organized and talked about the same information.
Incorporate CS as an Extension of User Research
Once your teams have a good foundation of trust, consider how you can use customer teams as an extension of user research. It’s common for the CS team to have a size advantage over product or research teams at the same organization. They also have direct access to customers — an often underutilized resource.
Some low-lift ways to extend product’s user research through the CS organization include:
Asking agents to run a poll or ask a survey question at the end of a synchronous customer interaction.
Using customer interactions to recruit for in-depth customer research studies.
At Wyzant, the product team had observed lower conversion rates for parents of elementary-school learners, so we set up a dedicated team of CS agents to do special user research: When an agent identified a support call from an elementary-school parent, it was routed to our dedicated research agents who could not only handle the caller’s issue, but also ask product-driven research questions in order for us to learn more about this customer subset and what about their situation our product wasn’t currently solving.
Those efforts helped us recruit highly motivated leads for our research, and the agents were excited to be a part of a strategic product initiative. The result of that research led to a different activation path for elementary parents with higher conversion and LTV results. A win for CS, product, customers, and Wyzant.
Create Shared Ownership of Feedback Systems
In Reforge’s Mastering Product Management program, we teach you how to implement an FSOR — a feedback system of record — to quantitatively track feature requests over time (and avoid over-weighing the most recent or most passionate feedback). While FSORs scale better than an inbox of qualitative feedback requests, they still require oversight and maintenance.
Unsurprisingly, it’s often more effective to recruit CS professionals to own this step — allowing PMs to delegate some work, while helping CS coworkers build product intuition and business acumen. The FSOR owners begin to understand the context around why and how PMs prioritize feedback. One champion within the CS org can help become a translator and advocate for product decisions when the PM may not be present.
Get Help with QA and Beta Testing
When it comes to product functionality, agents are often some of the most experienced and knowledgeable people at your organization. After all, they’re triaging and trouble-shooting issues with customers synchronously, and repeatedly.
The CS process can become an important point of leverage for product teams: Work to develop an issue and bug tracking process that allows CS agents to provide necessary context, make documentation easy and efficient with tools like Loom, and save yourself and your engineers’ time on quality assurance and beta testing.
Ahead of a major release, Wyzant’s product team got into the habit of giving the upcoming release version to CS agents prior to launch for additional edge case testing and confusion. Again, this level of collaboration is a win for product with fewer missed edge cases, a win for CS by being a part of the development process, a win for customers with a hardened experience, and a win for the company.
If your product team can think of CS as a bridge to customers, you’ll be able to get higher-impact work done. CS teams will feel more empowered, involved and included in their work, and have more visibility and confidence about where to spend their own time because they know what the product team is focused on and why.
Benefit #2: Create a Common Language
Without aligning on common terms for talking about customers, problems, and the work meant to address them, teams can find themselves speaking the same language in different dialects. And establishing common sources of truth can help ensure that product and CS are aligned on priorities, goals, and wins as they collaborate.
Create Issue Categorization Together
In a silo, CS teams will often categorize tickets and a tagging system based only on how they plan to use the data — most likely to inform staffing decisions.
CS teams use metrics like ticket volume and time per ticket to measure productivity, and categorizing issues under different tags can help to inform the expected service levels (SLAs) of these metrics across issues that might require different efforts and time to resolve.
While this works well for customer service’s unique use case, their taxonomy may not be as actionable for the product team. Product teams structured around a specific customer, use case, or lifecycle stage often think of product experience more holistically than the granular and functional orientation of CS ticket tags.
Without a common language, it’s easier for PMs to ignore the issue data and move on to more easily actionable data.
To get around this problem, sit down as a group and come up with a taxonomy that aligns with how PMs view the product too.
When we did this at Wyzant, the new taxonomy was more straightforward (less work for agents!) and aligned with macro themes rather than feature level issues. All of a sudden, the summary stats that CS shared via weekly recap meant something to the PMs.
Sunshine the Product Roadmap in Advance
The costs of context-switching are real for product and tech teams. The best time to knock out smaller feature requests or bugs is when the product team is already focusing attention and energy around that part of the product.
PMs who foster visibility and conversation around their product roadmap create space for others within CS, sales, or other teams to surface relevant insights that can supplement product discovery. This is an easy way to knock out a lot of low-value bugs or annoyances that otherwise aren’t severe, or high-volume enough to be escalated.
This visibility allows CS teams to surface existing functional pain points and can provide design direction and reduce the discovery cycles. Hearing "Hey, I know you are working on referral soon — here's a summary of the currently reported referral issues and feedback.” is a PM’s dream! Bonus points for including customer details so that product and research teams have a primed list of customers for user research.
Create (and Close) the Communication Loop
After all this effort to improve alignment between CS and product, it might seem unnecessary to close the communication loop between high-performing and well-collaborating teams. But it’s actually the most important step.
Retroactively examining mistakes is important, but also reflecting on what went right is an even more effective way to cement best practices, and communicate the impact and value of everyone’s hard work.
It’s the reward and “aha moment” within this habit loop. Just like in creating habits for our customers, we can apply the same behavioral principles to how we work.
Celebrating (or at least communicating) the work that’s been done, the CS issues it resolved, and the team effort that drove the impact can help fuel the loop repeatedly.
At Wyzant, PMs met with the support managers to discuss upcoming work and new issues monthly. It became kind of like a mini planning meeting with CS. Through physical meetings (rather than email or slack) we realized that indeed a lot of the issues customer support was bringing up were useful and getting addressed, but the PMs were not closing the communication loop when a bug was fixed. The meeting and agenda helped everyone see the impact of the Support agents, and share overdo kudos.
Benefit #3: Establish a Culture of Joint Objectives
After creating a shared language, you can begin to build alignment around goals — making sure both teams are focused on the same pain points and most important customer outcomes.
Operate Off a Single Source of Truth for the Priority Roadmap
When product teams communicate roadmaps and rationale behind the work, it helps provide CS teams with context on the types of problems and product features that are already top of mind for product strategy. CS teams can then effectively select and screen the insights they share to the product team, improving the signal to noise ratio.
On the other side of the same coin, knowing what’s intentionally not getting prioritized can also help CS leaders decide how to handle training and response efforts for issues that are not a strategic focus.
Set Scaleable Outcome Goals for CS Teams
For CS leaders, another effective way to build alignment is to set team metrics in a way that’s aligned to the company strategy. Ensure that the primary CS team metrics are outcome metrics, not output or health metrics.
If your company is data-driven, the CS team should be too. If the CS data lens is focused on volume, those metrics do nothing to tell a team if they’re successful. Tickets and SLAs are important health metrics, but with scale, they will always grow (more customers = more tickets). In fact they often work against the team, feeling like they are drowning in volume. Spending time to align CS metrics to company goals makes sure the team is aligned on the outcome metrics that matter.
For PMs, you can achieve a similar outcome by making one of your KPIs a metric that aligns incentives: decreasing tickets, decreasing severity, decreasing ratio of issues to core revenue driver, are all examples.
At Wyzant, a primary metric was a support-request to tutoring-lesson ratio. It helped us measure our ability to scale non-linearly, while also measuring a better customer experience as we grew. It also led the team to think about ways to improve efficiency independent of engineering, while also prioritizing high value engineering work. This created a sense of autonomy and ownership within the CS team, improving morale and opening doors for professional development.
Within product, the online tool team had a similar metric: online-tool-support-request to online-tutoring-lesson ratio. While we scaled the online learning tool, it was important that we maintained a high quality experience.
Establish Points of Contact
PMs don’t have the bandwidth to talk to 30 different people when gathering CS input, nor do CS agents. Set up teams to have a single point of contact, or liaison, for each side.
“At Quizlet, each cross-functional product squad had an embedded Product Support Specialist (PSS) who was the interface between CS and the development teams.” explains Natalie Rothfels, Reforge OIR and former product leader at Quizlet. “This enabled everyone to have a shared understanding of the product strategy.”
Your liaisons can communicate strategy, planning, and forecast issues before they become blockers. “We all had a sense of the big themes that we knew we'd be doing work around, and the PSS could more easily group issues coming in across CS channels in a way that was directly tied to current or future work,” says Natalie. “The PSS would share a biweekly recap of those issues with the full team, which gave us a consistent pulse on user feedback.”
Quizlet’s Product Support Specialists helped the product team deprecate a frail feature that few customers were using. “Even though we were confident this was the right call for the business, a fraction of a percentage of tens of millions of customers is still a lot of people impacted,” Natalie described.
“In advance of the deprecation, we coordinated with our PSS teammate to document everything we were likely to hear from customers,” she says. “We anticipated we'd hear from a lot of angry customers (which is never fun!), so we made sure we had a way of tracking the issues in advance. We also checked in weekly to review if what we thought was going to happen actually did end up happening. Indeed, we were hearing from many angry customers. But doing this kind of pre-mortem helped us to anticipate this outcome rather than be surprised by it, which would have likely caused even more frustration and concern from the CS team."
What Happens When Customer Service Becomes an Extension of the Product Organization
The result of implementing any of the strategies we’d covered here is the same: Product and CS leaders create a win-win-win situation for the business:
The product team wins by:
Being closer to the customer, and avoiding the trap of missing key customer insights early.
Having the extra hands of the CS team aligned and focused on product’s top-priority work, instead of feeling like their roadmap isn’t being respected.
Having more time to focus on strategic thinking, instead of low leverage bug tracking.
The customer service team wins by:
Understanding the value of their work, and directly contributing to strategic company initiatives, instead of spending time and energy cataloging issues that won’t get prioritized.
Being exposed to other internal teams, potentially leading to career growth and opportunities.
Enjoying higher morale and motivation, instead of feeling unheard and undervalued.
And finally, the customer wins by:
Enjoying a vastly improved experience — supported by both a customer-driven product and happy customer service agents.
These Same Dynamics Apply To Other Functions
These concepts aren’t unique to CS teams. There are likely other functions in your organization where this same dynamic is happening, like sales or marketing teams, within B2B or enterprise companies.
Your job as a product leader is to help set up the scaffolding to make high leverage collaboration easy, encouraged, and productive.
If you’re in a leadership position, here are a few things you can do today to expand this win-win-win collaboration across more parts of the organization:
Identify the weak link in your current product development pipeline and which internal team may have deep (or at least untapped) expertise in that domain.
Spend time with leadership on the internal team to understand the company from their perspective. Ask a lot of questions and listen to learn, rather than answer or defend.
Think about where the two teams would benefit from aligned incentives and where each group is operating from an information deficit.
Start small. Can you trial a new way of collaborating with one pod, or on one specific project? Success is contagious.
Tools not rules. Like most Reforge concepts, adapt and apply the ones that work best for your circumstance. You can make progress towards treating other groups as an extension of the product team by trying only one or two of the above suggestions.
Give it time. Internal alignment changes like these are based on healthy departmental relationships, and relationships take time to build and even longer to mend.
Investing time in relationships builds empathy and leads to collaboration and diversity — all necessary attributes to building a successful product-led-growth company.
