Programming takes a lot of time to learn and a lot of skill to do well. So obviously, if after all this hard work you can get paid to create state of the art applications the way you want, you’re not gonna spend your day talking to people who can’t remember their password.
But you should.
Customer support is no longer the number people call to waste their afternoon on listening to an underpaid consultant reading off a script. They’re sure they’ve tried turning it off and on again.
Customer support is where users come to help you build a better product – if you’re there to listen.
Putting designers and programmers and everyone else in direct contact with customers isn’t about putting out fires; it’s about fire safety. It’s about having the kinds of conversations that lead to better products in the first place.
Here’s 5 reasons why doing customer support should be a constant part of your workflow.
#1 If customers have trouble using simple features, you didn’t make them simple enough
A perfectly designed product would need no customer support. Until such a thing exists, the purpose of a good developer is to make a product that doesn’t need a walkthrough to be used.
When developing a product, it’s easy to get stuck in your own point of view. But an interface or feature that might seem intuitive to you will not feel natural to some customers. Talking to them will help you understand a different user perspective and optimize your design approach to make it clearer.
Your customers actually know the product better than you. They know its quirks and workflow issues. They know when it’s not serving its purpose well and what it’s lacking.
#2 Say “it works on my machine” to their face
I dare you.
You probably work on a newly updated equipment. Probably running Linux or OSX. You might forget that a big portion of your userbase is using a device much older than the previous OSX patch. Or, the horror! some of them are on a Windows version that is over 2 years old. Systems that none of your colleagues have access to, so obviously you’ve never tested the apps on.
You might’ve heard that saying:
#3 Just deploy. We’ll test it in production.
That’s deploy-rable. But you can get away with it as long as you collect the test results and act on the bugs that users report. For that, you need to speak to those users directly and hopefully patch the bugs immediately.
What’s amazing about having to support your own software is best summed up by Kevin Hale, the godfather of support-driven development:
If I’m going to build this, how does it affect me later when I have to support the user?
If you have to face the people you’ve annoyed by deploying a buggy or confusing product, if you have to answer that one “stupid” question one more time – you’ll find new appreciation for keeping it simple and thoroughly tested.
#4 The “known issue” dilemma, or prioritization
When bugs pile up, and you still have new features to work on, it’s easy to procrastinate on an issue that seems minor. And when your communication with the support department is not great, you might not realize how consistently annoying a minor bug is to tens of customers.
That is also the case when your customer support is so good they walk the customers through solving every problem instead of reporting it to the devs.
In support, you get so used to something being a “known issue” that you start treating it as a hidden feature. When customers keep reporting it, you just answer with a canned response. When you pass those reports to the devs, they answer “yeah yeah, it’s a known issue. We know.”
In this chain of blame-shifting, only the front line – the support people – feel that it’s an immediate problem. They’re the ones who apologize for it.
For a developer, when you know about this problem already, and it’s something not crucial for the functioning of the whole system, it’s easy to procrastinate on fixing it.
But when you’re doing front-line support, you are feeling the impact of the known issue in an immediate way. So there’s finally a good enough reason to fix it.
#5 Free and fresh ideas
The best part of customer support is unsolicited feedback and feature requests. You get users who are so obsessed (or dependent) over your software they keep thinking about how to improve it.
Some (most) developers prefer to think that without knowing the product roadmap, being just one non-technical user, all the new features you come up with don’t make sense.
Like in that saying about faster horses and cars.
But that’s wrong. Sure, you can’t implement every feature request random users throw at you. But neither can you consistently develop a usable product without listening to its users and understanding how their workflow looks and how they compare your product to others.
The best product is not the one built with the cleanest code or the most efficient algorithms. It’s the one that users need and want to use.