One of the very best things about working at Basecamp is “Everyone on support (EOS)”. That’s our policy where everyone on the team—no matter what their normal job is—spends one day per month as a customer support agent.
Each time my turn comes around I marvel at the truly excellent service our team provides every single day in what is a very tough job. Our team’s ratings and response time are insanely good even with dead weight like me pulling down their averages one day a month. I have no idea how they all remain so positive in a role where it feels like all day you’re saying “no”. Let’s face it, many customers know the answer to the question they’re asking. They’ve looked everywhere and tried everything so they’re frustrated, defeated, and sometimes grumpy by the time they reach out to a support agent— one who is understanding, empathetic, but often powerless to fix the problem. They have work to do and all this tech stuff just gets it the way.
While I’m glad to gain in appreciation for my coworkers what’s even more important about those stints on support is that I always learn something.
I know a lot about Basecamp already. I’ve been working on the current version of Basecamp almost exclusively since before the first commit back in 2011, from the first napkin sketches to its launch on iPad. What that means is I have internalized a very intricate mental model of Basecamp. I know every feature inside-out—and not just that, but code, domain models and all the decisions and debates and history that lead to why things are the way they are, why they aren’t another way and what compromises fit in-between. That’s not to brag, many of us who make products can say the same thing. These apps are built from our passions, they’re our babies. We can feel them. We notice when an interaction takes a beat too long, when a button is a few pixels out of alignment.
All of this blinds us. We’re wearing developer goggles.
One thing humans are really good at is rationalizing. And who could be better equipped than the mighty Product Designer™ with the entire history and its code repo in his head? Put a couple of them in a room and you get the intricate sparring of user advocates. We’re stand-ins, the noble voice of the lowly users, right? User-centered design. User experience. User stories. If we’re all so focused on making things for “users” why is helping those users in a support role so humbling? I should be great at support, right? I’m armed with deep first-hand product knowledge and can tell you all about every feature with a blow-by-blow of how it came to be. Hit me with your best shot!
It only takes one customer telling you about how your brilliantly designed feature sucks, creates extra work for them, or made them late/look bad/angry to realize none of that matters. A truckload of videos narrated by Jony Ive wouldn’t make that customer’s day better because explaining why doesn’t fix a thing. But empathy can go a long way. Taking off the developer goggles and feeling the customer’s pain isn’t just the best way to provide great support but it’s also the best way to become a better designer.
Yo Dawg, I herd you like Basecamp…
Here at Basecamp we make Basecamp with Basecamp. We use it all day, every day. That kind of use has resulted in a product that’s fantastic for working the way we do and for other companies that do the kinds of things we do more or less the way we do them. It’s a big reason why Basecamp has always been popular with designers and developers. But those kinds of customers, the ones who are like us, are a small fraction of our customer base. Most of our customers aren’t designers or programmers. They’re not enthusiasts for the latest gadgets or CSS frameworks. They’re regular people for whom Basecamp isn’t the most important part of their day, it’s just a tool that (hopefully) helps them get things done and doesn’t get in their way.
Those days on support I get to work like everyone else. When Basecamp becomes secondary to the support tool I’m using my point of view changes. I become more demanding and less forgiving. That spinner on the screen is no longer explained by that mental model in my developer’s mind that knows why it’s taking so long. Instead I’m just frustrated because I need that page and my customer is annoyed and emails are piling up and I’m destroying our legendary low response time average!
For so many of our customers, there isn’t any enjoyment in using the latest, greatest things for their own sake. Instead, technology is often frustrating, untrustworthy, clunky, slow, and fragile. I’m afraid to make a mistake. Why did they move everything in the new version? I don’t care about your new feature, I just need to print this damn thing! The gift I get from EOS is being able to remove those geeky developer goggles for a day and look at the world anew, like our customers do.
This is nothing new, it’s quite common advice to spend time talking to your customers. For many bootstrapped companies, dedicated support is a hopeless luxury in those early years so everyone answers customer emails anyway. What I’d challenge you to do is to find the thing that snaps you out of that developer mindset and makes you experience your product like your customers do. That’s what Everyone on Support is for me. What’s yours?
Junyu Zhan
on 19 Mar 15Thanks for writing a great article, Jason! The idea is simple: makers can’t look at things they make objectively and they need to be aware of that. I remember the book Don’t Make Me Think mentions this, too. It’s always a pleasure to learn from these simple and common sense knowledge from Basecamp.
By the way, some “goggles” are typed “googles”.
Andrea Grassi
on 19 Mar 15Hi Jason, wonderful write up.
Giving support once a month is great afterall, I believe you learn a lot from that. Also the thing of using basecamp for basecamp is great, and I’d like to know one thing.
Where is Basecamp Classic in all this? I wonder if, based on the team you use the one or the other or if you just use Basecamp and rely on userinput to decide what to do with the Classic version.
Be amazing
Nur Sah Ketene
on 19 Mar 15Nice read. I enjoyed it. You have one typo in the last sentence though: “makes you experience you product like your customers do”
Avalanche
on 20 Mar 15Thank you for sharing. This is a topic that I am very much interested in.
I was wondering about that 1day-per-month support policy. How are you dealing with the fact that not all colleagues are created equal and some just don’t seem to be cut out for customer support?
To start with little things: I know a lot of great programmers that lack the typing skills to work with anything that does not come with code completion and a compiler that accepts only valid syntax. It is simply takes them forever to write any non-trivial e-mail. And, an extra person to transform it to proper English.
Second, many developers have a really hard time thinking in terms the customer can understand. Talking about a NavigationStackControllerExtensionButton does not help customers unless they know that it is the back button at the top of the page. A more secluded variation of this is that (due to their intimate knowledge of the application) their description lack the details that regular users need to understand their instructions.
Third, some of them don’t seem to put up the empathy (or attitude) that is required for that job. It is a terrible support experience if an e-mail gets answered with “user error”. It is a horrific support experience if a detailed error description gets answered with “probably user error” because the support human didn’t feel like reading the full e-mail or didn’t see easy steps to reproduce the problem.
One of the reasons for my last point is that they feel that their job is “software developer” and many of them learned one thing: if you’re in a large organization and you don’t want to do something, just do it badly. That chore will get shifted to someone else very soon (and will probably not return to you).
I believe, good customer support is hard. In fact, it probably is one of the hardest parts of software development. My focus are software projects in large companies. The team is usually fixed and determined before the project even starts. Thus “hire only those that can do both develop and support” is not an option.
JZ
on 20 Mar 15@Avalanche – That description doesn’t fit any of our developers. Great writers are great communicators and that’s the kind of employee we’re looking for no matter the role. See: https://gettingreal.37signals.com/ch08_Wordsmiths.php. An employee like you describe who thinks and writes only in code won’t communicate well with customers or fellow employees. That doesn’t sound like recipe for success.
But I do see your general point that not everyone on the team may have the knowledge, gifts, and skills to provide customer support. What better way to learn, though, than giving it a shot and relying on the help of your fellow co-workers on the support team to help you along? We feel strongly everyone is better at their job when they understand the needs of our customers.
Avalanche
on 21 Mar 15@JZ: Thanks for the insights.
This discussion is closed.