Most startup advice tells you to get on sales calls. Close deals. Talk to prospects.
I do the opposite.
I spend 3-4 hours every day on customer support calls. Not sales. Support.
This isn’t a philosophical stance. It’s a strategic decision that has shaped every meaningful product improvement we’ve shipped.
The Case Against Sales-First Thinking
Sales calls tell you what could work. Someone imagines using your product and shares hypothetical use cases. They describe problems they think they have. They react to features they haven’t actually used.
Support calls tell you what doesn’t work. Someone has actually used your product and hit a wall. They’ve built workarounds you never anticipated. They’re frustrated with gaps you never considered.
One is speculation. The other is evidence.
When you’re building a product, evidence beats speculation every time. And the richest evidence comes from people who are already paying you, not from people you’re trying to convince.
When Founder-Led Support Makes Sense
I don’t do this forever. There’s a specific window when founder-led support delivers the highest ROI.
Every new product launch. The first users of any new product are your guinea pigs, whether you call them that or not. Their struggles reveal assumptions you didn’t know you made.
Every major feature release. Features rarely ship perfectly. The gap between what you built and what customers expected shows up in support tickets within days.
Until the patterns stabilize. I typically do 6-8 weeks of daily calls after any significant launch. By then, the common issues surface repeatedly and the solutions become clear enough to document.
After patterns stabilize, I step back and let the team handle support with the playbooks we’ve developed together. But during that initial window, my presence on those calls is non-negotiable.
The Four Signals I Listen For
Support calls aren’t just about solving problems. They’re intelligence gathering missions. Here’s what I pay attention to:
Words they repeat. When a customer uses the same word or phrase multiple times in a single call, that’s a priority signal. Repetition indicates what matters most to them, not what they mention in passing.
Workarounds they’ve built. Nothing reveals product gaps like discovering a customer has duct-taped together a manual process to accomplish something your product should handle. Every workaround is a feature request in disguise.
Emotions in their voice. Frustration, relief, confusion, delight. These emotions tell you severity in ways that ticket categorization never will. A calm “this doesn’t work” is very different from an exasperated one.
Questions they’re embarrassed to ask. When someone hesitates or apologizes before asking something, you’ve found a UX failure. If a reasonably intelligent person feels stupid using your product, that’s on you, not them.
The System That Makes It Work
Raw insights are worthless without a system to capture and act on them. Here’s my process:
Step 1: Log every call. I keep a simple document where I capture key quotes, issues raised, and emotional temperature. Nothing fancy. Just a running log.
Step 2: Tag by theme weekly. Every Friday, I review the week’s calls and group issues by theme. Patterns emerge quickly. The same problem showing up in five calls is more important than five different problems.
Step 3: Share raw quotes with the team. I don’t summarize or interpret. I share exact customer quotes in Slack. Raw language hits harder than polished summaries. When your engineer reads a customer saying “I wanted to throw my laptop out the window,” that lands differently than a ticket labeled “moderate frustration.”
Step 4: Prioritize by frequency plus emotion. Roadmap decisions factor in both how often an issue appears and how strongly people feel about it. A rare but rage-inducing problem might outrank a common but mild inconvenience.
What This Approach Actually Produces
Our best features came from support calls. Every one of them. We heard the same frustration repeatedly, identified the pattern, and built the solution.
Our worst features came from assumption. We thought we knew what customers wanted. We built in isolation. We were wrong.
There’s a reason founder-led sales gets all the glory. It feels proactive. It’s associated with revenue. Investors love hearing about it.
But founder-led support builds the product that sells itself. It turns customer pain into product improvements. It creates word-of-mouth that no sales call can generate.
The Question You Need to Answer
Most founders drift away from direct customer contact as their companies grow. It’s natural. There are more demands on your time. You hire people to handle support.
But here’s the trap: the further you get from customer pain, the more you rely on secondhand information. Reports. Dashboards. Summaries. Each layer of abstraction removes texture and nuance.
So ask yourself: are you still close enough to your customers’ pain?
If you can’t describe, in vivid detail, the frustrations your customers experienced this week, you might be too far removed. The solution isn’t to micromanage your support team. It’s to carve out time to hear directly from the people whose problems you’re trying to solve.
The calls are long. They’re sometimes frustrating. They rarely feel urgent compared to everything else demanding your attention.
But they’re also the closest thing to a cheat code for building products people actually want.
What’s your approach to staying connected to customer feedback? I’d love to hear how other founders balance this with everything else on their plates.