6. Whatever they say goes.
Don’t defend or explain.
Don’t negate them in any way.
7. Interviews
Learn about their pain points
in their overall process
Over the phone/in person
People to do this with:
- An existing customer
- A potential customer
- A former customer
Observe the person using your
product, looking at a landing
page, etc
Have the user share their screen
People to do this with:
- Existing customers
- Potential customers
Observation
9. 1. Take a look at this page and tell me what you’re
looking at. What do you think this product does?
10. 1. Take a look at this page and tell me what you’re
looking at. What do you think this product does?
2. Looking at the [button], what would you expect to
happen if you clicked it?
11. 1. Take a look at this page and tell me what you’re
looking at. What do you think this product does?
2. Looking at the [button], what would you expect to
happen if you clicked it?
3. Is that what you expected would happen?
12. 1. Take a look at this page and tell me what you’re
looking at. What do you think this product does?
2. Looking at the [button], what would you expect to
happen if you clicked it?
3. Is that what you expected would happen?4. What would your next step be?
How many of you have heard that you need to talk to you users? And how many of you feel like you talk to your users all...the...time? So many ways to talk to users and get feedback. Customer support (Intercom, Drift, etc), Github issues, Twitter, Phone, Sales, Email, etc. This talk is about how you talk to your users to get really helpful information that can help you grow your business so you know which features to add, what copy to write on your landing pages, and so forth.
What I’m going to talk about today applies whether you’re selling software as a service like me, or courses, or physical products. And it works with all ages and genders – whether they’re 25 or 85. I know this because I’ve done hundreds of user interviews. And it doesn’t even need to take long – only a few minutes if you know how to ask.
Let me tell you a quick story about that. A few months ago, I was at the grocery store. I noticed the cashier in front of me hug the woman in front of me when she left, and I asked if that was her sister. She said no, she was a longtime customer, she’d worked there for 25 years, and before I knew it she was telling me about the issues the union has with corporate and how they used to have pensions but now they don’t and they have 401ks and she contributes double to it… and before I knew it, without even meaning to -- mind you, this was only 2 or 3 minutes later -- I knew her full breakdown of her retirement income sources and how difficult it was for her to try to patch that together. I’ve never had a conversation with this woman in my life and yet I’d managed to learn this very private information.
Learning interview is powerful skill, and I’m here today to teach you how.
What that example about the woman at the grocery store shows is that when you’re interviewing someone -- whether it’s about their finances or the developer tools they use -- you want to find the pain. People are normally so private about their pain. We don’t want to show others when we’re struggling. And sometimes it’s on the surface, like if you’ve just bought something that you’re hoping is going to fix a problem, or if you’ve just cancelled because you realized it doesn’t fix the problem or you don’t have the problem anymore. But you can find it below the surface too. What I had to learn – and what I’m going to teach you today – is how to cut through that.
But first, how does pain help us make business decisions? There’s a framework from Des Traynor of Intercom that I reference all the time in my own work. And it’s called the “pain/frequency framework.” Basically the idea is that the more painful and frequent a problem it is, the more lucrative it is to solve. A high pain, high frequency problem -- which is where a lot of us doing SaaS fall, solving everyday, time consuming business problems -- falls. But there are good opportunities in high pain/low frequency; for example, buying a house. Most of us maybe buy one, maybe two houses in our entire lifetime. It’s complicated. As a result, the mortgage industry is a great place to be business-wise, very profitable. Similarly, low pain/high frequency: this is everyday stuff that’s just annoying and you want to go away, so you’ll pay for it to go away. But low pain/low frequency, these are the products we see and scratch our heads at.
Back to feedback and finding the pain. Something I’ve noticed is that there are a lot of blog posts talk about talking to users, they give questions you should ask or how frequently you should do interviews or things like that. But they’re all missing one key thing: getting useful feedback is all about how you act. It’s all about how you act when you are talking to that person.
The key to finding the pain is setting up an environment where your customers feel comfortable telling you things. You need to make them feel comfortable and open. They need to be vulnerable. You need to be blank and completely absorb what they are saying to build a map of how their world works. They are not going to be open with you if they think you’re judging them. You need to be a blank slate that is ready to absorb how they look at things.
And when you’re getting feedback, you are not your normal personality. When you are interviewing someone, you could say it’s a form of acting.
I was talking about this with someone the other day, and they said it’s like improv. In improv, the other person on the stage always has to react in a way that says “yes and” to whatever the other person has said or done, builds on it, goes with it, no matter how crazy it is. They never say no and try to turn it around. It’s like dancing; if you try to go the opposite direction as the other person, you’ll step on each other and end up in a big mess on the floor.
Following that -- the idea that interviewing is more like improv and less like a conversation -- whatever they say goes.
They say your product name wrong? Don’t correct them.
They describe a complicated way of doing things? Don’t suggest a better way.
They say your product doesn’t work correctly? Don’t explain to them why you built it that way. Ask them about their process. This likely means your product doesn’t match their process in some way, and this is helpful information.
DON’T say you’re working on it/it was designed that way/they’re doing it wrong.
Your users are never doing something wrong; your product exists to help them do it better. If it isn’t, it is your product that needs to change to suit the user.
They have a feature request, and it sounds awful to you? Say “Thanks, I’m writing that down and we’ll look into it.”
If you correct them even in a small way, they will be less open with you. And the feedback you’ll get won’t be as useful.
Two primary ways of talking to people, and where I use them
Interviews
What are they trying to accomplish overall, where does the problem your product solves fit in their process? What other steps are there?
Where do they spend a lot of time? What are they doing manually?
What did they use before? Why did they switch?
Remember earlier Jason Fried was talking about how we all have everyday processes that are hacky, that are annoying, but we accept them anyway. This is exactly what you want to find when you’re interviewing someone. Where are those inefficiencies?
Observations: usability testing on your product. See why people aren’t checking out, see if they’re absorbing the information you hope they are when they see your product (do they notice the menu items, etc) seeing why a landing page is -- or isn’t -- converting. It’s also great for testing prototypes BEFORE you build features.
Example of doing a test on a landing page, done via screenshare. One we’re doing right now. How do they perceive this product and what it can do? Do their hopes match what it actually does, or what you thought it should do?
Observations: usability testing on your product. See why people aren’t checking out, see if they’re absorbing the information you hope they are when they see your product (do they notice the menu items, etc) seeing why a landing page is -- or isn’t -- converting. It’s also great for testing prototypes BEFORE you build features.
Example of doing a test on a landing page, done via screenshare. One we’re doing right now. How do they perceive this product and what it can do? Do their hopes match what it actually does, or what you thought it should do?
Observations: usability testing on your product. See why people aren’t checking out, see if they’re absorbing the information you hope they are when they see your product (do they notice the menu items, etc) seeing why a landing page is -- or isn’t -- converting. It’s also great for testing prototypes BEFORE you build features.
Example of doing a test on a landing page, done via screenshare. One we’re doing right now. How do they perceive this product and what it can do? Do their hopes match what it actually does, or what you thought it should do?
Observations: usability testing on your product. See why people aren’t checking out, see if they’re absorbing the information you hope they are when they see your product (do they notice the menu items, etc) seeing why a landing page is -- or isn’t -- converting. It’s also great for testing prototypes BEFORE you build features.
Example of doing a test on a landing page, done via screenshare. One we’re doing right now. How do they perceive this product and what it can do? Do their hopes match what it actually does, or what you thought it should do?
In closing, one thing I want to mention is that when someone gives you feedback, make sure to follow up with them. Send them a thank you email, and for bonus points, ask for their address and send them a thank-you note with stickers. It may sound old fashioned but it really goes a long way for people.
If you have any questions about any of this, happy to chat later!