How To Be Heard By Your Product Team
Your customers know what they want from your product, and you know what your customers want from your product. You’ve given that information to the people who build it, and they seem to listen carefully… but the changes just don’t happen. Two teams, both responsible for the customer experience, who are seemingly unable to make obvious improvements. It can be incredibly frustrating.
What’s going on?
The problem is (probably) not that your product team doesn't care or that they don’t trust valuable ideas from the support team. It’s not a personal problem, it’s a communication problem — and that’s good news because communication problems can be fixed. So let's go!
Top 3 reasons your product requests aren’t happening
Based on my experience leading Help Scout’s product support analyst team and from talking to tons of people in similar roles, here are the most likely the root causes of your requests not being prioritized:
Missing data: Your request feels subjectively important, and it may well be, but you don’t have convincing data to back up your feelings.
Lack of road map awareness: You don’t fully understand why or what your business is working on, so you can’t make sense of their decisions.
Impossible Monoliths of Doom: Your requests are too huge or too vaguely defined, so your product team can’t realistically scope out the work that would need to be done.
These are all solvable problems, but fixing them will take some work upfront as well as some ongoing effort. Here’s how to get started.
Building an effective feedback process
When you are in support, you have a superpower: It’s your ability to deeply understand the customer’s perspective and how they relate to your product.
Creating an effective feedback process means making use of that power to share your perspective with your product team in a way they can understand and use. You want your team to represent and amplify the voices of your customers into the rest of your company. To do that, you’ll need to collect the right data, then communicate it in a way that suits the needs of your product organization.
1. Get to know your product team The better you know your audience, the more effectively you can communicate with them. Make an effort to connect with and understand the people on your product team so you can share your requests in a way they are most likely to understand.
Find answers to questions like:
Who are the product decision-makers?
Who are the other stakeholders?
What motivates them?
How do they decide what to work on?
What format of reporting do they prefer?
You can learn by reading their documentation, attending meetings, speaking to other parts of your business, and by just asking directly for insights.
2. Organize and enrich your data A product request that is backed by data is more compelling, but it takes more than slapping some numbers on the table. The system you use to track your requests and issues should be:
Scalable — It should keep working effectively as your team and your customer base grow.
Easy to implement — It should not add enormous friction to the work of the support team.
Accessible — It should capture and store data in a way that interoperates with the data that your product and other teams already use. That probably means going beyond your basic help desk reporting and integrating your support data with your business’s customer and product data. If your internal teams use a business intelligence tool, that’s where you’ll want your support data as well.
A key step to making a workable data system is figuring out which questions you want to answer with data and working backward to understand what information you will need to record.
Typically you will categorize conversations, capture requests, and snag bothersome bugs. When you’re doing that, try to match the language and the tools your product team is already using so they don’t have to translate your data into something that maps to their existing knowledge. For example, if your product org uses Jira to prioritize work, your bug and feature requests should be tracked and managed in Jira as well.
Consider building a request template to help your team be more consistent and more thorough with how they record customer requests. Combine it with some saved replies that encourage them to ask the right questions to really understand the underlying customer need.
Here are three core questions your feature request practice should aim to answer:
What are the customer’s expectations?
How critical is this issue for this customer?
What value would this bring to their team?
A tale of two feature requests
Here’s a common situation. Two customers ask you for exactly the same feature — in this case, it’s more colors to apply to the tagging system in your app. Those requests might sound quite different, depending how your team engages with feature requests in your queue:
Example 1 | Example 2 |
---|---|
"I need more tag colors!" | “I’m really struggling with organization in a shared space. If I had more tag colors to work with, my team could visually distinguish the things they need and manage tasks significantly easier across functions” |
The temptation for a busy customer service team is to just add two votes to the existing “more tag colors” feature request. But that’s leaving valuable insights out of the equation or up for assumption. A well-prepared support team can turn the first type of request into the second type just by asking a good follow-up question and digging in deeper.
In this case, you learn that your customer is struggling with organization and can’t work effectively as a team using your tool. More tag colors is the solution that they have imagined, but it is not the only possible solution. By taking one additional reply to understand what’s at the heart of the customer’s request, you’ve surfaced research gold for your product team — the problem behind the customer’s solution request.
Your product team can do a much better job with that additional context, and they may come up with changes that are completely unrelated to colors but will still help address the needs of both customers.
3. Be a storyteller Saying “100 people asked for this feature” is useful, but insufficient. It’s leaving out the business impact of the issue at hand. How is this “missing feature” affecting the goals of your company related to things like churn, conversion rate, or feature adoption?
Taking your detailed feature request data and aligning it with company data from your business intelligence tool will give you a more thorough, contextual story to tell.
Then, take that data and attach it to specific stories from real customers. Help your product team understand the broader reality of the impact by combining data with a strong narrative.
4. Align the support and product teams The more strongly connected your support and product teams are, the easier it will be for them to understand each other's needs and concerns.
At Help Scout, we have codified a product support analyst role that embeds support professionals into product teams. As they work together over time, their understanding of how decisions are made improves, and they can spot opportunities to efficiently slot in fixes and improvements to the roadmap.
Be a better bridge builder
When your new feedback process is working well, you will have all the elements you need to create the change you want to see.
When you make requests that are data-backed, context-aware, and well-defined, you are giving your product teams everything they need to make more informed decisions. You may not win every battle, but you’ll be much more successful than you even imagined possible.