I answered support tickets for the first six months of the company. Then I stopped, and within a quarter we had shipped three features nobody asked for. The inbox knew what to build. I had stopped reading it.
Support is the cheapest, highest-signal product research function a small company has. Customers tell you precisely what’s wrong, on their own time, in their own words. They give you a paid panel of users who are willing to write down what frustrates them — for free. Then most teams hand the inbox to a CS hire whose job is closing tickets fast, and the founder never reads it again.
What you lose when you outsource it
Three things, in order of which one hurts first:
- The wording. Customers describe problems in language your team doesn’t use. That language is also how prospects describe the problem on calls. You lose the vocabulary if you only see closed-ticket summaries.
- The frequency. “How often does X come up” is the question every roadmap argument turns on. The CS team knows the answer; the founder learns it third-hand and gets it wrong.
- The shape of the bad questions. The questions that “shouldn’t” be there — “how do I X” when X is documented — are the ones where your docs failed. You only see those if you read tickets.
What the founder should actually do
Read tickets for an hour every Friday. Not closing them — reading them. Look for: the same question asked three different ways, the workaround a customer described that’s better than your intended flow, the feature request that’s actually a bug they’re working around.
The CS team can close the tickets. The founder reads the inbox. These are not the same job.
The honest part
It’s tempting to stop because tickets are unpleasant. Some are angry. Some are confused. Some are written badly. That’s the job. The unpleasantness is the signal. A company where the founder thinks “support has it under control” is a company that’s shipping the wrong things, on time.