There are a lot of myths about what it takes to bring a product or a new venture to market. I read and hear them repeated again and again, which only makes them stronger – even when rationally we know they aren’t true. That’s why I was happy to read the experience of a non-technical leader of support for a product I use.
In Customer Service as Art, Rob La Gatta, Community Advocate for the Modern Tribe Events Calendar plugin gives his experience over the last two years – playing the balancing act of supporting customers and providing insight to the development team. What makes this article stand out to me? Let me give you a quick list of some of the myths his experience puts a light on:
- Technical products and services require support teams with strong technical backgrounds. I’ve heard this one several times – but think about it for a minute. In this case in particular, a product for users of the WordPress CMS, many of the users themselves do not have a technical background. They are marketers, business owners, bloggers – people whose job is to write and release content using WordPress on a regular basis. They don’t know why they are having a problem with setting up an event on their site, but they paid for the service. They want it to work so they can get on with their business. A support person with a technical background often has a tendency to start the conversation by trying to find out what the user is doing wrong. A non-technical support person needs to start the conversation by finding out about what the user is doing and the problems they have encountered. They have fewer assumptions and a higher need to listen and understand the client before offering a solution. As a user, which response would be the most attractive to you?
- Startups and teams with new products need to get support handled quickly and keep it from distracting them. Actually, I don’t think very many teams voice this belief, but I see them planning and acting in ways that have this exact outcome. Instead, Rob details a very Lean approach. He and the CEO were the first level customer support when the product was released. They learned from the good and bad experiences of users directly – and from that experience – they provided the priorities for the development team.
- Quality Assurance (QA) and customer support are two different processes with separate business focuses. The development team needs to handle QA. Let the product manager and support sort through user issues. In any organization, silos are barriers to both communication and agility, but worse they put a summary step in communication that means that important details are dropped. Developers hear that users are having a problem but not the context. What were they trying to accomplish? What did they expect? Will a better placement of a control matter if users don’t understand what it will do? Wasted cycles and unnecessary features are the result.
- Remote, distrubuted teams and contractors don’t have the commitment or passon to handle mission critical issues. This one is near and dear to my heart – because I work in an environment where it comes up fairly often. I understand a defensive posture from the “home team.” Working with remote team members requires trust on both sides. It takes work and a personal assessment of goals. But, the richness of a team that can bring a broad range of experience and insight to a problem can be a huge advantage, if it can be leveraged.
What have you heard that your own experience tells you is just a belief and not a truth? Have you been able to communicate that to others on your team?