Visiting customers as an engineer

We're a remote company, and most of the time that's exactly right. But there's a specific kind of understanding you only get in the room: watching someone use your product with their real data, their real workflow, and the three other tools they alt-tab to without thinking. People are more candid in person than in any written reply, and the friction that never quite makes it into a support ticket is obvious the moment you see it happen. Going to visit a customer is one of the best uses of an engineer's time we know of, and it's open to you, not just to a sales team.

Who's worth visiting

The best visits are with customers who are already friendly and engaged: they give feedback without being chased, they actually want the product to get better, and they use it enough that there's something real to watch. A team that's at least partly in one office is ideal, because the point is to see people work, together, the way they normally do.

Plan it well

A good visit is prepared for, not improvised.

1. Know what you're going in to learn. Go through the support signal, past calls, and what you've heard from listening to users, and write down the pressing issues and the things you're most curious about.
2. Find one point of contact on their side to coordinate. Two or three days is usually the right length: enough for real time with people, not so much that you're underfoot. Tying it to a moment they're together anyway, like their own offsite, works well.
3. Sort the logistics early. Book travel ahead, and clear the budget with People and Ops the way spending money describes. This is normal, encouraged spending, not a favor you have to justify.
4. Set a light agenda. Block an hour each with a few different users. Offer something useful in return, a short training session or an open Q&A, so it's worth their time too.
5. Do your homework. Watch how they actually use the product before you go, so you're asking sharp questions instead of the ones five minutes of looking would have answered.

While you're there

Let people show you, don't present at them. Ask someone to do a normal task and watch where they hesitate, where they work around something, where they expected a thing to be and it wasn't. That hesitation is the gold.

Be generous with your help, even on things outside the part of the product you own. You're the face of the whole company for those few days, and owning what you build stretches a little wider than usual while you're a guest.

After you're home

The visit isn't done when you fly back. Write up what you learned and share it with your team, and be willing to re-order what you were planning to build in light of it, since you now know something the roadmap didn't. Then actually do the things: ship the fixes, and tell them you did, listing what changed because of their time. Following up in the weeks after is what turns a nice visit into a customer who trusts you, and it's the same product engineering instinct as everything else: talk to users, then close the loop.