Transcript
# CaSE Podcast with Joy Heron and Michele Hansen
**Joy Heron:** Hello, and welcome to another conversation about software engineering. I'm Joy Heron. And today on the CaSE Podcast, I will be talking to Michele Hansen about customer interviews and deploying empathy. Michele is the cohost of one of my favorite podcasts, Software Social, and she's also the cofounder of Geocodio, and the author of a new book called _Deploy Empathy_.
Welcome to the show, Michele.
**Michele Hansen:** Hi Joy. Thank you for having me.
**Joy Heron:** I'm really thrilled for you to be here. I wanted to start out our conversation today. I personally find our personal journeys to be really interesting. So I just wanted to ask you to open up what your personal journey is in the software industry.
**Michele Hansen:** You know, it's funny. How far back do you want me to start? Both of my parents are software engineers and I actually remember at one point my dad was getting this side project going. And I don't even remember what it was for or what I was doing or anything, but I was helping my parents test whatever this thing was.
And they were willing to pay me $20 an hour to help them with this, which was a lot more than the money I got for mowing the lawn or babysitting. I think I was making like $5 an hour babysitting. And I remember that being like, whoa, wait, I can get paid this much money to be on the computer? And you know, of course I was also somebody who played around with HTML and MySpace and whatnot.
But I really seriously started when I got out of college. I actually studied economics and international relations, so not at all related to software. But when I graduated, I ended up getting a job at a web development agency. And from there I ended up really getting into the web development side of things, because in college I had started various projects that were all run off of WordPress and the company was building WordPress sites mostly.
So after about a year of working there full-time I became a technical project manager managing all of their web development projects and then took on product management as kind of a side job as it was a really small company. I ended up really falling in love with products, and changed jobs to become a product manager at a company in financial publishing.
I ended up running product development there. That was really fun. In between all of this, around the time I was working at that agency, I also married a developer and we got our own projects going. We launched a mobile app first and then had a couple hundred bucks a month in ad revenue.
We used that to basically fund Geocodio, which launched in January of 2014, which is a software as a service, basically to convert addresses to coordinates and coordinates to addresses, and also add extra data that you might need related to that. And so then I went full-time on Geocodio in 2017.
That's sort of the short run of it.
**Joy Heron:** Well, thank you. It's been a long journey it sounds like from the very beginning until now.
**Michele Hansen:** I guess I've just always been comfortable around the technical world event if I'm not you know, I always say I'm not a developer and I will say I'm the non-technical side of things.
And then my husband looks at me, he's like, no, you're technical. Look at what you can do in spreadsheets. And I spent two days this week diving into something. Like building an API integration for Google Sheets. And it was so fun. I really love Excel programming. But yeah, I think it's just always something I've been around and have always been comfortable with.
**Joy Heron:** I always find these stories so interesting. So thank you for sharing that. Specifically today, you mentioned that you really got interested in product at a certain point in time. So is this around the time that you started getting interested in talking to customers as well?
**Michele Hansen:** Kind of. So my early exposure to product did not have any customer involvement really. And it was basically, you know, here's what the head of the company thinks we should build. Okay, great. Let's go out and build that and oh, why does nobody want to buy it? Huh, maybe we need more ideas. Let's go talk to the head of the company again and see what we should do.
I think launching Geocodio was really the first moment for me around this. We launched January 2014, we were front page of Hacker News all day. And as a result of that, you know, we made $31 our first month, which for us, that was great.
Because we just wanted to cover our server costs, which were two little DigitalOcean drivers for ten bucks a month each. So we had made $10 more than we spent. So we were psyched. But more so out of that, we got hundreds of emails from people with feedback on things and asking us, oh, can you support this country? Can you do this? Can you do that? And because I don't come from the geographic space, I'm not a GIS person, we would just ask them, why do you need that? Can you tell us why? Because we genuinely did not know. And so that was really interesting, hearing about all these different things.
And I found it really fun to learn about everything that people are doing. And also once we would start building things that the people asked for, and then we would grow more. You know, first they asked us for reverse geocoding and turning latitude longitude into addresses. And we did that.
And then it started growing more and then people were telling us about how they saw that we had the API, but they also had spreadsheets. And so the developers or companies were using us but the marketing people wanted to use it too, or maybe they had a big, you know, they needed to run their whole database through and it was just easier to upload a CSV.
And it turned out that the only service at the time that you could do that with was, you could email it to this guy and then he would get it back to you in a couple of days. And we're like, yes, this sounds like something for software. So then we're just genuinely asking people questions about what they were doing and then once we've grokked it building something and then seeing our growth improve. And so that was a wake-up call for me. And when I took my full-time job as a product manager, because I got tired of going from project to project and I really wanted to be able to be able to ...
**Joy Heron:** So you had started Geocodio and then you got your job as the product manager?
**Michele Hansen:** Correct. So that was December of 2014. I switched jobs. And I was still running Geocodio as a side project. So when I switched to being a product manager, I was still more excited about feedback than the other product managers at the company. I had seen the result of feedback emails, so I started putting those in for when we had new cohorts of customers coming through and trying to personally talk to them and became really close with everybody in the customer service department, where normally most of the non-customer service staff didn't really spend much time there. I was there every day talking to people saying what are people saying? Can I listen to what you're hearing? But it didn't really occur to me that I could like talk to them myself. Until about a year later, when I got to start working with a user researcher. And there was kind of a shift in the team too, and it started doing usability testing.
And then we started really seeing how people were using what we had built and where things were going wrong. And it was like, oh wait, hold on. We're really getting stuff out of this. This isn't a drag on us. I thought this was going to be, you know, it's just going to be someone complaining and then we all feel bad at the end.
No, this is inspiring us. This is motivating the team. Everyone is fired up. Now we really understand why people aren't completing this onboarding sequence or whatever. And then soon after we started actually interviewing them. And that was when things really took off.
I was observing interviews for, I think a couple of months before I actually started interviewing myself. Because there is a way of doing it that you need to learn. And so that's really when I got into interviewing and then once I got into interviewing I couldn't get out of it, because it's just so enlightening. It was just revelatory for me as a product manager, because I went from looking at spreadsheets, which I already said are my happy place, and analytics and stuff like that. And then being like, okay, how do we get these metrics to move? Okay, let's see the people who did this, did that. Those people, that's the result we want. If we get more people to do this thing, then maybe deal it out, okay, let's run an A/B test. Like that kind of decision-making and it wasn't working. But then we started talking to people and understanding what they were trying to do. And then all of a sudden things started to click.
And the team was motivated. And instead of talking about what is this card again? What are we trying to do? Where is that? What's the rationale for this? Everybody just got it because maybe they had been in the room with us when we had interviewed someone or they had heard clips of it, or they had seen quotes from it or they had been in a debrief for one. So that was about six years ago.
**Joy Heron:** So from this in these six years you started out, just trying it out and finding you liked it. And now six years later, you've written a book on the topic. So how did your learning journey happen over this time? Did you do a lot of really intensive, theoretical learning, right at the beginning when you were starting? Or did you just pick up these things over the years?
**Michele Hansen:** So in the beginning, there's mostly observational learning. So I was fortunate enough to be able to observe a PhD user researcher and an experienced design leader do interviews. And it was really helpful learning from them and also reading books recommended by them.
I read a lot of Rosenfeld books. So Indi Young's deploy empathy– sorry. Oh my gosh. That's my book. Indi Young's _practical _empathy. One of my favorites, also books like _Service Design_ is another one I think I read around that time. _The User Experience Team of One_ is a good one, even though there was multiple of us, it spoke a lot to what we were trying to do.
And also other product books at the time, too. Interviewing helped me apply them. So Marty Cagan's book _Inspired,_ that one is one of my favorite product books and knowing how to interview helps me apply that book so much better. So it was kind of a combination of observing, starting to interview myself, and reading. And then also when we were doing those interviews, we were, you know, we're in a larger company. And so we were processing those interviews. So we would get transcripts made. We would be clipping out quotes from them. We would be making journey maps, stuff put on Post-Its ... You know, all those perceptions about UX people loving Post-It notes and keeping 3M in business, like yeah, that was us. So I think also the practice of reading the transcript of what you said and listening back to it is so helpful for learning. Because then you'd be like, oh, I shouldn't have said that, I could have started this differently. Okay, next time I'm going to do that. And I mean, I even still do that. I still read stuff and I'm like, oh, I could, maybe I could have said something different there. But then it's just, okay. This is just part of the learning, it's like reading it, understanding, okay, what could I do better?
But also I learned so much from this anyway, despite the fact that I didn't say the perfect thing every time.
**Joy Heron:** So, the question that I have is that I am a developer. I think a lot of listeners of this podcast are probably developers or maybe architects or involved in the software development process.
My question is, as a developer, do I have a place in this customer interview idea? Can I also do customer interviews or is that just something that the product people do?
**Michele Hansen:** Yes, it is absolutely something that you can be involved with. And don't just take my word for it. Stripe involves their developers in the customer interview process too.
**Joy Heron:** Okay, easy answer. So with me as a developer, specifically what value can I get from doing customer interviews?
**Michele Hansen:** The big one is really understanding why people need what you're building, which, if you're used to receiving tickets from a project manager or product manager, I found that there was very often a lot of conversation on okay, what is this for? Why do people need this? What's the business case behind this? Basically, why are we building this? But then also, what does it need to be anyway? And when I was working as a product manager, I found that once we started bringing developers into the interviews, into the usability sessions and just having them sit in the room with us, they didn't even have to ask questions.
All of a sudden those conversations were so much faster and so much easier because they just got it. They understood who the customer was, what they're trying to do, what their whole context was. And things were less like a chore and they're more like, oh yeah, I want to help that person that we talked to. Now, of course, you're helping thousands of people who are doing the same thing, but having that specific example of someone in your head really helps to put you in their shoes and understand not just how your software should work, but also what is the broader thing that someone's trying to do, where your software is only one piece of it, and how can you make that whole process easier for them?
And it just becomes so much more enjoyable to work on things when you know what it needs to do and why and who it's going to help. And so whether it's asking questions yourself, like Stripes developers do as part of a group call, or simply sitting in the room, there's so much value in having the developers there.
And there's also value in being part of the analysis process too, in being part of the tornado of Post-It notes that can come out of analyzing interviews. One of my favorite studies on this is actually really the first studies on this, from 1994, called _Voice of the Customer_. And this is sort of the seminal paper on interviewing customers. And it's in the context of usability studies. And so this is back in the nineties when they had the usability labs that people would go to and then interact with things there, you couldn't do it over Zoom like you can now. And so they tested getting insights out of the interview.
So they took the transcripts and the videos of the interviews and asked different groups of people to analyze them. So one of those groups was a group of college students, another group there in a sort of experimental term was the user research expert, and another group was engineers who actually worked on the product in question. And they found that the groups of engineers were more effective at pulling insights out of the interviews than the user research expert.
**Joy Heron:** That's really cool. I think one thing is with the developers, what I know from my personal experiences, is when we work on something, we get emotionally attached to our software and so for me, one thing I personally think that customer interviews can help with is making sure that we're building the right thing.
That we're building things that people actually want and need. Because if we aren't and then it turns out this feature is not really useful for anything then it's really hard for developers. I spent so much time and effort and energy investing into this feature that I've been building. And now you're telling me all of a sudden that this wasn't actually worth it. It's really like a punch in your gut.
**Michele Hansen:** It's really dispiriting and demoralizing.
**Joy Heron:** Yeah, exactly. So I think it's a good idea. You know, if we can be sure that what we're building is actually going to be used and be useful then it makes a lot of sense for us to talk to people.
What I have difficulty with sometimes is actually getting to talk to the customers. I want to talk to customers, but then it's like sometimes I have to talk to somebody in order to be allowed to talk to a customer. And I have difficulty sometimes with getting that permission from a boss or from a customer to talk to their customers.
I don't know if you have any resources or anything that you could point to about how we can do that part a little bit better.
**Michele Hansen:** So that's always tricky. I would say where I would start is if your company already has a user researcher or product manager who is doing this work. In some cases it might also be your business intelligence team doing it too.
If they're already doing sessions with customers, whether those are usability or interviews, see if you can just sit in the room with them. Chances are, they will be excited that you want to be there. They are not the ones who are going to gatekeep, they are going to be excited that someone is showing interest.
And just ask if you can just sit in the room and listen. If you're having a boss who is questioning you doing this, and you don't have a user research team, that's going to be a bigger challenge. It's always a challenge to sell user research within an organization. In that case, you have to be a little more strategic.
Usually the approach that I recommend is try to make your boss think it's their idea. So somehow get them to read a Clayton Christensen book, and then they will be all fired up about jobs to be done. And, you know, oh, what is the thing people are hiring our product to do? And like, let's figure it out and everything, and then that'll kind of help with your inertia.
And then maybe they'll get somebody else running the interviews and you can tag in and be like, "Hey, I'll help you with it" or whatnot. Cindy Alvarez's book _Lean Customer Development_ has some tips on this, though it's written from the product manager's perspective. It definitely is more unusual for a developer to initiate a customer research effort, but don't let that hold you back.
**Joy Heron:** For any listeners we'll try to get links to all of those books and things and put them in the show notes to make it easy to find them. One thing I find interesting is that the title of your book, you call it not "Introduction to Customer Interviews" but _Deploying Empathy_. Could you tell me a little bit about how you came up with that title?
**Michele Hansen:** I think it was a shower thought kind of title. I didn't know what to call it. I initially had this very long title of what I was doing ... well, initially it was just Michele's customer research guides. Because I was just writing this so I had one central place to send other founders when they asked me how to talk to customers. We're usually developers who have transitioned into being founders. And I didn't know what to call it. It has to be a pun, because I just love puns, and I was like, wait, hold on.
So if it's deploy empathy, then it's like deploying, but you're not deploying code, it's empathy. But then people also use the phrase of deploying empathy in a situation. And so I was like, oh, this is okay. I remember running out of the shower in a towel like to check, you know, I want my name and seeing if I could get the domain, and lo and behold deployempathy.com was available.
I also grabbed deployingempathy.com because I wasn't quite sure. I think I wanted to make it really clear to technical people that this was a book for them too, so somebody who is not from a technical background, to them the meaning may just be that meaning of deploying empathy, without any sort of code implications of it.
But a developer, they see the word "deploy" and they're kind of like, oh, is this for me? So it makes people feel welcome. In a field where a lot of the books are written for user research people. Some of them are written for product managers. A lot of them assume a lot of user experience background.
And so I wanted to make it very clear that this book did not– that developers and technical writers, and it turns out a whole host of other people too, that this book was as much for them as it is for product managers.
**Joy Heron:** Well, there's also a rubber ducky on the cover, which is like when we programmers ... I had a rubber duck on my desk while I was working for a really long time.
Because they always say, if you talk to the rubber duck and explain it to the rubber duck, then you'll figure it out. Is that the metaphor you are going for with the cover of your book?
**Michele Hansen:** So it's a spin on that, but the rubber duck is definitely a dog whistle to developers. I mean, normally the word dog whistle is used in kind of a negative connotation, but it's like hint, hint, wink, wink.
Same story, but the idea that I apply it in the context of is to imagine yourself as the rubber duck, when you were talking about something.
**Joy Heron:** Okay. so I am the rubber duck. It's not that I'm talking to somebody, but that I'm listening. Interesting. Very nice. Another thing I found interesting about your book is you use a definition of empathy which is not one that I heard growing up.
So growing up, I always learned there's some sympathy and empathy and sympathy is like, you're just saying nice things to people. Like when they're sad, you say "I'm sorry, that's too bad." And then empathy is you're actually able to feel what they're feeling.
But you use a different definition of empathy in your book. So could you maybe tell us a little bit about that definition that you use in your book?
**Michele Hansen:** I love this, I think this is such an important thing to talk about and it actually wasn't even something I originally planned to talk about in the book, but I had readers ask me a similar question to this.
And so I'm happy to talk about the difference between empathy, sympathy, and compassion. I think compassion also belongs in there. So sympathy, as you said, is usually something to the effect of, "I'm sorry that happened," or "I'm sorry you feel that way," or "It's terrible that happened to you."
And the problem with those phrases is that, first of all, they center the person speaking first. So all of those phrases start with _I_ am sorry. When the other person is hurting. The other problem with them is that they isolate the other person and they emphasize that the other person is the only one experiencing this. And you are not.
So it places distance between the person speaking and the person receiving that. So saying, "I'm sorry you feel that way" says only the other person feels that way and you don't see it or agree it, or understand it. And we say these things without really realizing it, especially if we've learned to say them this way. Brené Brown talks about this a lot that, that sympathy very often counterproductive and it makes someone feel more alone, and feeling alone is one of the worst feelings you can make someone feel, being alone and shame, as she talks about.
And then moving on to compassion. I think of compassion and I don't think of words, I think more of someone explaining how they went through something difficult and the person they're talking to simply clutching their own heart. Right? Because they're feeling it, you know, and you see it in the body language, especially. And compassion also comes through as an action. You know, you see someone who's cold and you put a blanket around them, right? I think of that as compassion; someone is hungry and you give them food and, you know, you help them with that.
Empathy is different. The definition I use in the book is from Brené Brown, Indi Young, and from Chris Voss, the author of _Never Split the Difference_. Very different people. One coming from a social worker research perspective, one coming from a user research perspective, and one coming from a former FBI hostage negotiator's perspective.
And this definition is basically that empathy is seeking to understand someone else's experience, even when it differs from your own. Basically validating their experience and putting your own opinion of it aside. And so what it means in this context, in the software context, for example, let's say we're building invoicing software, it's understanding the entire process someone goes through. Not just a click to create an invoice, but understanding, oh, okay. Wait. So first it started out that they were negotiating this deal with this company, and then they had to deal with the procurement portal that that company uses with the invoicing people. And then they had to go through all of these steps to get set up with the invoicing, like the procurement portal.
And then when they finally went to create the invoice, here's all of the different things that they had to do. And then this is what their process was to resolve it. And so it's understanding that entire activity that they were going through from their perspective. An example of this is when you look up a recipe and it says it takes 15 minutes. But then it turns out the recipe assumes that everything has been pre-chopped and your oven is already heated and the water's already boiling. And that recipe does not understand the entire process that someone else is going through and all of the different hurdles and barriers and steps that they're going to face in the course of making dinner.
And so how do we make software that really understands the entire process that someone is going through? Even if we think it's ridiculous that they're still using Internet Explorer, we have to understand _why_ are they still using Internet Explorer? You know, what can we do to make this easier for them?
Oh, it turns out the step before they use our software requires a ton of paperwork and it's like ten steps and they really hate it. So by the time they get to our software, they're super annoyed and irritable and tired. And that's why they're having trouble with our software. It's not because anything is wrong with our software. It's because they're already tired from all this other stuff they were doing.
And so empathy is understanding someone else's context and someone else's perspective, and it actually doesn't require that you feel the same way they do. And in fact, it's actually kind of distracting. So as we sort of talked about with sympathy, when you say, "I'm sorry, blah, blah, blah." Right? This happened to you. You're centering yourself. And if someone starts explaining to you a process they went through, even if it's a boring, normal, everyday business process like creating an invoice and you, all of a sudden, you start to feel annoyed at this process and you start to feel tired. Then you're centering yourself again. And that's counterproductive.
The whole point is to understand their perspective on what they are going through. And it's helpful to understand the emotions behind that, but it's one of those things where you don't really need them to say I was frustrated, because if they spent four hours working through paperwork and they were very tired at the end, you don't really need to hear them say it was frustrating because it's very clear that they're frustrated by it.
**Joy Heron:** I do really like that definition. I think I've always felt like I struggled a little bit with empathy. When we're talking about usability testing or something, then I can kind of get it. And the reason I can understand the user in that context is because it's something that I'm familiar with.
If I'm asking a user to try to use my software and I'm looking at what they're doing and if they're understanding everything, because it's my software, I've had similar experiences. And so I can understand what they're going through. But I think in general, my question with that definition is what about when I don't understand their perspective? This definition of empathy, it's talking about needing to understand someone else's perspective and also recognize that that's a valid perspective to have. But what about that first part? If we have difficulty actually understanding where they're coming from. So I have a little bit of a question mark there.
**Michele Hansen:** So this is where asking questions and learning how to dive into their experience is really helpful. And also just finding it fun. So first of all, empathy is a learned skill. And this is according to Brené Brown. A lot of us don't learn empathy growing up, right? If you're crying, you're told to stop crying. It's not, "Oh, what's going on? What happened here?" Right? Some people have parents who do that, or they learn this as children, but for a lot of people it's shut up, stop crying, and that's not empathy.
So if you had empathy modeled to you as a child, maybe you understand it as intuitively as an adult, but for most people it's something they learn. And it's okay to learn it. I learned it. I had to learn how to listen to people and understand how to reflect back their experience and dive deeper.
The other thing there is that a lot of us we're also conditioned to not ask questions. And we got chastised for asking "stupid questions" or basic questions when we didn't understand something. And we also may have been conditioned to not ask people questions about their lives, because maybe we were told that that was intrusive or we were made to feel bothersome when we did that.
And in this context, that's what you need to do. First of all understand that those hesitations you have are completely normal and it's okay to have hesitations about this. You have good reasons why you have those hesitations. They come out of your life experience. They've helped you probably. Um, but in this context, we try to put them aside and say, okay, how can I understand what this person is going through and why?
And this is also why I have five different scripts in my book, so that if you're really stuck on, okay, how do I ask this person? Why did they cancel? Like where do I even start? Or how do I figure out why they switched to using this product? So I can find more customers, right. There's scripts there.
So there are training wheels, so to speak, and my hope is that people customize those scripts eventually. But the idea is that you can just grab them and go and run with it. And so you don't have to try to figure out how do I ask them more about this?
And the book also includes a lot of tips for following up with people. And I think something that surprises people is that the best follow-up questions are not questions at all. They're instead simply reflecting back what someone has said or leaving a pause for them to fill so that they feel there's more space for them to say what they're saying. In many ways that part of the book, "How to Talk so People Will Talk," is kind of the most important chapter of the book, because it really goes into the nitty gritty of how to get someone to keep talking in a way that is not spelled out in a lot of other books.
**Joy Heron:** I have actually read that section of the book. It's called "How to Talk so People Will Talk" and it goes into some different tactics about how to talk. And my reaction to that section was actually, wow. Almost none of these things are things that would come normally to me, or I feel a little bit uncomfortable doing that.
One of the tactics is mirroring. Like when someone says something, you just kind of rephrase what they said. It's just interesting. So in your experience, was it really difficult to pick up all these things and it takes a lot of practice on, or is it something that you can pick up pretty easily?
**Michele Hansen:** It definitely took practice. I would say for the first couple of months definitely I was doing this it really took a lot of focus for me to sit there and be like, "OK, listen, don't try to relate to what they're saying. Try to dive deeper into what they're saying. Just repeat it back to them. Even repeat it back wrong. To prompt them to elaborate, put them in control of the conversation, even though you're actually running it, give them the rein, make them feel like they have the rein, so to speak. Don't try to show them how smart you are, just try to listen to them."
Right? Because something I talk about in the book is that I have ADHD. Now everybody has a different experience of ADHD. But let's put it this way, people with ADHD are not known for being calm and listening to other people. As a group, we're not especially renowned for it. And so it was really hard for me to learn this.
And I think something I try to stress is that you don't have to read this book and then change how you talk to everyone in your life. It's okay that it's not natural to you to mirror back what someone is saying. That's okay, you don't have to do this in your whole life, but for that half an hour or an hour, once a week, when you're talking to a customer, that's when you do it. Think of it like acting, think of it like you're putting on a costume and this is how you act in this specific scenario to understand what people are trying to do and then how you can use that to build software.
**Joy Heron:** When we talk about acting, that's seems a bit odd to me. I don't know if I'm allowed to say that, but, it feels like, okay, I could _act _empathetic. That doesn't actually make me _be _empathetic. I don't know. Is there a distinction really between the two or by acting empathetic can you become empathetic? Just by practicing or something like that?
**Michele Hansen:** This is where those definitions of empathy are really important. As we were saying earlier, if someone is telling you how they spent four hours dealing with paperwork, but by the time they get to your software... even if they haven't told you the emotion that they were feeling, you can imagine how you would feel in that scenario and how frustrating that would be.
And so even if you have not done anything that is outwardly compassionate, which is where I think those two words really get mixed up a lot, even if you haven't said to them, "Oh, can I help you with that paperwork?", which would be more of a compassionate thing, you're still being empathetic. You know, I think we forget that most people don't have people in their lives who will just listen to them without any judgment or trying to contradict them.
I think so often in our lives, when you say, "Ah, I'm feeling really down today," someone will say, "Oh, it'll pick back up. Don't worry." That's not empathetic. Like that is toxic positivity. That is _not_ empathy. Empathy is saying, "Yeah, it's going hard today." That's empathy. And so I think all of this about feeling empathetic, I think we confuse that with compassion. I am in favor of compassion, but we need to stop mixing those two things up. I see this all over the place and I hear it from people like you saying, what if I can't be empathetic? I've had people who are either diagnosed or believe they have autism who have told me, well, I've been told my entire life I can't be empathetic. Can I do this? And they're also very sensitive about it too, because people have told them they can't be empathetic, which in turn sometimes means they can't care about other people and it's really, really bad.
I don't think empathy requires feeling the other person's feeling. Because again, what I was saying before, if you're feeling what the other person is feeling, you have just turned it on yourself, then you need to regulate your own emotions, right? Rather than just understanding what their experience was. And maybe for some people it's harder to understand the emotional side of something, but even if you still understand the functional side of it and you understand, okay. And all that paperwork, they also had a coworker coming in who was bothering them every 20 minutes. Even if you don't necessarily understand the social side of things very naturally, you can understand that this other coworker coming in and bothering them every 20 minutes was bothersome. Or that they have to go get approval from their boss for something. And it's a long process. That's a social component to something.
So you don't necessarily have to be intuitively or innately emotionally attuned, or socially attuned to use empathy or be empathetic. Empathy is a way of acting, of comporting yourself. It is not a feeling. Empathy is not like anger, right? It's not something that you just _feel_, it's something that you _do_, and you can make a conscious choice to be empathetic, so that when someone says, "Man, I'm having an awful week," you say, "Yeah, you're having an awful week?" And you don't say, "Oh, it'll be better next week" like it's a decision that you make.
**Joy Heron:** That is very interesting. And it's something that is in your book and something I've been thinking a lot about recently, because it's something that's new to me. I think I need to process that a little bit. One other thing I wanted to ask you if you have any advice is it seems like with these customer interviews, you have to improve your listening skills. Do you have any tips or tricks about how to do that?
**Michele Hansen:** That's such a good question. Because as I mentioned before, it's something that I have really had to learn. And I think a big challenge for me with listening was on the one hand calming down my brain a little bit.
And then also removing the desire to impress the other person or show them anything about myself. And again, I don't know if this comes out of being an ADHD person where when you're growing up you're always told that you're not doing things right. And that you're not going to be as successful as other people and all these kinds of things.
So you start having to prove yourself a lot. And I found myself just doing that in conversations. You know, where someone says something and then instead of diving deeper into their experience you relate your own experience instead. And for me it was a big shift in the listening to allow myself to be curious about the other person and to recognize that they enjoyed that. fMRI studies show that the parts of the brain related to pleasure and enjoyment light up the most when somebody is talking about their own experiences to someone else. They don't light up the same way when they're listening to someone else tell them about it.
So when you are listening to someone, knowing that they are enjoying that and that you are allowed to keep asking them and that you are allowed to be curious. And then my mind gets all excited about like, "Ooh, okay, wait. So wait, what happened here?" And I liken it to poking through their mental closet and going, "Ooh, what's in this drawer?" "Oh, what's going on over here? This is interesting." And actually it becomes difficult to stop people from sharing too much and getting into a place of, "Okay, thank you for sharing that with me. Can we go back to something you were mentioning earlier, that's more relevant and also not in oversharing territory?"
It's really great how many people I've had come to me who said the first time I did this, I was so afraid that it was going to be ten minutes and I wasn't going to get anything out of it and they didn't want to talk to me. And then the third one, I couldn't get off the phone and I had to cut it short at an hour because they just kept talking.
But again, you know, that's something that you can practice. And I mentioned with the "How to Talk so People Can Talk" chapter that even if you don't have to use these things in your daily life, it really helps just to try them out there. So for example, if your spouse comes home and says traffic was terrible today, just say "Traffic was terrible today?" and let them talk and be a witness to their experience.
**Joy Heron:** Well, I think that's a pretty good end to our discussion today. Is there anything else that you would like to add?
**Michele Hansen:** I would like to add that technical people can talk to people just as much as anybody else, whether this is because I'm the child of software engineers and married to one or ... Research shows that technical people can also be insightful in customer situations.
Don't let that stereotype that developers can't talk to people hold you back. Anybody can learn empathy. Anybody can learn the skills to understand their customers. So they know what to build. They know how to get customers. They know how to stop. Turn. You can do this.
**Joy Heron:** Thank you. Just to wrap up, can you let us know how we can keep up with you online and where we could buy the book?
**Michele Hansen:** Yeah. So, you can buy the book on Amazon or on the book's website, deployempathy.com. You can buy a Kindle version or PDF. I'm also doing an audio book that's being released weekly as a private podcast. We're on the third part right now. You can also preview the first five chapters of the book, at deployempathy.com.
You can find me on Twitter at @mjwhansen. You'll also find a link to the Deploy Empathy newsletter there, where I write about ongoing topics, things about the book and whatnot. And of course, as you mentioned, there is my weekly podcast, Software Social, where Colleen Schnettler and I – Colleen is an electrical engineer turned developer – talk about our businesses every week.
**Joy Heron:** It's a great podcast. I'll just slip that in. I really enjoy listening to it every week. Well, thank you so much, Michele, for coming on the show and talking to me, I enjoyed it. And thank you to you for coming on the show and to all our listeners, until next time.
**Michele Hansen:** Thank you so much Joy.