For the Future of Product - Build Better. Build With Customer Support.
Originally published on March 20, 2025
Could the secret to building a product your customers actually love be hiding in your customer support queue?
To be clear, not all customers are created equal, and it does make sense to prioritize. You can’t jump through hoops for every user who isn’t really invested in your company or product. But it’s easy to hide behind that justification when you’re avoiding the real issues. Those recurring problems that drive your support team (and your customers) absolutely bonkers.
We all say we’re customer-centric. We slap “user-first” on our mission statements, conduct user research, and maybe even attend the occasional customer support sync. We might do our bi-weekly check-ins with the support team, nod along to their reports, and then promptly forget about it as we dive back into planning the next shiny feature. We might even hop on a call with a frustrated customer to say, “It’s on the roadmap for later in the year!” (It might not be.)
The truth is, it’s easy to think you’re customer-centric when you’re not the one dealing with the daily barrage of support tickets, angry emails, and frustrated phone calls. And that disconnect can be deadly for your product.
Incentive alignment is a tricky beast
For a lot of reasons, you might not solve customer problems right away. Some are good, others...not great.
Good Reason: Maybe you’ve confirmed that an issue only affects a tiny fraction of your users. (Yeah, we’ll add a note to the FAQ and call it a day.) Or maybe solving the problem would require a massive engineering effort that’s just not worth the ROI. (We’ll file that one under “nice to have...someday.”) For example, let’s say your system freaks out when a contract renews on February 29th. You might solve it at the contract level by adjusting the signed date. Or, if it’s a deeper issue, you might just flag those end-of-February contracts and deal with them manually. It’s not ideal, but it’s a pragmatic solution.
Not Great Reason: The elephant in the room, those messy, legacy issues that everyone’s afraid to touch. The ones that would require unraveling a spaghetti code of temporary fixes and confronting some uncomfortable truths about past decisions. Ignoring them won’t make them go away. But, let’s be honest, it’s a lot easier to pretend they don’t exist when you’re not the one fielding the angry phone calls. You intellectually know the problem exists, but you don’t feel the frustration of a customer whose workflow grinds to a halt because of your broken product. And that makes all the difference.
We often talk about the lack of user empathy in the product world, but the best way to build it is to trade the fancy product roadmap for a customer support headset
The Commercial Disconnect
Of course, not all customer needs are created equal. Sometimes, fixing a customer problem means creating a premium feature – something your commercial strategy dictates you should charge extra for. An example of this is CVAT’s on-prem solution. They offer Meta’s SAM v2 model for faster image labeling, which is a huge win for their users. But they don’t give it away for free; you have to upgrade to the Enterprise license to get it. Is that greedy? Maybe. But it’s also a smart business decision. They’re testing “willingness to pay“ and ensuring they can continue to invest in improving the product. The key is to be transparent with your users about why you’re charging for certain features. Explain the value they’re getting and how it benefits the overall product. Don’t just hide it behind an upsell and hope they don’t complain.
But beyond these pricing considerations, there’s a deeper disconnect at play. We often talk about the lack of user empathy in the product world, but the best way to build it is to trade your fancy product roadmap for a customer support headset. Because let’s face it, most PMs have seldom been in the hot seat – the customer support seat.
Customer support teams (or “Customer Success” at the hip and cool places) are on the front lines of customer experience. Their sole job is to deal with problems and solve them ASAP to keep those customers happy. Every support team I’ve worked with has a core group of people who genuinely thrive on that! (I’m thinking about you - Ian Schuster, Paris Good, Lokesh Paliwal, Shashank Kaushik, and Anthony Secco, to name a few) They’re also the ones who have to manage the really pissed-off (and sometimes entitled) customers, knowing full well that some problems are simply unfixable.
A PM might get brought in on 1 in 50 of those “impossible” cases. And that’s by design. If PMs spent all their time firefighting, they’d never have time to build a proactive product strategy. But that doesn’t mean we can afford to be completely disconnected from the daily realities of our users.
So, how do we bridge this gap between these two functions? The answer depends on the size and stage of your company:
Embed one PM with the support team for a week at a time. Think of it like an on-call rotation. Engineers do it by default, so why not PMs?
Small Companies: Let’s be real, you probably are the customer support team. When you’re just starting out, every customer interaction is make-or-break. You’re incentivized to pay attention because one lost customer could sink your whole year. The key here is to document those early customer interactions. Create a system for tracking common problems and feature requests, so you don’t lose that valuable knowledge as you grow.
Growth-Stage Startups: This is where things get tricky. You’re starting to formalize roles and responsibilities, and it’s tempting to offload all customer support to a dedicated team. But resist the urge! I’ve seen too many startups where PMs start shifting their focus to new features and “high-impact” projects, leaving customer support in the dust. They’re still building things, for sure, but they’re prioritizing the new over the necessary. The biggest warning sign? When team members start prematurely calling for rigid role definitions. (Translation: “I don’t want to deal with that anymore!”) Don’t fall into that trap. What works best is leadership alignment. Make it clear that customer support is everyone’s responsibility. Otherwise, your team will always default to the excuse: “We can only work on revenue-generating things right now. We have a target to hit!”
Large Companies: In larger organizations, there are often good connections between support and engineering, but a million layers of bureaucracy to get anything prioritized. One solution I’ve seen work well is shift rotations: embed one PM with the support team for a week at a time. Think of it like an on-call rotation. Engineers do it by default, so why not PMs? It breaks down silos fast. Of course, you need to free up capacity for this, and that requires leadership buy-in. This has to come from the top, or no one will feel comfortable stepping away from their “real” work.
A large distance between Empathy and Compassion
You’ve likely heard your colleague say something like “I love our support team, such great people! But I wouldn’t touch that job with a 10-foot pole. It’s just not my thing, you know?”
Look, I can buy the argument that some people are better equipped or built for a type of job or role. I definitely don’t have the relentless optimism a sales person will carry to deal with 10 rejections a day. However, if we’re being quite honest with ourselves, the real reason we’ve heard or said the above is because we like working in a job where the real consequences of our actions are externalized and the benefits of a successful outcome are more likely to be received by us first. We did create the superb strategy, after all. We’re the mini-CEO of the company! 🙄
Sure, sales gets that fat commission. Maybe the real CEO will take credit for what you and your team did, your boss will too. But this is how you’ll get promoted and a pay bump. A year from now, you’re likely working on a different team or product with a different set of responsibilities, but someone is going to be left holding the bag to deal with the problems you left behind. Another engineering team, another PM, and also...the entire customer support team.
The Enduring Product
I’m not saying you need to cover every single edge case or write a million smoke tests before shipping a new feature. I’m also not saying you should spend five months building something that should take five weeks. And I’m definitely not saying you need to stay a PM on the same product for five years. What I’m saying is: True ownership comes from building an enduring product. A product that customers are willing to recommend to others. A product that generates the fewest support tickets per user, per company, per dollar. (There’s probably a good non-NPS metric to track in there somewhere.)
So, for however long you’re in charge of a product, take the time to understand what customer support has been dealing with. Put yourself in their shoes. And, most importantly, demonstrate how you’re fixing those problems. You’ll be a better PM for it. You’ll build more allies across the organization. And you’ll build a network that might just save your butt five years down the line, in ways you can’t even imagine right now.
If you’ve made it this far, thanks! Now pick one recurring customer support issue and make it your personal mission to solve it within the next month. Work directly with the support team to understand the root cause, brainstorm solutions, and implement a fix. Not only will you make your customers happier, but you’ll also earn the respect of your colleagues.