Deploy Empathy: How to Talk so People Will Talk

This is the 2nd post of my notes from the book "Deploy Empathy: A Practical Guide to Interviewing Customers" by Michele Hansen. You can find the 1st post here.

---

When Should You Do Interviews

Interviews are used for both Targeted research for answering specific questions around a project and ongoing research to build general customer understanding to inform broader decision-making.

The process can differ based on the size of the company. But the fundamentals are the same: identify a question, get a sense for the size and value of the problem, talk to people, iterate, and repeat.

[It makes sense to do qualitative research (i.e. interviews) when the size of the problem and business impact is high. As interviewing 5 to 10 customers and analyzing results would take 20 to 30 hours over a course of 4 to 6 weeks. My estimate, not directly in the book.]

How many people should you talk to?

General rule is 5 before making decisions. Maximum of 15 to 20 if the problem is complex. (There was a study quoted that interviewing 12 people can surface 80% of customer needs.). Real rule is stop talking to people when you hear the same thing over and over again.

If you hear any of the following, that's a good sign:

• frequent and painful problems
• people doing things manually
• people already paying for a solution
• problems with solutions that are feasible for you build [anything is feasible with software. so I'll read this as fast to build and easy to maintain/support as a solo operator]

Short surveys for ongoing research

One or two questions surveys are still valuable and get higher response rate than longer surveys. Some good questions to ask:

• What did you use before you used [product]?
• How did you come across [product]?

Also ask questions that are easy to answer. For example "what did you use before you used [product]?" is factual and easier to answer vs. "why did you switch to [product]?". The later asks for emotions and thoughts and decision-making.

Do not ask open ended questions like "if you could change anything about [product] what would it be?" Because you'll get responses about people wanting it to be free or cheaper.

Interviewing new customers

• Great for marketing ideas and even landing page copy, as people might be using your product in ways you never thought about
• Do it after they have used your product for 1 to 3 months. Don't do it too soon (like 1 to 2 weeks), otherwise they'll think it's an onboarding call.

Interviewing happy and canceled customers

Interviewing canceled customers seems intuitive to most, you want to find our why they canceled, and how to prevent others from canceling, etc. Interviewing happy customers is valuable too, as they have the exact use case your product is serving.

This is funny...on interviewing happy customers:

"Sometimes people are afraid to poke the bear and ask them why they are happy"

[aside] haha, precisely. I have a 3 students who have been paying for coding mentorship every month for 14, 10, and 9 months (!). I've never asked them why. I think I know what value I provide as a teacher and guide but I've never really asked them directly. And my goal has been to 'graduate' them and make them self-sufficient so churn is okay and expected. But teaching is very different than a SaaS product. So that's okay I guess.

But in all seriousness, I'd be willing to bet that most SaaS founders who have not yet hit some significant revenue (100k to 1M?) believe it could all disappear just like that. Like if they try to talk to "happy" customers, the customer will be like "what!? I didn't realize I was paying for this" and promptly cancel. Unlikely! but brains are weird and such fears are real.

---

Recruiting Participants

Here we go. Now we talk about how to find the key ingredient for interviews, an interviewee! Social media and forums for non-customers and email/survey for current/former customers.

Reddit
There are awesome scripts in the book with exact copy you can use to make reddit posts. (Too much to copy/paste here. Get the book!)

General steps:
0 Identify your niche, your audience. And find subreddits for that niche
1 Decide who you want to talk to and who you don't
2 Write you post (ex: "Looking for people to talk to about complexities of scheduling meetings - $10 Amazon gift card if you participate!)
3 Sort through the applicants, schedule and conduct the call
4 Send the gift card while you're on the phone at the end (and consider asking them to post a comment on the original post like that the interview was legit. "Just FYI, I talked to this person yesterday. They were super nice and it wasn't a sales pitch, and I got the gift card. Not a scam!)

Twitter

Here the key is to find people who have experienced the problem and are already talking about it, by tweeting negatively about a competitor or about the process. [not sure if this is relevant for Shopify merchants, do they tweet about their problems? I think more on reddit, fb groups, and slack. But this is relevant for my reading/book notes tracking app idea]. Once you find relevant people, do research on them by reading tweets/blogs, and reach out to them. Either by replying to their tweet or DM.

LinkedIn and Facebook Groups also an option.

[tool] Demand Curve - growth consultancy with a guide on how to do LinkedIn outreach.

Email

This is for existing customers whose emails you already have. Author does not recommend doing cold email outreach for research purposes. People are used to getting a lot of cold sales emails and you don't want your research emails getting lost in there.

some tips:

• 5% to 10% response rate is really good. It's a numbers game.
• When recruiting existing customers, play up the fact that you're the founder (or some important title that you've made up for this purpose) and are open to hearing feature suggestions.
• Keep it short, line breaks for scannability. Share why you want to talk to them and for how long.

Surveys

Short 1 or 2 questions surveys can be used as a springboard for follow-up questions and optionally to set up a call. When someone answers "what did you use before product X?" you can ask them something like "I'm curious to here what it is you're doing overall and how you found us"

---

How To Talk So People Will Talk

The most import part of the book. Goal is to create a "bubble of suspended judgment"

The Do's and Dont's:

1. Use a gentle tone of voice
2. Validate
3. Leave pauses for them to fill
4. Mirror and summarize their words
5. Don't interrupt
6. Use simple wording
7. Ask for clarification, even if you don't need it
8. Don't explain anything
9. Don't negate them in any way
10. Let them be the expert
11. Use their words and pronunciation
12. Ask about time and money already spent

[aside] wow, applying all of these I can imagine would be super powerful. I can think of many examples where I don't do some of these.

These techniques are so powerful that the author wants you to promise that you will use them for good and that you won't do bad things or be manipulative!

Just being a presence who is willing to listen is more powerful than people realize

Gentle tone of voice

Late-night DJ or a therapist tone of voice. But don't be condescending. Think of your customer as someone you respect and can learn from (because you should and you can).

Validate them

Use validating statement, even if you don't agree with what the person is saying or what they are saying is absurd to you.

Story about the "next-level conversational jujitsu":

Interviewee: "Sorry, I'm eating a quesadilla right now"
Interviewer: "oh you're fine" (but not "that's fine" or "no worries")

You also cannot agree with them or congratulate them or indicate that you have an opinion, even if it's a positive one. "I can see where you're coming from"= good. "Yes, I agree with you" = Not good.

Examples of validating statements (many more in the book):

• That makes sense.
• I can see why you'd do it that way.
• It sounds like you think that could be improved.
• It makes sense that you think that.
• Can you tell me more about X
• It sounds like there are several steps involved. I'm curious can you walk me through them?

Use 'think' instead of 'feel'

Free social tip for making small talk at cocktail parties - when someone tells you what they do for work, reply with "oh that sounds challenging"

Leave pauses for them to fill

Leave a pause that feels one or two beats longer than what feels normal. Like a long pause. The idea is that you want to elevate the customer's position in the interview, to be in the dominant one (remember they do 90% of talking, you do 10%). You want them to teach you about their view of their process.

Tip of logistics: During the long pause, and if you're on the phone, in case the customer asks "are you still there?" Here are the awesome phrases that put the focus back on them:

"Yes, I was just giving you a moment to think"

Or

"Oh, I was just jotting down what you said, that seemed important."

Mirror and Summarize their Words

Repeating words back to someone has the magical power of encouraging them to elaborate

[aside] Reminds me of a co-worker, Luke, who would often say "let me parrot that back to you" after we had a technical discussion about the details of a project to integrate two distinct applications. He was in charge one app and I was in charge of the other so it was important that we understood each other. And I liked it when he repeated back because it allowed me to see whether he 'gets it'. It's like when you order take out over the phone and the other person repeats your order back to you before hanging up.

Repeating or rephrasing the customer's words, I imagine, can also allow them to see that you "get it", that you understand. And if something you say is not accurate, give them an opportunity to clarify with "actually, that's not what I meant"?

Tip: important to use "it", rather than "I" when mirroring. "It sounds like..." better than "I am hearing that..."

Don't Interrupt

Yup. agree. Enough said :)

Here's an exercise suggested in the book: ask a friend "What are you really excited about lately?" and you're only allowed to say "mhmm", "can you say more?", or nothing. This will be more challenging than it sounds.

Use Simple Wording

For example: don't say SaaS, say Software until the customer indicates they're familar with the term by using it themselves.

SaaS vs. sass (as in syntactically awesome style sheets) - I never noticed until now that those two are homonyms and could be confused.

Ask for Clarification, Even When You Don't Need it

This one seems like some next-level conversational jujitsu :) The logic is that my restating the process and asking for clarification on some steps, you get the customer to elaborate and give you even more details.

This is not the same as "playing dumb" it's more about making the customer an authority/teacher of their experience.

Don't Explain Anything or Get Defensive

When someone questions something about how the product works or expresses some disconnect from their expectations, don't try to explain why you made it that way or your thinking and your perspective. Try to get to the bottom of the negative feedback by asking "I'm curious, can you walk me through what you expect to happen?"

Don't Negate Them, Build on What They Say

This is the improv comedy rule. You say "Yes, and". You don't ever say "No or but". Helps with not breaking the judgment-free bubble of trust.

Let Them be the Expert

I imagine this would be very difficult to not correct someone if they say something completely wrong. But the point is to understand how they came to think of it that way.

An example of something you should not correct in an interview:

You’re talking to a new user of your product—let’s say it’s a programming course. The price of your course is $299. But they say: “When I saw the price was $399, I was a little nervous, but I decided it was worth the investment.” Do you correct them? No.

[aside] One way to get a developer attention is to propose a wrong solution - a former engineering manager shared his trick and I watched it work on many (including me). He'd send a screenshot of a code diff he is planning to make on slack to solve some low priority bug that no one else has time for. And immediately he'll get someone saying "wait wait wait don't do it that way" and boom, now it's that person's problem.

It's hard for software developers to let some error in detail slide. Because, to be good at what they do, they have to be extremely detail oriented. They respect details and know that details matter (the devil is in them, etc.)

If your goal is to get someone to open up and share their experience, correcting them will be counter to that goal...to correct them on even the smallest thing would break the rapport you’ve worked so hard to build in the interview.

Use Their Word and Pronunciation

This makes sense. The point of the interview is not teaching them pronunciation. That would be a distraction and get in the way of hearing their unvarnished view!

Ask About Past or Current Behavior

We know asking things like "would you use this?" and "would you pay for this?" don't lead to useful answers (as with "do you like my idea?"). These ask people to predict the future.

Here are some more questions that are not good:

• How are you struggling?
• What are your pain point?
• What is confusing to you about [X]?

These may feel offensive to the customer. Here are better questions to find out about "struggle":

• How long does it take to do [X]?
• Compare to what you expected, how long did it take to integrate [X]?
• Thinking about the whole process, what takes the most time?

Instead of asking for predictions, ask and listen for facts, like time and money spent. Ask people what they have actually done in the past...Through their explanations, you will learn about where they struggle and where they’re willing to spend money.

Better questions than "what are your problems?":

• Can you tell me about the last time you did [X thing your product would be part of solving]?
• What tools do you use [for that purpose]?
• How much do you pay for [those tools]?

Be a Rubber Duck

The rubber duck on the cover of this book, while unexpected, was not much of mystery to me. I immediately thought "I bet this is borrowing from the concept of rubber ducking from programming" And yup, this sections confirms this.

---

The first 2 posts cover 1/2 of the book. Will be sharing notes for rest of the book over the coming weeks. Subscribe to the Indie Book Notes series, to get these straight to your inbox.