Support Work Is Product Work
Support is a complicated and often misunderstood role across almost all industries and products, from B2B SaaS software to luxury widgets. There’s a gap between how products are designed and built and how they’re used by people in the real world. Support Professionals do more than answer tickets, we spend the day in that gap, doing product exploration that goes beyond the boundaries of what your company makes and sells. Aside from being the face of your company (which itself is not a minor role), the Support team is a critical part of your product development engine.
TO THE SMITHY!
Let’s say you’re a blacksmith who makes cast iron skillets. You make one shape of skillet but you make it really well, so you open a small shop in town where you can make and sell them. When customers come in, you stop what you’re doing (presumably making more skillets) to attend to them. You like talking to folks who like your skillets. You build some relationships with people in town, and start getting repeat customers who own restaurants nearby.
Word gets around. Business picks up. And the interruptions slow you down. So you hire someone to handle customers at the front of the shop while you make skillets behind them. You can still see the customers and talk to them occasionally, but you can also focus on your work. You’re making more money and everyone is happy.
The person who handles the sales, though, is getting busier and busier. They’re selling skillets all day but they’re also handling returns, questions, and complaints, so you hire a second person to take on the post-sales work. Anyone who needs a refund or a repair goes to the new person’s counter to have their situation handled by someone with time to focus on them.
You’re busy making skillets so you don’t have time to follow up with every customer, but you talk to your employees every day to see how things are going. Sales are up, returns trickle in, you get a handful of pans to repair every week, and things are going well. The sales person tells you what’s going well and the support person tells you what isn’t, but not in detail. Just enough to make sure things are running smoothly. Revenue’s up, so it’s fine.
But the detail’s important. People return skillets for different reasons (not big enough, too deep, too heavy, not heavy enough). A lot of them do have the same reason, though; the handles get too hot, which makes them hard to use. Something in the design needs a tweak, but you never hear it.
I think you get the point, and none of you are making skillets. You’re probably making software, but your Support team is in a similar situation. They’re getting loads of product feedback but you aren’t hearing it with the kind of detail you got when you were talking to customers directly (assuming you did at some point). All this customer feedback is in your helpdesk with a couple dozen (or a couple hundred) tags. Or maybe Support creates Jira or Linear or GitHub issues for the Engineering and Product teams, but it’s never clear how those relate to the current product roadmap or the company’s strategic priorities. So the feedback gets shuffled to the back of the queue to deal with later, if ever.
The problem seems obvious when it’s three people in a small shop. Why aren’t you, the blacksmith making the skillets, talking to customers or getting better feedback on your product? The customers are right there. Why isn’t your employee giving you information in ways that can help you decide what to change or improve or how to expand your product line? It looks easy, but even three people in a room can be so heads-down that they stop sharing useful info, and when that expands to a couple hundred people you don’t always realize how disconnected you’ve become from the customer. When the little blacksmith shop becomes a plant with smiths and designers and product managers and engineers and quality assurance directors, it’s not clear who should be getting what feedback in the first place, let alone how.
FEEDBACK LOOP, ACTIVATE!
A true story: There was a Support team of about 10 people who would get lots of product feedback from customers. Sometimes it was explicit feature requests, but often it was a customer problem that could be solved with some change to the product. There wasn’t a bug, but there was a difference between the customer’s expectation and their experience. This team would save all those nuggets of informative feedback and in markdown files organized by month. There the feedback would sit, waiting for Product. Forever.
This sounds terrible to you, maybe. Or familiar, because let me assure you that lots of teams are doing something similar right now. Or they’re doing even less, because many Support teams are tasked with talking to customers and not with solving product problems.
Once you see it, you can’t unsee it. Support teams are part of the product development cycle, but they’re usually completely disconnected from that cycle. Product teams aren’t getting useful information from Support and are therefore missing key feedback that should be informing product decisions.
We’re just turning off a feedback loop that already exists. How do we turn it back on? You’ve probably heard people talking about “Support getting a seat at the table” and this is what we mean. Talking up the “value” of the team isn’t going to earn us more than some kudos and a pizza party. What we want is to be part of the process that continually improves what we offer customers.
Some larger companies have Voice of the Customer programs (VoC) built around the idea that customer feedback should be filtered and funneled back to Product teams. This is great! It’s also strange that it has to be a specific program with a specific owner instead of a core part of the Support team’s role. Waiting until you’re big enough (in headcount or customer count or revenue) to implement a VoC program means you’re wasting information. It should be a given that Support is responsible for taking feedback, data, and customer stories back to the Product team.
Lots of companies are trying? But more are getting it wrong than right.
WHO SAID WHAT TO WHO, AND WHY
The worst is when Support teams put a bunch of work into packaging up their data and sending it to Product, and it’s ignored.
Your Skillet Support Representative spends all week talking to customers and handling returns and handing off repairs and answering questions about the best way to fry eggs. At the end of the week, they write up a five page report about everything they’ve seen and heard and hand it to you. You skim it, see some notes about butter vs. oil that don’t actually help you make skillets, toss it aside and get back to what you were doing. Your rep feels crappy. Customers keep burning their hands on skillet handles. It’s a lot of work, and it’s not helpful to anyone.
In many companies, Support eventually stops packaging up feedback and tells Product they can search the tickets if they want and that’s that. Everyone goes back to their siloes. Their angry little siloes.
Other Support teams put together weekly, monthly, and quarterly reports with reams of customer data, quotes from real tickets, and lists of work that Support thinks should be prioritized. Then they get mad when the Product and Engineering teams glance at it and put it to the side… but usually haven’t asked why it didn’t help. Did it come at the wrong time? Was it all irrelevant to what the other teams are focusing on right now?
You don’t know if you don’t ask, so what if Support asked Product what it wants? You’d be amazed how easy that is to answer and how infrequently Support teams ask. Product teams already have a strategy and a way of managing what they’re working on. Throwing information that doesn’t relate doesn’t clarify anything, so they ignore it. So ask. Ask what they want to know more about, how they want to see that information, and what kind of data helps them right now.
Where do you start these conversations? Here:
- What kind of customer feedback would be useful?
- What data, if any, would help your decision making?
- What do you NOT care about right now? What information is getting in your way?
- How often do you want this information, and when is it most useful for you to receive it?
That Support team that was putting all its customer feedback in unread markdown files eventually sat down with some Product Managers and talked about what kind of information was useful to them. Not just “product feedback” but “feedback about features A, B, and C from customers in cohorts X, Y, and Z.” Support couldn’t have guessed exactly which parts of the product were most important to the other teams at that moment, and they wouldn’t have known how Product was thinking about customer cohorts. Until, of course, they asked. It wasn’t a complete and perfect solution, and there was still some friction between teams, as there always will be at large and growing companies. But it was a start, and every month the Product Managers would come back with feedback for Support on how to iterate on their data to make it even more valuable.
Support teams want a seat at the table. We want other teams to listen to us. We have valuable insight. But sitting at the table requires us to speak the language other teams are using, and to focus on the topics that other teams are talking about.
Sometimes you’ll bring in a new topic. “Hey, I know we’re focused on features A, B, and C right now, but we had a spike in questions about feature D the past few weeks. There might be something there worth exploring.” Sometimes that’ll raise more questions and pique the interest of other teams. Sometimes it won’t and those other teams will think it’s a distraction and THAT IS OKAY. The role of Support is to feed customer information back into the company. The organization as a whole will determine what is useful and valuable and actionable.
Sounds easy? Well. It’s not. But it’s simple. It’s just talking.
Go. Right now. Go talk to your Product Managers and figure out what would help the product. Make sure your feedback from customers gets translated into something that improves the product and company. You all work as one big team, and thinking of Product and Support and Engineering and Design as isolated organizations that don’t know how to talk to each other is holding everyone back. Everyone’s gotta pull up a chair.
Have a comment or a response to this post? Take it to Bluesky or LinkedIn.