Product Support is on the front lines dealing with customer pain that would otherwise interrupt Product Development. From the perspective of Development, it’s easy to see Support as a shield that frees them to focus on building and improving the product. Pain is Support’s problem.
But while pain is unpleasant and we may wish to avoid it, it’s vital for survival as it steers us away from problems and danger. Development must not ignore customer pain. It’s a warning signal, and if that signal dies in Support then Development can easily steer right into danger.
I’ve seen Development teams with tech support rotations that allowed each developer a chance to work directly on customer issues – and those teams eagerly shut down those rotations as soon as there was a strong enough Support team to take on that burden. To those teams' leaders, the perspective gained by working directly with customers to resolve issues was less valuable than more uninterrupted development time. This is understandable, but more development time is not worth it if it’s spent on the wrong things, and without sharing in customer pain it’s easy to lose sight of it. Every time one of these developers desk-sided with a customer and saw them actually use the product, they came back amazed at what they’d learned and pushed for a flurry of pain-preventing fixes – but none of these teams ever scheduled regular desk-sides.
I’ve also seen Product Support work with customers over an entire weekend to restore service after a product issue caused an outage. Along the way, Support filed a bug ticket on the underlying issue – and on Monday, that ticket got marked low-priority by Development. Development missed the pain of the weekend and to them the takeaway was that the issue had a solution. The bug didn’t get fixed and there were more painful weekend outages.
And I’ve also seen Support teams realize that Development was ignoring customer pain because Support had it covered. These Support teams could no longer be effective customer advocates and spent a lot of time treating customer pain from the same problems over and over – and unsurprisingly, these teams consistently lost their best people.
Product Support is there to treat customer pain, but it’s there to prevent it too. For that to happen, the signal provided by the pain must not be lost. It must be successfully conveyed to Product Development and factor appropriately into prioritization.