Support teams talk to customers every day. Product teams need to know what users struggle with and how they use and experience the product. Teams don’t actually know what users are asking, except as anecdotal, gut feel analysis. This problem rarely exists in small startup teams with less than 10 people covering all roles in the company. Everyone sits next to everyone else, and everyone covers multiple roles at the same time. The problems sneak in as the company grows to consist of specialized teams of three or more team members. From that point and up to where the teams are large enough that someone can be dedicated to fixing internal issues like communications with the product team, these problems persist.And we see that the tools commonly used still haven't plugged the gaps we’ve seen filled with manual processes and work-arounds in larger companies that have the resources.
Theme 1: The disconnect between support and product development
This one is ironic, since the support team talks to users every day, and product teams build for users every day. The disconnect happens in stages as a product and a team matures, and usually ends up being a more or less latent conflict between the two teams. From the support teams you will hear complaints about how the product team is only interested in building new features, not fixing the stuff that is broken for the current users.
On the other hand, the product team feels like their time is wasted hearing about minor glitches that affect a few loud customers (and by extension loud support people). Instead of the features or optimizations that they feel will benefit all users. There are definitely tools that help teams list and prioritize issues and features, but there is still something missing.
Theme 2: Teams don't know what users are asking
Companies know a lot (sometimes too much to do anything with it...) about how their support teams operate in terms of response time, resolution rate, agent productivity etc. But they very rarely have more than a cursory understanding of what their users are asking. The occasional unicorn of a team may have some high level tagging of the user's issue (e.g billing vs. login questions), but even when done, it's rarely consistent or granular enough to give any insights.
And tying those insights back to actual improvements in the product itself and in the help that is offered in contextual tips, help articles and so on is the next challenge. When this whole process works, it is usually the result of a fairly complicated process and succeeds despite, not because of, the tools used.
Theme 3: Support does not equal a ticketing system
Most support systems used by both small and large companies are, at their core, systems designed to help teams efficiently answer incoming questions whether as emails or chats. To varying degrees they also offer things like a stand-alone knowledge base, maybe a chat widgets to embed in the product, in some cases even a help widget embedded in the product which gives access to knowledge base articles. What generally characterizes most of those functionalities is that they have been added on to a core that is the ticket management system.
That is fine (at least temporarily) if efficiently replying to questions is the main concern. But for very early stage teams quality of input into product development is usually more important than resolution rate or email response time. And at later stages, the efficiency gains from making systematic improvements at the top of the user's question path, usually outweigh any local optimization of, what should already be, a well-oiled support operation. But ops people are great at optimizing agent workflows, so they keep hammering at the nails they see.