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?