Beyond the Code: Deploying Empathy

Updated on November 22, 2022
22 min read

Code is always a means to an end rather than the end product itself. It’s extremely important to understand the broader picture and see what the code that you or your team are going to write is helping to solve. Michele Hansen, author of Deploy Empathy and co-founder of Geocodio, reveals some of the best practices around understanding your users and responding to their needs. Join Michele and Hannes Lowette, head of learning & development at Axxes, while they dive into how to run successful and useful customer interviews.

Code is always a means to an end rather than the end product itself. It’s extremely important to understand the broader picture and see what the code that you or your team are going to write is helping to solve. Michele Hansen, author of Deploy Empathy and co-founder of Geocodio, reveals some of the best practices around understanding your users and responding to their needs. Join Michele and Hannes Lowette, head of learning & development at Axxes, while they dive into how to run successful and useful customer interviews.  

Intro

Hannes Lowette: Hi, I'm Hannes. I'm here today with Michele Hansen. And we are here to talk about deploying empathy. So, Michele Hansen, can you please introduce yourself to the audience?

Michele Hansen: Hi, I'm Michele Hansen. I am co-founder of Geocodio, which is SaaS, and I am also the author of "Deploy Empathy", which is a practical guide to interviewing customers.

Hannes Lowette: So, Michele, can you tell me how you ended up in your current position at the company?

Michele Hansen: Well, my husband and I started our company as a side project in 2014. We do geocoding, that's converting addresses into coordinates so that a computer can understand them and coordinates into addresses so that a human can understand them. We started that in 2014. I was working as a product manager at the time. Grew the company and I eventually went full-time on the company in 2017. When I was a product manager, one of my focuses was on new product development and customer research.

I found learning how to do customer research to be revelatory for me as a product manager. Our team increased team velocity so much. We felt like we had a really clear vision once we started incorporating customers into our process. And so, when I went full-time as an entrepreneur, got a chance to do a lot more of that with my customers, but also started investing in mentoring in other companies as well. And sort of learned that there was a need for more books that spoke to people about how to talk to their customers, how to solve problems like churn, customer acquisition, retention, and figuring out what to build in the first place. All of those things took the rigor of the UX world but put it in a way that made it approachable for anyone, especially developers, to start deploying empathy in their work.

Before deploying code, deploy empathy

Hannes Lowette: Right. You mentioned figuring out what to build. It's one of the things that I tell junior developers all the time. I coach a lot of junior developers. The first thing I tell them is to hold off on the coding. Figure out what you're building first and why you're building it. You will save so much time because you'll end up redoing a lot less of your work. Does that sound familiar to you?

Michele Hansen: Yes. Before you deploy code, deploy empathy, figure out what you're building, why, and who is it for. How are they going to use that? Because that determines the big picture. But also a lot of little decisions you might make daily as a software developer, whether that's how you're structuring an API or a database schema, that determines how the information can be packaged up to the user and consumed by them. Without understanding what the user's goals are and what they're trying to do in the first place, you can't build something that makes that easier for them. 

Hannes Lowette: You can also not think along to their process if you don't understand how they made their money or what kind of process, the thing that you are building is going to fit into. I think that that's probably what makes senior developers, senior developers look a little bit further than just the code that they're writing and try to solve the real problem. You are wearing a t-shirt with a duck. Does that have anything to do? Because we have rubber duck debugging when we're writing code. Is it something similar that...Well, you brought in a rubber ducky?

Recommended talk: Anniversary Edition of The Pragmatic Programmer • Dave Thomas & Andy Hunt • GOTO 2020

Michele Hansen: Yes. So, the rubber duck which you find on my t-shirt and the cover of my book is inspired by that famous story in "The Pragmatic Programmer." If you have a problem, you should talk it out to the duck. And I take a little spin on it, which is that when you are interviewing a customer, whether that is in a formal sit-down exploratory conversation or usability session where you're trying to figure out whether they can use the thing that you've built, the idea is to picture yourself as the rubber duck because, in a well-run interview, the person you're interviewing is doing 90% of the talking.

You have some questions that you want to ask them, but mostly you're just encouraging them to keep talking about their process, about their goals, so you can figure out where your product fits in their overall process. It's a helpful mental image to picture when you might find yourself wanting to jump in on what someone is saying or get excited and instead sort of calm down and be like, "Nope, I am the rubber duck here. They are the one who is talking and I am absorbing."

Hannes Lowette: Like holding off on proposing solutions as long as you can, right?

Michele Hansen: Yes. Ideally not propose them at all when you are talking to the customer. Yeah.

How to run successful customer interviews?

Hannes Lowette: So, what are the key dos and don'ts when you're having such conversations? Because I feel that it is tough to get good at doing that.

Michele Hansen: Yes. It's so important. It's important to the point where I spent a whole part of my book talking about how to talk so people will talk. Because the way you ask questions and the way you treat someone in an interview determines the quality and quantity of information that you get back. Sometimes I hear from people who say that they tried customer interviews and they didn't get anything out of it, but then it turns out that they weren't well prepared enough in terms of how you ask a question, right? Because there is a big difference between “why'd you sign up for our product today” and “why'd you sign up for our product today” (e.n: different tones of voice? It was because your boss told you to, or you were looking for something and why'd you sign up for our product today? It's a huge difference between those.

If you want someone to open up to you and tell you about their process, even if it's a very boring everyday business process, those are sometimes the best ones because people haven't talked them through with anyone else. The way you ask questions and the way you treat someone makes a huge difference. It's almost that your questions that you might have come in with, they're just setting up the interview and showing the other person that you care about this process or goal that they have, that you're listening to them and that fundamentally they have for the floor and you are just there to listen to them. So, things like using a calm, gentle tone of voice, not interrupting them, leaving pauses for them to fill, and mirroring and summarizing what they're saying. All of those things are incredibly important to building rapport with the person so that you get really good information back that you can then use to build better products and more successful products.

Recommended talk: Rediscovering Humanity in Tech • Eric Johnson • GOTO 2022

Hannes Lowette: Right. If you talk about getting summarizing information back to the user, is it also a key point to find the nuance in the terms that they're using to describe their processes? It's really big in the DDD world when we're looking at finding the ubiquitous language that is being used in that business, the terms and the domain terms that apply and a customer is something else than a person and a subscriber, they might all mean different things in a certain context. Is that something you try to also achieve in those interviews? Like finding that nuance?

Michele Hansen: Yes. It's really important to make sure that you understand what the user is saying in their context. So, you might understand what DDD is, but you might not understand what it is in its specific context and how it works within their organization, right? The goal is for them to teach you about their experience, not necessarily the subject matter, right? And so, I might rephrase that back to you and say, "So you were telling me that's important in DDD?"

Hannes Lowette: Well, yes. You used the term customer now, but you were using the term subscriber a little bit before. Like what's the difference? It doesn't mean the same thing or those kinds of questions are the things that I go looking for when I'm talking with a customer is that to understand what they're talking about, if they use different words, they usually mean a different thing. But I don't know what the difference is because I'm an outsider getting in, right?

Michele Hansen: Mm-hmm. This is a tactic I call asking for clarification even when you don't need it, right? So, if you ask for clarification about something you already understand, chances are you will learn something about how it works within their specific organization, which could be incredibly key for selling something into their organization. Right? You need to understand how the process looks. Every organization is different. Everybody implements agile differently, right?

Hannes Lowette: Yes.

Michele Hansen: And so, you need to understand how it works in their specific context. There's also a little level up there too, where you can rephrase and ask for clarification slightly wrong. So, you might misstate the steps of a process, for example, and then I find...

Hannes Lowette: You can do that on purpose?

Michele Hansen: Yes. So, for example, if someone is telling you about how they want to onboard a new vendor, let's say, and they say, "So first I go to my manager to get approval, then I go to purchasing to get a PO, and then I send it back to the vendor." For example, you might say, "Let me make sure I have this straight, first you go to purchasing to get the PO and then you talk to your manager, and then you send the PO back to the vendor."

It's very slightly wrong, but it will prompt someone to say, "No, no, no, no, I have to go talk to my manager first because if I don't talk to him first, then I can't go get to purchasing and then it's going to be this huge mess. And I did this once and it was like," they're just gonna go off. Right? And they won't even remember that you had it slightly wrong. You'll get so much detail and just it's amazing.

Hannes Lowette: You'll get to why. It's like, why do you do it in this order?

Michele Hansen Exactly, exactly.

Under the hood: looking into an organization through customer interviews

Hannes Lowette: That's nice. You also mentioned that it could be a very boring business process. Right? Have you ever like consulted with a business that was legitimately boring even after you found out all the details about it?

Michele Hansen: So, I don't do consulting myself but our company, we are a truly horizontal SaaS. Our customers range from college students who are making a map for the first time and using Geocodio because their professor told them to, to Fortune 50 companies, banks, insurance companies, government, and massive organizations. Something I love about interviewing customers is that it's so much fun to get a window into all of these organizations. And it's just really interesting. I don't think I have ever found a use case that I found boring. I think maybe just from an investor's perspective perhaps, I just find it so fascinating to get to peel back all of the little layers of what they're trying to do. I think with Geocoding, for example, it's abundantly clear that somebody has to do something else with it, right?

Like coordinates are not stamps. People don't collect them for the fun of it. They are not a result in and of themselves. We are a step in some larger process. I find it so much fun to talk to people whether their use case is regulatory compliance or they make software for tractors and they need to make sure that the health reports they're getting back from each tractor are correctly timestamped so that the one at 11:59 in Delaware is timestamped on the right day and not the one at 11:59 in California. Right? It just runs the gamut and it makes it so fun and inspiring to work on the business too.

Hannes Lowette: Yes. It's what I always loved about...I'm a software development consultant, so I'll go in and help them write software. I found that step of the process, like finding out how they make their money and why they're doing the things that they're doing. A lot of these domains may seem boring from the outside, but as soon as you start learning what makes that whole company tick, it might be a company that writes software to do customs declarations, or it might be a very fancy IoT company, but as soon as you get into the little levels of detail, it almost always becomes interesting at some point because you're dealing with these situations and fine-tuning their business with the products that you're building, which is always great to do.

Recommended talk: The Path to Becoming a Senior Engineering Manager • Denise Yu & Jiaqi Liu • GOTO 2021

Michele Hansen: And it makes you a little bit invested in what they're trying to do. Right? Because maybe on the surface, customs, that's a little bit boring, but then you start talking to them, it's, "Oh my gosh, they've come so far. They've upgraded all of their IT in the past 10 years. This is part of a big effort they're doing. This is real people who are trying to do things." And then, so when you go back to your team, you have that in your head of, "Okay, yes, I have thousands of customers who are going to use this," but in my head, I can picture, "Okay, this is how that customs company is going to use, and I remember the steps of the process, and so if I make this decision, this will make that a lot easier for them. Then, in turn, thousands of other companies that also are going through that same activity."

What makes Geocodio unique?

Hannes Lowette: Yes. So, geo-coordinates, you've got my interest there. It seems like there should already be solutions for that out there. What is your product able to do that makes it unique?

Michele Hansen: Our niche is in the North American market, and where we focus is where people need coordinates for data enrichment purposes. So, for example, many of our customers are making maps, which is sort of the most obvious use case for coordinates. But a lot of them are using them for other things where the coordinates are a doorway to other pieces of information about a location. So, for example, if you want to know who somebody's congressperson is, you need to take their address and put it in the coordinates first. If you wanna know somebody's time zone, if you wanna know any sort of census or statistical data about a location, first, you have to have the coordinates. There are all sorts of things in the US, Canada, and all over the world where you can only get these pieces of information about a location if you have the coordinates. And it runs the gamut from political data to things that lead to insurance or environmental risks. It's really fun.

Hannes Lowette: Users will not input their coordinates. They're gonna put input their street address, right?

Michele Hansen: So, it can be coordinates or the address. As we're focused on the sort of data enrichment practices it's usually people uploading spreadsheets of thousands to millions of addresses using an API that's either real-time in their application or, you know, maybe they've got a database of hundreds of millions of addresses that they need to find one specific census point for regulatory purposes, for example.

Hannes Lowette: That sounds cool.

Michele Hansen: Yes, it is cool.

Hannes Lowette: It's also a domain that if you dive into it a little bit deeper, will become interesting. What is interesting, what are the biggest problems that you faced when you were building that?

Michele Hansen: Well, building all those data pipelines is tricky. I think that's something where we focus on, is that we know that for our customers and their process if they're using anybody else, they're gonna, they might need to hit five different APIs. They're coming back with different terms, different pricing, and different formats, and just normalizing all of that data takes a lot of time and is pretty frustrating for them. We instead try to consume as much of all of those base data sets on our end. Having all of those data pipelines, getting the data, and updating it continuously, are challenges that we are working on, daily to make sure that things are as easy as possible so that we are the ones who are dealing with sorting and normalizing, and updating all of that. So, when it comes to them, they can just click a box or add a field in the API and get it and never have to worry about all of that data stuff.

Hannes Lowette: That's nice. And that company is based here in Denmark?

Michele Hansen: Yes.

Hannes Lowette: I understand.

Michele Hansen: Well, we started it in the US and, my husband and I, moved to Denmark two years ago, but we still have a US company. We joke that we're the world's smallest multinational corporation.

Hannes Lowette: The world's smallest multinational. Okay, that's...Well, it's a statement that's technically correct, which is the best kind of correct. Moving to Denmark in 2020 sounds like it must have been fun or frustrating, or both.

Michele Hansen: We feel very fortunate that we were able to move to Denmark in 2020. We have a daughter and schools were closed in the US and looked indefinitely closed. And we had been planning to come to Denmark for the summer anyway, where my husband is originally from, and we're like, "You know what? Why don't we just stay here for a year?" But after a couple of months, we loved it and decided to move here. So, we moved from five minutes outside of Washington, D.C. to a six-acre farm in the Danish countryside.

Hannes Lowette: Oh, Danish countryside. Like near which city?

Michele Hansen: Faaborg.

Getting to know your customer

Hannes Lowette: Okay. That's nice. Let's get back to talking to business people. What is the first kind of thing you start looking for if you know nothing about their business?

Michele Hansen: So, if I am talking to one of my customers, or I'm talking to somebody who wants to talk to their customers?

Hannes Lowette: What do you teach people? I get into a new business, what type of questions I should be asking them even if I know nothing except for like, the basic information I find on their website?

Michele Hansen: I think the first question to ask is what are they trying to get done. If we're gonna apply jobs to be done and research their customers first let's apply jobs to be done to this company. Why have they reached out for help in the first place? And that might be hiring a consultant or simply reading a book. What is the problem they're trying to solve? Where are they in that process? What have they already tried?

These are the questions that we ask of users, but first, we ask the company to figure out where they are, and what are they trying to do. What have they already tried? Why isn't it working? Right. Where are they struggling? And then from there, figuring out, okay, so if we know what their goal is, maybe that's the primary thing that they're struggling with is that whether it's new customers or retaining existing customers you know, having cancellation issues, figuring out which ideas they should be prioritizing.

I have scripts for six different common situations in my book to make it hopefully easy for people to just take that, make some modifications that are relevant to their business and their customers, and then just run with it so they don't have to go through the process too much of workshopping scripts. And then hopefully they can start, go find five people to talk to. People across the UX world generally say that you start with five and then see what you've learned. You'll probably find some threads that are interesting there, and probably learn some things you didn't even realize were there, which is always the fun part about doing interviews. And then you can continue to explore as you see necessary going in the directions that look like, you know, are a good nexus of what might be profitable for the business and you're capable of solving but are also high frequency, high paying problems for customers that they're already willing to pay for.

Handling divergent information from users

Hannes Lowette: Right. So, you mentioned five people. I guess that when you do these conversations, you'll either see people either contradict each other or confirm each other's stories. How do you deal with that?

Michele Hansen: The general rule that you will hear people say, and this includes Nielsen Norman Group, Jim Kalbach, author of "The Jobs to be Done Playbook," a whole bunch of other people, starts with five and then stop when you keep hearing the same things over and over again. You may hear the same things from, you know, four people in a five-person set, which probably means you have a very defined scope and you already really understood that problem quite well because you targeted your interviews very well. But for a larger, more nebulous problem, you may need to keep doing research, loops of five people to figure that out a bit more and narrow things down further. That's very normal.

Recommended talk: Adopting an Experimental Mindset • Mark Rickmeier • GOTO 2021

Hannes Lowette: Okay. so, are you on purpose looking for the contradictions or to confirm certain stories? Do you carry your findings from the first conversation that you have into the second and the third and so on? Or do you treat them as completely different separate conversations?

Michele Hansen: I encourage people to evaluate their ideas rather than validate them. So, when you go into something, you might have a hypothesis about the behavior you might say, "Okay, we've looked at our data, and we can see that these users who take these actions, end up being the ones who retain," for example. And you might have a theory as to why. Usually, I found those theories end up being wrong, and it's kind of fun to be wrong in those scenarios. And it's important to keep an open mind when you go into that be prepared to be wrong, and even be excited about the prospect of being wrong.

Hannes Lowette: Of being wrong.

Michele Hansen: Yes. And learning something new. You'll know that your time has been well spent researching if it turns out your original hypotheses were wrong.

Being empathic to yourself

Hannes Lowette: That's interesting being wrong. It's often a sentiment that triggers some kind of primal response in us humans, right? It's like I said this thing before, but now it turns out that I'm wrong. Our nature tells us to fight that. How do you deal with that?

Michele Hansen: Well, first I think whenever you find any emotion that is challenging you, whether that's you're afraid of talking to people or you're afraid of being wrong, the first thing is to recognize that that feeling is valid. I think the most important part of being able to deploy empathy with our customers is deploying that empathy on ourselves first and saying, "It's okay that I'm afraid to talk to people. It's okay that I'm afraid I won't get anything out of this. It's okay that I'm afraid of being wrong and having to explain to people why I was wrong about this." Recognizing that first is incredibly important because if you try to push that away, the feeling will only grow stronger. Right? If you tell yourself not to worry about something, what are you gonna do?

Hannes Lowette: You're gonna worry about it.

Michele Hansen: Exactly. Right. And then, so if you can build a culture where it's okay to be wrong, you know, I think back to the team that I was on before I was a full-time entrepreneur, it got to that point where it was acceptable and even encouraged to be wrong, and people were excited about it. That made it such a great team environment to be on because we were all learning so much, and you didn't have to feel like you were right all the time. It reduced a lot of pressure and allowed us to try new ideas to push things forward,

Hannes Lowette: Search for the truth together kind of thing. And it's okay that what we thought previously now turns out to be completely invalid.

Michele Hansen: Yes. And I think you see this, in broader leadership advice now to Brene Brown, for example, who is famous for talking about the power of vulnerability and leadership, and this is a very concrete way that team leaders can do that is make it okay for their employees to do things wrong. Whether that is they wrote code that had a bunch of errors and failed the tests, that's okay. You've learned something. Let's be excited about that. Right? Especially for someone who's a junior developer and may not feel as confident in their coding abilities, but also people who are doing product side research, make it okay for their initial assumptions about user behavior to be wrong and encourage them to go out and find those answers and continually finding those answers and always learning new things.

Hannes Lowette: So, is this step of the process where the title of the book comes from "Deploy Empathy"?

Recommended talk: Talking With Tech Leads • Patrick Kua • GOTO 2020

Michele Hansen: Yes, the title is a bit of a wink to developers, or initially the audience I was writing to was developers who would become founders either because they had side projects or they started their own software companies, very often very small shops where maybe they're the person who was doing everything or they only have a handful of employees. And I wanted to make sure that developers knew that this was a book for them because a lot of UX and product books are written for UX and product people. And instead, I wanted to make sure that they knew that they were included in this and that this was a book that they would be able to get something out of even if they had no prior experience with customer research.

Hannes Lowette: Yes. That's a daunting situation. As soon as you start entrepreneurship you're first, you're this chief everything officer, and then you have to figure all the things out, from bookkeeping to doing customer research to building the thing. Has that also been your experience in your business? Because you said you're the world's smallest multinational company, that leads me to believe that you're still a very small outfit. Are you taking on all of the roles in the company?

Michele Hansen: Yes, my husband and I do have a division of labor. We have some areas where we share things. But some areas are pretty much exclusively mine and some areas are pretty much exclusively his.

Hannes Lowette: All right. And you still run the whole shop, the two of you? Or are there employees involved already?

Michele Hansen: We're hiring our first employee right now. He'll be starting in July. But we've had a lot of consultants and freelancers over the years as well.

Hannes Lowette: Sounds exciting. Is it gonna be here in Denmark, an employee here in Denmark or?

Michele Hansen: No, in the US.

Hannes Lowette: In the US, okay. So, it's going to be a fully remote job?

Michele Hansen: Yes.

Hannes Lowette: Very pandemic, right?

Michele Hansen: We are exporting a little bit of Denmark to it though. In Denmark, we have this concept of vacation money where people get an extra payment in the spring...

Hannes Lowette: In June or July.

Michele Hansen: Exactly. To go on a vacation that summer. We decided to give them a minimum amount of pure vacation that we expected to take and then split up their annual bonus. So, half of it is in the summer and half is at the end of the year. So, they have that vacation money to go on.

Hannes Lowette: Sounds awesome. I hope that you succeed with your new employee and that they appreciate the European way of doing things. We have the same thing in Belgium. We do get a bonus just before the summer and one at Christmas. Is there anything else that you would like to add to this conversation getting to the end of it, or do you think you shared everything with the audience that you wanted to tell?

Michele Hansen: So, people can check out the book by going to deployempathy.com. There, you can find a preview of the book. You can also find links to buy it. You can buy it from Amazon or Saxo or wherever you buy your books,

Hannes Lowette: All right, so find it on Amazon "Deploy Empathy" by Michele Hansen. Thank you so much for being here with me today and for having this conversation.

Michele Hansen: Thank you so much.

Related

CONTENT

Design for Developers

Design for Developers

August 31, 2023
Grokking Algorithms

Grokking Algorithms

December 1, 2022
Paving the Golden Path: Achieving High Performance with an Internal Developer Platform
Paving the Golden Path: Achieving High Performance with an Internal Developer Platform
GOTO Amsterdam 2022
Conway's Legacy

Conway's Legacy

October 28, 2021