I once had a boss that insisted that developers act as support for at least a month on all newly released products. The idea was that they would get direct feedback from the customer. This would allow them to better understand the real world use cases, and share the pain of any errors. I believe this approach has a fair amount of merit. I have learned a lot from my customers. In general, I release a version 1.0, and from there, customers determine future feature releases. It doesn’t always work this way, but customers have pretty good ideas about what they want. (Thank you for that insight captain obvious).
Despite this, I don’t believe that developers and support is a good match. We’ll start by picking on developers. This may come as a shock, but the average developer is not necessarily a “people person”. The stereotype of a socially awkward introvert exists for a reason. The stereotype portraying developers as arrogant and matter of fact also exists for a reason. It can be really hard for some devs to admit something is a bug and not a “feature”, or that maybe the user really is smart enough to use the product, and it’s the product that’s too hard to use. There can also be a language barrier. So, do you want your customers to be told the equivalent of “you’re holding it wrong” in an accent they have trouble understanding? Obviously, not all developers fit this mold, but support is not what they are trained for, ad is not typically what a developer has a disposition for.
Support by developers also interrupts flow of future development. Once a release is done, the next begins. Do you delay the next release schedule because your developers are not 100% on development? How much would you delay it – 5%, 10%, 25%? That was supposed to be a good release, right? When a developer is coding, is a good thing for them to be interrupted, and have their concentration broken? Bouncing from one thing to another is inefficient at best, and is a source of bugs.
Now, you might say that these issues can be overcome with training, scheduling and management. I might be tempted to agree in a perfect world. There is another issue, however. A lot of developers and whole companies look at support as a burden they have to carry. I think it is more of an opportunity. If a customer contacts you, it gives you the opportunity to communicate with them. You get to understand how they are using your product. You get to hear where it might be made better, and you may hear great feature suggestions. It also provides the opportunity to find out if you can do anything else for them (trying to avoid using “up-sell” – what a bad term).
Here’s where it gets even more important. It allows you the chance of making that customer a happy, repeat customer who will tell other people how great you are. Social media is such an important part of marketing these days for the reason that people will trust recommendations from others far more than they will trust an ad. When you give great support to a customer, you may create the farthest reaching, most effective ad you could imagine. Think about all the testimonial quotes you’ve heard and seen on sites or ads. You don’t really trust those, however, because they are clearly cherry-picked. Now, think about it if that person tweeted the same quote in real-time. You’ll probably give it a lot more credibility. And if a conversation begins about how great you treated other people, well, that might be worth putting a bug in just so you can talk to customers (no, not really).
So, who do you want to answer that customer, a dev who’s cranky because the customer found a bug, and interrupted the creation of some shiny, new feature, or someone who really wants to communicate with as many customers as possible?