Empathy engineering: bridging the gap from code to customer
Main illustration: James Heimer
My name’s Dale, I’m an engineer and I have a confession to make. I like talking to customers.
I know I’m supposed to spend all day shipping code in a state of flow. But whenever I ship something new, I can’t help but be curious about the impact it’s having on our customers.
This shouldn’t be unique, but the status quo for most engineering teams is to be disconnected from the people who use their product. Communication with customers exists, but it comes in the form of a ticket or issue logged in Github. This might be the best way to triage and prioritise bugs in your product, but does nothing for an engineer’s ability to empathize with the person affected by the issue. What seems like a “small issue” for an engineer could well be a showstopper for a customer.
The best software isn’t built in a coding factory. It’s built by engineers who are dialled into the needs of their customers. And that requires empathetic engineers ready to listen to what customers are saying. Here’s how we do it.
Getting into the trenches
When you start talking to customers, you’ll quickly realise that there are many more problems than you have the resources to fix. So the first step is setting yourself up so that you’re having the right type of conversations. They have to add value, for the engineer and the customer. You’re unlikely to get much empathy troubleshooting issues with Internet Explorer and the like.
To start, it’s useful to split conversations into two categories: experienced customers who have been using your product for a while and those new to using your product. Both are valuable, but in different ways.
Talking to existing customers
Talking to existing customers lets you see firsthand how your code is being used and where it may be breaking. You’ll quickly identify areas of the product that are too complex and recurring bugs your customers are running into.
Of course, it’s impossible to expect to reach out to every customer. That’s why it’s important to identify a single part of the product you would like to explore with customers, track those who are having difficulty, and then reach out.
For example, I’ve recently been keeping a close eye on certain Android issues our customers are experiencing. To track these, I set up a simple integration that posts in a Slack channel any time a new message arrives in the Intercom inbox with the word “Android” in it. This allows me to see common issues at a glance and what customers I need to reach out to for more context.
One recurring issue has been push messaging. It’s got a lot of moving parts so it’s understandable that my Slack channel was full of customer feedback like this:
What we quickly realised was that these were not isolated incidents. Customers were tripping up on similar issues over and over again, which helped us understand how we could fix the root cause issue. (Previously, tapping a push notification opened the host app, but as most apps have a splash screen that opens right away, customers never saw the notification. We fixed it so that we would hold onto the notification they tapped, and you could tell our messenger when you wanted the user to see the notification).
Had these issues been logged without customer feedback, we would have ended up putting band-aids over bullet wounds, missing the obvious fix that killed a repetitive issue from coming back again.
Talking to new customers
When a potential customer is interested in using your product, it’s normal for the sales team to hop on a call. But this is also the perfect opportunity for an engineer to sit in too. Many times I’ve found that a customer will have a specific use case that they’re concerned won’t work. Engineers can explain how they can achieve this use case right away, or the potential workarounds if it is not supported out of the box. I’ve been on many calls where the difference between a customer signing up is a couple of lines of code changes.
For example, we found that new customers using our mobile messenger frequently logged out a user then logged them back in every time the application started. This was inflating session counts and could result in users not receiving messages.
We understood what was happening, but we still didn’t understand why. It was only by getting engineers on a call during the onboarding process that we could really understand how to avoid this problem in the long run. (As it turned out, by simply asking, “Are you logging out before logging in?”, we could tell before they shipped if they were going to run into this problem.)
After talking to enough customers who were accidentally doing this we made changes to our mobile messengers to protect against this. The solution? We simply hold onto the logged out user for a short period of time and if they log back in that user we don’t increment the session count. A small amount of work that means we no longer have to worry about new customers making that mistake again.
Provided you’re equipped to listen to your customers, engineering with empathy isn’t that difficult. Even if you only talk to two or three customers, you’ll sniff out customer feedback that can have a real impact on your product. Here’s a few benefits it has had on our team:
- Reducing rate of incoming issues. Everyone loves the latest, shiny new project. But if the same issues are coming up time and time again, you’re letting your customers and your support team down. Even by talking to say, three customers, you’re very likely to encounter many of the most significant problems relating to a specific workflow.
- Positive and (negative feedback). Your work might look great when it’s beautifully mapped out on a whiteboard but it’s only when it’s in the hands of real worlds users that the rubber hits the road. The faster you get the feedback on what you’ve shipped, the faster you’ll learn. Think of it as positive reinforcement.
- Identifying non-product feature requests. By identifying an engineering problem with a customer and bringing it back to the team, and explaining the support impact this work would have, it lets us re-organizse our roadmap. We can then prioritise this task as something that will improve the quality of the product.
As engineers, talking to people might not seem seem like real work. Real work is coding. But in reality, one hour of talking to customers pays back many times over and will save weeks of building useless stuff that has no impact on your customers.
