recursion

When I was getting started with programming, I had stereotypical programmer attitudes about dealing with “stupid users”. I believe that I had the Apathy demotivational poster as my desktop background at one point, and I enjoyed jokes about lusers and read BOFH often.

But as I’ve progressed my career, I’ve realized that it’s actually really interesting to talk to the people using the software you write (after all, why else are you writing it?). At Swiftype, I spend a lot of my time answering support requests. We do full-company support and all the developers take turns reading and answering support requests.

Answering support requests is interesting because a lot of them expose corner-cases we hadn’t thought of yet. Recently, a customer emailed to complain that their query customizations weren’t applying for upper and lower case. I was surprised, because we don’t differentiate between upper and lower case for search queries. But sure enough, she was right: we were considering the case of queries for customizations. The same customer pointed out it’s hard to know which queries you’ve customized – we’d never gotten around to providing a list. Both of these problems had fairly simple fixes and we were able to roll out a new version of the software that day.

I think having developers on the front lines of support is really useful. Developers learn more about how people actually use their software, and quickly pick up patterns of common problems to fix. This can mean fixing bugs, improving the UI, or adding documentation or an entry in the FAQ. In short, support requests are how software gets better. Meanwhile, customers are very appreciative when they realize an actual developer listened to their problem and fixed it quickly.

An important lesson I’ve learned from doing support this way is: Don’t ignore the little guys. Customers of all sizes discover important problems that may affect many other customers. Obviously, it makes sense to pay more attention to your big customers. But if you fix the little customers’ problems, the first time a Fortune 500 customer sits down to try your product, chances are that it’s going to go a lot more smoothly.

Obviously, it’s difficult to scale this level of support. That doesn’t mean you shouldn’t do it. For a small company trying to make its mark, having great customer support can be a major distinguishing factor, and I’ve already pointed out the great benefits to the engineering team of understanding your customers. Meanwhile, as you grow, you can make adjustments to shield the development team from too much support burden. For example, Harvest has a “Delta Force” of two developers who rotate into support duties. The Delta Force members are the primary point of contact for the frontline customer support staff, allowing the rest of the team to focus on new feature development.

Delta Force is comprised of two developers: a primary and a backup. The primary will typically spend his entire week investigating and fixing bugs. The secondary is there to support the primary team member, picking up the slack on a busy week and reviewing fixes coded by the primary team member. Our four developers rotate through these roles one week at a time. The secondary is the previous week’s primary, which helps with knowledge transfer for ongoing problems.

As you grow, you can keep your competitive advantage in customer support by investing in technology to manage the process. For example, we’ve integrated a number of features into our administrative dashboard to help with support requests, and we added a question and answer forum to capture common requests.

Still skeptical? Kevin Hale of Wufoo has some great things to say about what he’s coined “support-driven design”. When they were acquired, the Wufoo team of about 10 people was able to handle an average of 400 support requests a week with 7-12 minute response times.

They invested a lot in their support infrastructure to make that possible, and it paid off very well for them. Kevin has given a number of talks about this over the past couple of years. Watch his talk from UserConf 2012, or browse his Support Driven Design slides. Wade Foster of Zapier also has a good blog post about the benefits of support driven development.