{"id":12620,"date":"2017-05-15T16:57:33","date_gmt":"2017-05-15T15:57:33","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12620"},"modified":"2020-07-30T12:57:58","modified_gmt":"2020-07-30T11:57:58","slug":"empathy-engineering-bridging-the-gap-from-code-to-customer","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/empathy-engineering-bridging-the-gap-from-code-to-customer\/","title":{"rendered":"Empathy engineering: bridging the gap from code to customer"},"content":{"rendered":"

My name\u2019s Dale, I\u2019m an engineer and I have a confession to make. I like talking to customers.<\/p>\n

I know I\u2019m supposed to spend all day shipping code in a state of flow<\/a>. But whenever I ship something new, I can\u2019t help but be curious about the impact it\u2019s having on our customers.<\/p>\n

This shouldn\u2019t 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 \u201csmall issue\u201d for an engineer could well be a showstopper for a customer.<\/p>\n

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\u2019s how we do it.<\/p>\n

Getting into the trenches<\/h2>\n

When you start talking to customers, you\u2019ll 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\u2019re having the right type of conversations. They have to add value, for the engineer and<\/em> the customer. You\u2019re unlikely to get much empathy troubleshooting issues with Internet Explorer and the like.<\/p>\n

To start, it\u2019s 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.<\/p>\n

Talking to existing customers<\/h3>\n

Talking to existing customers lets you see firsthand how your code is being used and where it may be breaking. You\u2019ll quickly identify areas of the product that are too complex and recurring bugs your customers are running into.<\/p>\n

Of course, it\u2019s impossible to expect to reach out to every customer. That\u2019s why it\u2019s 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.<\/p>\n

For example, I\u2019ve 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 \u201cAndroid\u201d in it. This allows me to see common issues at a glance and what customers I need to reach out to for more context.<\/p>\n

One recurring issue has been push messaging. It\u2019s got a lot of moving parts so it\u2019s understandable that my Slack channel was full of customer feedback<\/a> like this:<\/p>\n

\"customer<\/p>\n

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<\/a> 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).<\/p>\n

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.<\/p>\n

Talking to new customers<\/h3>\n

When a potential customer is interested in using your product, it\u2019s 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\u2019ve found that a customer will have a specific use case that they\u2019re concerned won\u2019t 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\u2019ve been on many calls where the difference between a customer signing up is a couple of lines of code changes.<\/p>\n

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.<\/p>\n

We understood what was happening, but we still didn\u2019t 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, \u201cAre you logging out before logging in?\u201d, we could tell before they shipped if they were going to run into this problem.)<\/p>\n

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\u2019t increment the session count. A small amount of work that means we no longer have to worry about new customers making that mistake again.<\/p>\n

\n

Provided you\u2019re equipped to listen to your customers, engineering with empathy isn\u2019t that difficult. Even if you only talk to two or three customers, you\u2019ll sniff out customer feedback that can have a real impact on your product. Here\u2019s a few benefits it has had on our team:<\/p>\n