"Your credit report has changed."
That's the subject line of an email you receive from a popular credit monitoring service.
Expecting praise for aggressively reducing your debt, you're surprised when you open it. The email says:
"Hello customer,
There seems to be a change on your TransUnion credit report.
You were late in the payments of one of your accounts.
Do you recognize this new information?"
So you check the credit report with TransUnion where your suspicion is confirmed. There are no missed payments. You reply to the email requesting an explanation. When support responds, they ask for information to verify your identity: full name, social security number, date of birth.
Two days later, you receive an automatically generated email. Your request was resolved, but no, it's just another automated email where they don't explain anything to you.
Annoyed, you reply again, this time to demand an answer. Instead of giving you one, the employee keeps avoiding you. He/she sends you a long response detailing how credit scores are calculated and says nothing about faulty notification emails from the company. Therefore, you decide to delete your account.
This happens very often. And it's not because support representatives enjoy unproductive conversations but because customer service and products only get involved when they need to.
Support and product have a lot in common. Both teams work to create positive user experiences, and both know the product better than most people in your organization.
They are not strangers either. According to Tony Ulwick, pioneer of the job-to-do theory, customers "hire" products and services to perform specific jobs.
When those jobs don't deliver as expected, customer service serves as a safety net, a way for companies to bridge the gap between what customers need and what they get. In practice, this often includes:
But despite the inevitable contact, and proximity to the product, most customer service, and product teams don't share their knowledge to proactively improve the customer experience.
But, their relationship is very important and both teams must be prepared to react. The support team reacts to product issues by sending them to the product team. The product team reacts to support requests by raising issues and, in many cases, talking to a developer to find a solution.
This dynamic can keep companies with a modest customer base, but as a business grows, a purely reactive relationship can become a problem. In extreme cases, such as when a company's product consistently fails to "do its job," both teams grow to resent each other for hurting their respective productivity:
Amid these tensions, customers suffer, products stagnate, and members of each team have much less appreciation for their work (and each other).
Worst of all, the gap between what customers want and what an organization can offer widens, paving the way for competitors with similar solutions, and better alignment across teams, to gain market share.
Here's the good news: When you join forces to navigate customer issues before they happen, products can be better developed, support can be better served, and your organization can earn a reputation for being customer-centric, the ultimate in competitive advantage.
That's how:
Mistakes are more than an unavoidable part of doing business. They are a considerable source of tension between customer service and the product.
Like the people on the front lines, support wants bugs fixed as quickly as customers, but pressures at work often get in the way. From managing first response times to getting the information needed to file a report, support representatives stay spread out across multiple tabs and systems.
Product teams don't worry about this when they get mind-boggling bug reports. They worry about getting the information needed to replicate the problem. When tech support can't deliver it, they delay the problem, usually to an overwhelmed agent who hoped it was clear enough the first time.
If the steps to reproduce are too vague, or if there are two separate issues lumped into a single ticket, too many support representatives waste time writing bug reports that the product team hates to read.
Here are two ways to solve it:
1 - Reconfigure your bug reporting tool: To produce bug reports, the product team can act quickly, support teams need an ongoing process. Each entry should be programmatic, like autocomplete dropdowns, so representatives don't waste time thinking about what to enter.
Manual data entry should only occur in one field - steps to reproduce. For clarity, tell representatives to conclude each report with an expected result and an actual result.
Consider investing in something more robust if your current tool can't connect with other systems or allow the flexibility to create reports on products or features.
2 - Rethink product development resources: Product teams must balance bug and code management with new product development, which is no easy task.
Some engineers see debugging as a valuable experience that helps them become better developers. Others see the process as a time-consuming task left to junior employees. Then there are the people who just enjoy the thrill of figuring out something mysterious.
It's likely your company has all three on the product team. Depending on their backlog, they have a few options:
Products inevitably break into big and small shapes. To reduce customer downtime, every business should strive to resolve these issues as quickly as possible. To do so, they must first reduce employee friction.
Feature requests can also fuel tension between the support team and the product team.
Without looking at the overall goals, customer service representatives can easily support ideas about features they think will have the biggest impact, even when the product team knows better.
They may even frame their ideas as fully realized quick fixes that the product can "easily" address without noticing other dependencies.
For product teams, this lack of awareness leads to skepticism around support-based feature requests. If they aren't monitored, they begin to view supportive comments as anecdotal or overly emotionally driven and can become dismissive as a result.
To eliminate these perceptions, the customer service team and the product team must align around what makes a feature request compelling.
Here are two starting points:
1- Data: For your requests to be taken seriously, the customer service team must validate product recommendations with as much data as possible. There are a few ways to approach this:
Any of these options can help your support team identify which products or features create the most friction for customers. Attaching these data points to feature requests will help the product team understand the business case behind them.
2- Context you describe, not prescribe: Product development is not just about adding new things. It's about identifying a customer's problem and devising elegant, holistic solutions.
This is why product teams are more responsive to feature requests that describe the issue associated with a request. They don't need support representatives to prescribe a solution.
Here is the difference:
| Descriptive | Prescriptive |
| As a user, you should be able to return to the app from the dashboard so that... | Put the 'Back to App' button on the dashboard |
When support defines the problem rather than mandates a product-specific solution, it indicates that they understand that there is more to consider than the immediate need.
While support teams should never dictate product actions, they can and should use descriptive context to create recommendations that ideally reduce the volume of certain types of tickets.
How customer service retains feedback is just as important as the feedback itself.
For small teams, this usually starts in spreadsheets, but if your team supports multiple high-profile business clients or a global client base, these makeshift methods can quickly get messy.
No matter how hard your team tries to make them all-encompassing, it will be impossible for the product, or tech support, to capture the full picture without switching between multiple systems.
This may not seem like the end of the world, but it's not scalable or efficient. In its analysis of how high-performing, innovative organizations get ahead, Slack found that they share three common traits. Employees in these companies:
For an organization's customer service and product teams, this means investing in purpose-built software that not only captures product feedback but can also quantify it and meaningfully connect with the systems these teams already use.
The best support representatives know the product and its team. What they don't know is what hurts them: the big picture and all its necessary complexities.
Regular meetings can solve this. In addition to building rapport, they enable a company's customer service and product teams to build trust through transparency.
Here are some ways to take advantage of product team meetings and support:
1- Train new agents on features and functionality: While your team can certainly train representatives on how to perform certain actions, the product can provide broader context on the origin, evolution to date, vulnerabilities and product shortcomings, valuable context that new and existing representatives can use to personalize their interactions and speak with authority.
When support representatives serve a wide variety of use cases, they are more prepared to set customers up for success.
2- Provide clarity on the complexities of the product. Some product features can be inherently complex, but customers expect support representatives to be experts regardless. When they are not, your customers will react in one of two ways:
They are also likely they end up the communication being confused and upset by spending time on an unproductive conversation, especially if the support team provides inaccurate information.
By making it a priority to turn support representatives into bona fide product experts, organizations can ensure quality and meaningful service.
3 - Stay ahead of support documentation: As a product evolves, support must do more than learn new features and functionality. They're also on the hook for creating and updating FAQs, email macros, and any other messages they use to educate and inform customers.
Meeting regularly with the team to discuss the product roadmap and upcoming updates allows customer service to gain the information needed to get a head start on support content.
4- School product on adoption and trends: Product teams may have their means of identifying user engagement, but qualitative feedback support can provide them with greater impact than numbers alone.
Customer service representatives can share data on which products are generating the most questions or confusion, what types of questions customers are asking, and what feedback they've offered.
Given the opportunity, the product can ask questions about feedback and assess how to prioritize feature requests against its roadmap.
Consumers have several options. If you need a ride, you can hail a cab on the street, but you can also use Uber or Lyft to pre-arrange a pickup. Do you need a help desk? There's Zendesk, Freshdesk, HelpScout, and HappyFox to name a few.
With so many companies embracing similar solutions, true product differentiation is for unicorns. For most companies, increasing their focus on customer service is enough of competitive advantage.
But when organizations promote customer experience initiatives, they often overlook the relationship between product design and customer service. Worse yet, they rarely involve the support team in the design process.
According to various studies, these companies are missing out big time.
The most innovative companies recognize the relationship between a customer's "cost of ownership" and a product's "serviceability."
| Low cost of ownership for customers | High service capacity for companies |
| The product is intuitive and easy to use. | Fewer support tickets and less hand-holding |
| The product satisfies obvious needs and satisfies needs that they may not have anticipated. | Customers are more likely to share praise and “nice to have” feedback that inspires and informs product team decision-making |
Organizations that do not see customer service as crucial to the product design process typically face very different circumstances:
| High cost of ownership for customers | Low service capacity for companies |
| Product "too difficult" or confusing to use. | Fighting support to help customers achieve their goals. |
| Too often, the product can't "do its job." | The product strives to create or maintain the solutions that customers need. |
When the product team makes use of the knowledge of the support team before creating or defining a new product, they can design for real needs instead of perceived ones.
Products consciously designed for ease of use often stand out as an obvious choice in a sea of options. Like the original iPhone, they can even help redefine what customers expect from a product.
The goal of customer service and product alignment is not only to build a better product but also to build a better relationship between teams. To get there, both teams must get the job done.
To help at an organizational level you can: