Episode 586 | Mastering Customer Interviews with Michele Hansen

Rob: In this week’s episode of Startups For the Rest of Us, I talk with Michele Hansen. She’s the co-host of the podcast, Software Social, a bootstrapped entrepreneur who has grown her SaaS to north of $1 million with her co-founder, and she’s written a book about mastering customer interviews. It’s called Deploy Empathy: A Practical Guide to Interviewing Customers. Simply a good book.
I’m going to be honest. Her experience, learning, and then practicing customer interviews is pretty unique, and you can tell in the book that this is not just another book about doing jobs-to-be-done, customer development interviews. She has a very unique take on it and you’re going to enjoy it, even if you’re concerned or scared about doing customer interviews. You don’t have much interest in them, this conversation’s going to be enlightening.
You can go to deployempathy.com if you want to check out all the ways you can buy the book and learn more about Michele. Of course, you can check out her podcast, Software Social. Without further ado, let’s dive right into my conversation with Michele.
Michele Hansen, thanks for joining me on the show again.

Michele: Thank you for having me back.

Rob: Folks might recall episode 524 of this very podcast. It was called Bootstrapping a Commodity SaaS, where you and your husband, Mathias, came on and talked about your trials, tribulations, and victories with Geocodio.

Michele: Yeah, that was about a year ago or two.

Rob: This is 586, that’s 60-some episodes, so yeah, a year-and-a-half. And I would like to note that in the book that we’re going to talk about today, your book is Deploy Empathy: A Practical Guide to Interviewing Customers. You revealed that the two of you have bootstrapped Geocodio to north of a million dollars ARR. That is awesome. Congratulations.

Michele: Yeah. Geocodio turns eight in January, which is pretty wild.

Rob: Yeah, and when you started it, didn’t it do $31 in the first month or something like that?

Michele: Yes.

Rob: You were like, hey baby build this little fun tool, and now that is an amazing, life-changing startup for you guys. Amazing, life-changing product.

Michele: Absolutely. When we started, it was actually a side project to keep another side project going. It never even crossed our minds that it could be our full-time job, and here we are now. I have actually worked on Geocodio longer than I ever worked for anybody else at this point.

Rob: Yup, and it’s a […] SaaS it’s that the flywheel that just gets going in the first year. It does X thousand, then the next one it does 2X, and then 3X. Pretty soon, you’ve built this amazing two-person SaaS company that makes seven figures and is the envy of so many people that we know. It’s like more people do it than you think but also not as many. A lot try and don’t get there.
What do you think that you and Mathias have done right? What are two or three things you might say that this is what created the success for us?

Michele: Do what you said about people wanting to get to this point. That’s something that drove me to write the book because having built a company I feel a responsibility to help others do the same. Whether that is investing to help them, we’re excited to be investing in kinds of […] or just helping them where we didn’t have help or we didn’t really have mentors throughout this whole process.
The one thing that we do is we listen to our customers and we let that guide us. That was a huge motivation for me, and getting all of this stuff about how to understand your customers and how to talk to them out of my head and on paper as a way to help other people do what we’ve done and then some.

Rob: Yeah, and I think that’s a good way to think about it or I like that way that you’re thinking about it because you have this information in your head. My guess is you’ve probably heard other people talk about customer interviews or you’ve read other books on it, and they just didn’t quite sync up with your experience.
I’ll put it this way; I’ll speak for myself. I wrote Start Small, Stay Small in 2009, published 2010 because I was pissed off at all the […] books about starting up and how none of them were for us, none of them were for bootstrappers, none of them talked about being a one- or two-person company. Everyone expected you had venture capital. I was so angry and I was like, well I’ve done this. I just need to get this out.
I’m not saying you’re as angry as I was, but I am curious if you looked around you’re like, you know? My take I think would be really helpful and it isn’t out there yet.

Michele: Yeah, there are a lot of great books on user experience research but basically—with the exception of The Mom Test—a lot of them are not written for people who are trying to start their own companies without funding, and as you said, there are those assumptions of like, oh, will it bring this to your team of people? And like, you know? You want to get some budget for this. Or like, think about budgeting for travel to visit them.
I started out doing user research as a product manager in a bigger company, and those things were not off-putting to me at the time, but throughout the years and throughout having this experience of jumping on a call with a founder and just helping them figure out how to interview customers and I would recommend the books that I had used when I was learning how to do this, people would be off-put by it because they’d be like, oh, I don’t have a budget. I don’t have a dedicated researcher. I don’t have a dedicated UX person to prototype with them. I don’t have all these things that this book is assuming I have. Is this still for me? It made people feel like this was not something that was for them or that they weren’t welcome, and something that they had already built up some fear around of talking to people and understanding it.
There was already a large amount of fear built up around just the interaction itself of interviewing someone, and then adding on this additional layer of insecurity around, oh my God. This is only for people who have funding. It’s only for big companies. What am I doing here? I don’t belong here.
The goal is to make it approachable to everyone, but also think about how The Mom Test is on a lot of people’s shelves and it does such a great job of talking about that stage when you’re figuring out what you should build, whether you should build it, and how do you get that really early feedback from people.
You also need to get feedback if you’ve been running a company for 5 years or 10 years, or once you’ve got it going how do you stop churn, or how do you figure out why people are bouncing off of something, or how do you figure out why people are happy so you can get more people who would be happy. There are all these other things that you can use research for, and there just wasn’t really a book geared towards the indie software experience.

Rob: That’s why it’s so helpful and why it resonated with me. As I read through the book, your examples all feel very much in line with my experience and the experience of the founders around me, and it’s because you are a practitioner both of customer interviews and of being a bootstrap founder. If folks check out your podcast (Software Social), they’ll hear you and your co-host (Colleen) talking about this kind of stuff.
It was probably six or eight months ago, but you either did a sample interview on air, where you interviewed her. I don’t remember what it was, but that episode struck me as really interesting because hearing the insights, and you have at least one transcript, maybe a couple in this book of sample interviews.
That’s what I like about this book and that’s why folks listening should pick it up. It’s for $10 on Kindle and $25 on paperback. It is crazy practical. There’s a tiny bit of theory—just enough—there’s a framework, but then it’s like, when should you do interviews, recruiting participants, how to talk so people will talk, sample interviews, sample scripts, and if you really want to hit the ground running you flip through this. And you also give either the justification of when to do it and why.

Michele: Yeah, I wanted to make it really practical for people, bearing in mind that they may already be feeling overwhelmed by this. I don’t want to bog them down with theory. There needs to be enough that it needs to be woven into it, and ideally you could sit down, skim the book. There’s even a section at the back of the book that’s like, if you just want to skim this here’s your little cheat sheets for the stuff you need and you can just get running and go on it.
Actually, being a practitioner, that was something that I didn’t realize until the book had been out for a couple of months at that point, when someone pointed out that most of the books on user research are written by consultants, which makes sense because the book is written for them in a way.
And there are very few books that are written by practitioners, like Cindy Alvarez’s Lean Customer Development comes to mind, for example. Never mind a small SaaS practitioner, so yeah. The ideas you can just pick it up, run and get started, and have what you need there as reference if you need it later.

Rob: I’ll quote you from your book. People sometimes quote me what I’ve said on a podcast or in a book and I’m always often like, did I say that? Because either it’s like, huh, that’s actually really insightful. I’m happy that I said that. Or I don’t remember saying that and that sounds kind of dumb, or I don’t agree with it anymore.
Anyway, I want to read this quote from the book because I was struck by the title. It’s Deploy Empathy, and I had to think of deploy as a code, but if you’re deploying code… Then I was like, no, it’s not that. I think it’s bringing empathy to the customer. Actually, a piece of this you took from a different definition.
There are embedded quotes in here, but the bottom line is it says, “Empathy is about understanding how another person thinks and acknowledging their reasoning and emotions as valid even if they differ from your own understanding. In this context, in the context of this book, empathy means entering the other person’s world and understanding that their decisions and actions make sense from their perspective.”
The subtitle is, A practical guide to interviewing customers, but the title is, Deploy Empathy. It’s an unusual title, I’ll say. What brought you to Deploy Empathy?

Michele: I wanted to have a title that was sort of a wink to developers, so that they knew that this was a book for them. When I initially started writing the newsletter which became the book, it was very much geared towards indie developers and makers.
The audience has since expanded significantly beyond that, but that was really the core group of people. I thought by using the word ‘deploy’ in it, it’s like you’re deploying code and what you are deploying has empathy for your customer embedded into it, but you’re also using empathy.
What I didn’t realize until well after I had launched the book, which I wish I had done more research on, was that apparently deploy empathy is also a Gary V phrase and I had no idea about that. It’s basically really hard to search for on Twitter because you get all these Gary V people in there.
I seem to have a talent for picking ungoogleable titles because Software Social you get all this stuff about social software, and it’s like ugh. Don’t ask me for naming advice, but yeah, it’s a very subtle wink to developers but also that a non-developer would also understand the title at the same time.

Rob: Got it. I totally picked up on the ‘deploy,’ and I thought to myself, am I reading too far into this? Is there […] symbolism?

Michele: Do you have it? Flip over to the back cover. Do you have a copy on you right now?

Rob: Yup. I have a PDF you sent me when we hooked up.

Michele: Okay. On the actual book—I’ll have to send you a picture of this—there’s a little code block that says, “Empathy deploy, Initializing mental models… Building interview skills… Softening tone of voice… Configuring recruitment template… Preparing tools… Loading scripts… Installing debug protocols… Processing results… I thought it was very clever by doing that.
Rob: That’s the tell. That’s the confirmation. It’s funny. Let’s talk about feature requests as customer research. Your book is nice and concise, about 200 pages, and then there are 100 pages of extra stuff. There are transcripts, sample interviews, and appendices. When I looked at the appendices, I was like, oh yeah. There’s a whole appendix aimed at single founders or people without teams and all that. One piece of this, Chapter 56, is Feature Requests As Customer Research. Want to talk to us a little bit about that?

Michele: Yeah. This chapter came out of a lot of the conversations I had with readers of the book. I very much did a build-in-public, write-in-public process for writing the book, and started writing it out as a newsletter. When I got to where I was, I had a full draft. I interviewed 30 early readers of the newsletter for those early drafts, understanding why they want to learn about this in the first place, but also what are their fears around this, what have they already tried, what other practical business books they liked and what did they like about them.
One hesitation and fear that came out of those was people feeling they didn’t have time for this on top of everything else you’re doing. Great. I know this myself. If you’re running a company, you’re doing everything from building new features to security issues, to negotiating a contract, to dealing with your account, and to answering customer support, you’re doing everything. The idea of adding something else on top of it, even if people get the point of it, they see the value of it, and they want to do it, it’s like how the heck do I fit this in?
I don’t have time to just stop what I’m doing and just research for a month, which is something Colleen and I had talked about on the podcast. I was always like, no. Integrate it into what you’re already doing. You don’t have to go into a research cave for a month and stop building features.
Feature requests are a really helpful springboard for understanding what people are trying to do without necessarily having to chunk off all this time to do interviews or recruit people for them because people are coming to you. There is a whole chapter on how do you take a feature request and turn it into something that helps you understand what that person is trying to do and why.
A lot of people, when they get a feature request, their first thought is, is this even possible? How would I make that work? What else do I have going on? What is the time? It feels like someone handing you a project, especially if you’re a developer.
Instead, reframing that as, let’s just pump the brakes on figuring out if we can build this, or should we, or where it fits in. Then let’s pull back and say, thank you for the suggestion. I’m really curious, can you tell me what leads you to want that? What are you currently using to get that done? You can understand what someone’s process is and understand how valuable it is to them.
If they’re currently patching together four different tools for that and they would rather use your product, that’s a really great sign. There’s a lot of frustration, hassle, and probably money spent there for just a random passing idea they had, and that’s something they do once a year, then probably not so much. It’s really important to get that context first. You can always make it become a phone call so you can really understand what they’re trying to do and use some of the interview techniques from that method.
If you do use feature requests as a springboard, then you don’t have to do that recruiting process. I imagine after you do a couple of calls with people requesting feature requests, you will want to go, then recruit people, understand better, and you’ll really see the value of it.

Rob: And you have a list of questions that if the feature request happens to come while you’re on a phone call, here are some sample questions you can use. I won’t read all of them, but you have questions like, can you walk me through the context on when you might use this? How did this project come about? What do you currently use for this? What did you use for this in the past? Do you pay anything for those other tools? Can you walk me through which one to consider?
It’s really about getting more context and about getting a deeper, more complete understanding of what they’re actually trying to do and what they’ve tried in the past. With any app I built—Drip is the most recent one—I remember getting feature requests, like for the campaign builder, I want an ‘if,’ so I can say if they have this tag, then send them this email. Otherwise send them that email.
It was always like, okay, why do you want to do that? What are you trying to do? Show me the actual emails you’re trying to send, and (a) we can probably do it with two campaigns, but (b) that would be a really clunky way to do it the way you’ve described. I don’t want to do it the way you’ve done it, but we are trying to get to the problem, not their solution.
Oftentimes, customers are not software people. They just think, what’s the simplest? I need a check box here but that will actually ruin your app over time because then you’ll have a gajillion check boxes everywhere. And it turns out that particular one we kept getting variations of, eventually we just need a visual workflow builder.
That’s a better way to express an if, rather than attach or bolted on to the campaign builder like the customers were suggesting. But we never would have understood (maybe) the depth of their request or what they’re actually trying to do without asking questions like you have here.

Michele: Yeah, and very often people express problems as solutions. That can be a little bit frustrating as a product builder. I remember being a product manager. You very often get that from executives too. That’s like, oh we need to add this feature. Okay, but could you walk me through what’s leading you to say it? You can deliver on their problem but maybe in a way that’s more coherent, cohesive, or fits in better with the product vision, but that the problem they’re expressing through that solution is still valid.
That’s where the role of empathy comes into this. The perspective this person’s coming from is valid. The way they’re expressing it to me may not be the most optimal way. Let’s put that aside, let’s try to figure out. What is the problem beneath all of this? What are they really trying to do? What is the context that has made them think about this so much that they are now proposing a solution to me? They put a lot of thought into this. Why have they put so much thought into this? What is going on here?
Then when (as you said) you get multiple people coming to you with these features that have similarities in them, then it’s like, okay there’s some underlying context here, and the fact that we’re getting them so frequently means that this is a shared problem among people. This isn’t just this one particular person with this very particular problem.

Rob: Right, and the interesting part about interviews, usually when I hear someone do a talk about interviews, or I see a book or a podcast episode, I cringe a little bit for two reasons. One to your point earlier, who has time for this? The other one is it’s a little intimidating if you’ve never done them. It’s like a developer thinking about doing sales, where it’s like, oh I really don’t want to do that.
You seem to be a natural at these interviews because, again, I never heard your sample and then when I see the transcript in the book, it seems to just come to you without a lot of effort. Was it always like that, or were the early ones pretty rough and you had to get better, and now you’re really good because you’ve practiced?

Michele: It’s definitely not a natural for me. A lot of the tactics I talk about and how to talk so people will talk, mirroring someone and leaving space for them to talk, how to phrase follow up questions and show that you’re listening, all those things I had to learn. I write this book about empathy from the perspective of someone who had to learn empathy both for other people and for themselves.
I was fortunate enough to learn interviewing under the tutelage of a PhD user-researcher and an experienced design leader. I was basically a silent participant in their interviews for several months, handed books and papers from them about how to do interviews, had them sitting with me, partnering with me as I was doing them for several years.
I really got that kind of experience and I feel very grateful for that. Most people can’t get that kind of experience, especially if you’re a solo dev running your own company. The idea is how do I teach this to people in a gentle way, that if they’re coming at this from the perspective of, this is overwhelming, this is scary, I don’t like regular social conversations, and now you want me to talk to these complete strangers who pay me money. What if I what if I offend them and they don’t want to pay me anymore? There’s a spiral of anxieties that come up, so it was really important to me that the book exhibited an empathy for the reader so that they would understand what empathy feels like on the receiving end through the process of reading the book.
That was something I really focused on as I was writing it, to almost be a bit repetitive about, it’s okay if you’re worried that this is going to be a waste of time. It’s okay if you’re worried you’re going to say the wrong thing. It’s okay. The fact that you’re worried about it means that you care, and that’s a good thing.
You don’t have to push that feeling away. You don’t have to just tell yourself not to worry about it. Anyone who has tried to tell themselves not to be worried about something, knows that you end up just more worried about it. It’s, how do we exhibit that empathy and gentleness to the reader so that they feel confident in doing this.

Rob: And that’s somewhat a unique take. I think because you experienced both the academic side of it and reading all these papers and books, you received an apprenticeship in this by watching the PhD, and then you are now a practitioner in your own company, that there are a handful of people on this earth who have done those three things in this field.
You have such a unique experience that I think that’s why this book will resonate or who resonates with me and I will resonate with founders is because doing any one of those things is great and you could have written a book. It would not be this book. It would have a different feel to it or a different focus.
A piece of the book says this book will help you, and it lists a bunch of things. It’s, launch a product, see if people would pay for something, understand why people are canceling, know why people are buying so you can find more customers, determine which features to add next, figure out how to keep customers and why people buy again. It’s not just, here’s interviewing for academic’s sake. This is what a perfect interview looks like. This is how you accomplish all these things.
As I look down this list, actually it feels a lot, it reminds me a lot of jobs-to-be-done. Most people would have heard of that by now, and there’s interviews. How would you compare and contrast your approach or your mental framework of it to jobs-to-be-done?
Michele: It was very much a jobs-to-be-done book. I am hugely influenced by Clayton Christensen and Bob Moesta. By the way his book, Demand-Side Sales, also has three sample interviews in it, so if that is your favorite part of my book, go get Demand-Side Sales. So good. Very, very influenced by jobs-to-be-done.
I only namecheck it a couple of times because I don’t want to introduce too much jargon into the book. There are references throughout it to a lot of jobs-to-be-done books and at the end of it, but it’s very much a jobs-to-be-done book. It’s, what are people trying to accomplish overall? What is the process they’re going through to do that? And then the idea from a business perspective is if you solve steps of that process and make it easier or faster or cheaper for people to do the things they’re already trying to do, then you will have a better chance of having a successful business because you are solving a real problem that they are already trying to solve.

Rob: Right. I realize I should have said this at the top but folks want to buy the book, it’s on Amazon. You can search for Deploy Empathy. We’ll obviously link it up in the show notes as well. You both have a Kindle and a print version. Have you considered doing an audio version?

Michele: Oh yeah. I did a private podcast presale last fall. I was just recording every chapter, basically, so I release one chapter a week from the end of August to the end of December. I actually just hired an audio editor today to do the post production work, to get the audio book out there.

Rob: Awesome. Are you going to put it on Audible?

Michele: Unclear. I thought I was going to do Audible. I’ve been reading a lot about Audible lately, and it doesn’t seem super great for authors. I might find a way to distribute it instead, but it seems there might be some hijinks going on with how Audible calculates when they pay an author.

Rob: Well that’s a bummer because I have two books on Audible.

Michele: Yeah, but it would find a way. It’ll be available through public libraries.

Rob: Awesome. You have testimonials. You have a testimonial from Patrick McKenzie, says, “Deploy Empathy is far and away the best book ever read on user interviews.” You have a testimonial from my friend and yours, Adam McCrea, founder of Rails Autoscale.
If folks are listening in here at all, interested in learning about interviews, you should go check it out. It’s Deploy Empathy: A Practical Guide to Interviewing Customers Of course, if they want to hear you chat about this stuff as well as running your own bootstrapped company, they can check out Software Social. It’s the podcast you’ve been running for a couple years. Thanks so much for coming on the show.

Michele: Thank you for having me.

Rob: Hope you enjoyed this week’s episode. I’ve been trying to mix up formats with some conversations with founders, some solo episodes, some Q&A episodes, bootstrapper news, conversations with authors and people who are going maybe a little deep, because sometimes you hear a 30-minute conversation about a topic and you realize, I would love to listen to a 10-hour audiobook or read a physical copy on that topic.
Hope you enjoyed the variety of content that I’m putting out for you, and hope to see you back here again next week. I’ll be back in your ears again, as always, next Tuesday morning.