What Three Years in Support Taught Me About Building Product

Customers show you the gap between what is built and what is needed

In support you see the workarounds. A customer exports data to a spreadsheet because a report does not quite fit, or repeats a manual step every month because a workflow stops one step short. None of that shows up in a feature list. It shows up in the questions people ask.

Those workarounds are some of the clearest product signals there are, because the customer has already shown you what they are trying to do.

One ticket is a story, a pattern is a priority

A single complaint can be loud without being important. What matters is when the same kind of problem keeps coming back from different customers. Learning to notice those patterns, and to bring them to product owners with evidence, was my first real taste of prioritisation.

Severity teaches you to rank

Support queues force you to decide what comes first. An issue that blocks a business from closing its books outranks a confusing label, even if the label generates more tickets. That same thinking applies to a roadmap: how many people does this affect, and how badly?

Empathy is a working skill

It is easy to say you understand the customer. It is harder when you have spent the day with someone who cannot get their invoices out. That experience makes me careful about edge cases and about what happens when something goes wrong, not just when it goes right.

I still start with the problem

Now that I own modules in Zoho CRM, I write PRDs, run customer research and plan sprints. The habit I brought from support is simple: understand the problem in the customer's words before deciding what to build.