104 – Surfacing the Unarticulated Needs of Users and Stakeholders through Effective Listening

Experiencing Data with Brian O'Neill (Designing for Analytics)
Experiencing Data with Brian T. O'Neill
104 - Surfacing the Unarticulated Needs of Users and Stakeholders through Effective Listening

Today I’m chatting with Indi Young, independent qualitative data scientist
and author of
Time to Listen. Indi explains how it is possible to gather and analyze qualitative data in a way that is meaningful to the desired future state of your users, and that learning how to listen and not just interview users is much like learning to ride a bicycle. Listen (!) to find out why pushing back is a necessary part of the design research process, how to build an internal sensor that allows you to truly uncover the nuggets of information that are critical to your projects, and the importance of understanding thought processes to prevent harmful outcomes. 

Highlights/ Skip to:

  • Indi introduces her perspective on analyzing qualitative data sets (00:51)
  • Indi’s motivation for working in design research and the importance of being able to capture and understand patterns to prevent harmful outcomes (05:09)
  • The process Indi goes through for problem framing and understanding a user’s desired future state (11:11)
  • Indi explains how to listen effectively in order to understand the thinking style of potential end users (15:42)
  • Why Indi feels pushing back on problems within projects is a vital part of taking responsibility and her recommendations for doing so effectively (21:45)
  • The importance Indi sees in building up a sensor in order to be able to detect nuggets clients give you for their upcoming projects (28:25)
  • The difference in techniques Indi observes between an interview, a listening session, and a survey (33:13)
  • Indi describes her published books and reveals which one she’d recommend listeners start with (37:34)

Quotes from Today’s Episode

  • “A lot of qualitative data is not trusted, mainly because the people who are doing the not trusting have encountered bad qualitative data.” Indi Young (03:23)
  • “When you’re learning to ride a bike, when you’re learning to decide what knowledge is needed, you’re probably going to burn through a bunch of money-making knowledge that never gets used. So, that’s when you start to learn, ‘I need to frame this better, and to frame it, I can’t do it by myself.’” – Indi Young (11:57)
  • “What you want to do is get beyond the exterior and get to the interior, which is where somebody tells you what actually went through their mind when they did that thing in the past, not what’s going through their mind right now. And it’s that’s a very important distinction.” – Indi Young (20:28)
  • “Re: dealing with stakeholders: You’re not doing your job if you don’t push back. You built up a lot of experience, you got hired, they hired you and your thinking and your experience, and if what went through your mind is, like, ‘This is wrong,’ but you don’t act on it, then they should not pay you a salary.” – Indi Young (22:45)
  • “I’ve seen a lot of people leave their perfectly promising career because it was too hard to get to the point of accepting that you have to network, that I’m not going to be that one-in-a-million person who’s the brilliant person with a brilliant idea and get my just rewards that way.” – Indi Young (25:13)
  • “What’s really interesting about a listening session is that it doesn’t—aside from building this sensor and learning what the techniques are for helping a person get to their interior cognition rather than that exterior … to get past that into the inner thinking, the emotional reactions, and the guiding principles, aside from the sensor and those techniques, there’s not much to it.” – Indi Young (32:45)
  • “And once you start building that [sensor], and this idea of just having one generative question about the purpose—because the whole thing is framed by the purpose—there you go. Get started. You have to practice. So, it’s like riding a bike. Go for it. You won’t have those sensors at first, but you’ll start to learn how to build them.” – Indi Young (36:41)

Links Referenced:


Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Indy Young in the line. How are you, Indi?

Indi: I’m good, how are you?

Brian: I’m doing great. And you are going to shed some light here, open up the whole world of research, doing user research, which is how I have you positioned in my head. My old coach calls this a Rolodex moment. And when I think of UX research, you have kind of parked next to those words in my head. I know you’ve been in this space for a long time and you’ve written several books on this, and I’m going to ask you about those a little bit later.

Why I wanted to have you on the show here to talk to primarily this data product audience, the data science leadership and analytics leadership community—and there’s product people here is—that I think part of my mission is to drive design practice into this world where there’s not a lot of user experience, design, or product management, or user research happening, and what’s happening is a lot of the work doesn’t get used, it doesn’t get trusted. And this becomes more and more important as we use more advanced technologies such as machine learning and AI. And so, I wanted to bring you in to kind of talk about how do non-user experience professionals do this work. Can they do it work, can they take imperfect action to get going with it, if it’s a, you know, maybe hiring professionals is not in the cards yet or they don’t have a budget for that, but they are feeling the pain of what happens when we ship stuff that hasn’t been designed well. And so, that’s kind of the premise of why I wanted you to come on today.

So, I remember, like, when we first met, you said, “I am a data scientist. I just work with qualitative data instead of quant data.” And I love that. And you also mentioned that people aren’t taught how to deal with empirical qualitative data. So, my audience is obviously really comfortable with large data sets, especially on the quantitative side.

Where a lot of the struggle sometimes is in figuring out what’s actually needed and getting beyond surface-level asks and feature asks, and things like I need a dashboard that uses NLP to do something that might help them. And the tendency is to run in, try to deliver exactly what is on the surface without actually getting into the weeds there. So, what does an audience that really does understand the quant side of this, what do they need to know about qualitative research and dealing with empirical qualitative data? What’s a message that you want to send to them?

Indi: [laugh]. It is doable. There—

Brian: Yeah.

Indi: —that’s the message [laugh]. The rest of it is so deep and complex, but that’s mainly because we are humans and we’re deep and complex. And part of what I have managed to do is scale up a way of finding patterns that is reliable, that we can get from qualitative data. A lot of qualitative data is not trusted, mainly because the people who are doing the not trusting have encountered bad qualitative data, data that’s just, like, an anecdotal story or, you know, we heard it from one guy and so we’re going to build this whole thing and then it flops. And I’ve wasted all this time and then I lose my job over it. And I’m never going to do qualitative data again because it’s ridiculous. So, I mean, maybe it’s not always that bad [laugh] but that’s the idea.

And mainly is because people are still in the mindset of encoding processes. So, when we started with software—what was it, way back in the ’30s, right—we were encoding processes, we were encoding calculations. As we got more sophisticated, we were encoding the process for landing a lunar module on the moon, or whatever else. We were encoding the process of playing chess, we were encoding the process of pretending to be another person and trying to trick somebody on stage.

We were also encoding the process of compiling code, encoding the process of debugging it, we were encoding all these things that people did and we started reaching out and encoding other things that people who weren’t engineers and scientists try to do. So accounting, so writing, you know, the easy ones came next. Now, we’ve got medical apps that people on the street can use to track certain things and get a better handle on how well they’re treating their body or their condition or whatever. And so, as we’ve moved, we’ve carried with us this idea that, hey, there’s a process for it and we’re going to encode it. And that is a fallacy, and we all know this in our hearts.

So, we got into this field because there was a moment somewhere where we’re, like, “Oh, man, I could help that person. I could make that solution better.” And so, that’s the spark. And we get into the world of whatever we’re doing, right, and it feels as if we’re moving away from that spark. We don’t have the budget, we don’t have the time, we don’t have the team, and so maybe we worship or keep that flame alive by using big data.

We want our organizations to be data-driven, so we’re going to use big data and that is coming from the groups of people. So, that means it predicts big groups of people’s behavior. That’s not design research. Design research is understanding different people’s approaches, the variety of those approaches, and trying to design something that’s not going to harm them.

And the harms can be mild. The harms can: cause them frustration, cause them confusion, right, or the harms can be serious: cause them to feel unwelcome, cause them to feel self-doubt, interrupt them, trigger them, all of this kind of stuff. And it goes—I’ve got this chart with two more layers of different kinds of harm above that: lasting harm and systemic harm. But those layers of harm are not things that we’re used to addressing. And those layers of harm are happening, say, within a group of employees that, let’s take an insurance company and their HR department is trying to understand, you know, why are our employees leaving?

We don’t want them to leave. We just spent a lot to try to get them here and they’re leaving. And so typically, what happens is that some executives get together and they set up a little process to try to keep people from leaving based on their own experience. On the alternative side, is you could go and listen to a whole bunch of those employees and understand what’s going through their mind as they lead up to a decision to leave. What went through your mind there?

We can speak to employees who left, we can speak to employees who are still there, of what’s going through your mind. And it turns out, there’s, like, one study that I did, there were five different thinking styles. The typical approach to supporting, to try keep your employees only address, like, half of one of the thinking styles. So, that’s why you still are hemorrhaging your employees, is that you haven’t done any of the understanding, the deep understanding. And those thinking styles, they come from listening sessions and interior cognition.

And they come from a way of framing a study so that we guarantee that patterns come out of it. So, with quant we’re measuring scale or amount, that kind of thing. With qual, we’re measuring patterns and regularities. And if we don’t get patterns out of it, we don’t have valid data. We’ve got subjective data, we’ve got anecdotes, one-offs, right? We know where those go [laugh]. What we need is the patterns. So, I do two things: I frame it so that I’m pretty sure will patterns have come out, and then I shift the frame if the patterns aren’t showing up. And I re-recruit.

Brian: I’m glad you brought up the HR example because it suggests that what you’re talking about is not just for, say, tech companies that have in-the-millions-type sized audiences where you can’t—maybe you can’t interview 100,000 people, so you have to do a smaller set of those in order to draw some kind of generalizations there. So, it sounds like you think this is relevant when the audience for your product—and I’m going to use the word product in this episode and that can mean an internal decision support application, like maybe it’s a tool for the HR team that predicts which employees look like they might churn, such that we can have an intervention prior to that instead of waiting until they’re out the door; so just theoretically, let’s say that’s it—that might be 100 HR staff that might use that or 50 HR staff or something like that. That could be the world of the quote, “Users,” of the solution. Are these techniques important to know about? Is it important to know about these thinking styles?

If my world is really trying to satisfy these 50 HR reps—and I understand, you know, from the user standpoint here might be the employees is really—those are the quote, “Users,” or their stakeholders in the system, but the solution that I’m quote, “Building,” is for the HR staff. When I’m talking to the HR staff because they’re the ones are going to use this dashboard and this tool, is it important to know about these thinking styles and all of that? And if I don’t know about these thinking styles, like, how much do I have to worry about, quote, “Doing it wrong,” doing the research the wrong way, versus making—this idea of imperfect action which is, you want to learn how to ride a bike, don’t read a book is so one of my favorite [laugh] Seth Goden quotes. You have to get started by learning by doing. How much do we need to know about this to get going? And how do we begin to be aware of these thinking styles?

Indi: So, there’s two wildly different questions there. The first one is, why is it important to those 50 or 100 or 150 HR staff, right, to know, thinking styles? And thinking styles is just one part of what I do. There’s two parts of it. The other part is the various cognitive and emotional approaches to the purpose. So, it’s broken up by the way that a person approaches their purpose and then layered with thinking styles on it. But let’s just to answer that one thing. Why would they care about thinking styles?

Brian: I’m not asking or suggesting it’s not important to know the employees’ thinking style. I’m asking about the thinking styles of the actual HR people because those are my quote, “Users,” of my, let’s say, where—again, this is a fictitious scenario, hypothetical scenario that I’m a data scientist; we have 200,000 employees. We think we can predict employee churn based on something and so I’m building this for the HR team so they can get ahead of it.

Indi: Yeah. This gets to the idea of what knowledge do you need when? So, when we’re doing research, all we’re doing is building knowledge to help smooth something out that the org is doing. There’s different tools that you use to build different knowledge, I think we all can agree on that. There’s this idea of ‘thick data’ that Tricia Wang came up with, which is mixed methods trying to layer data together.

And that’s something that I do, is trying to, for example, layer, not only thinking styles on top of these approaches, but also some of the other big data that we have on top of those approaches so we can see more broadly. But the whole idea is, like, why are we making this knowledge? Where does that come from? Who makes that decision? And how good is that decision?

So, this is the place where you actually have to be careful. When you’re learning to ride a bike, when you’re learning to decide what knowledge is needed, you’re probably going to burn through a bunch of money-making knowledge that never gets used. So, that’s when you start to learn, I need to frame this better, and to frame it, I can’t do it by myself. I need to understand where my stakeholders are coming from, which is specifically to have relationships with them to have, even more specifically, listening sessions with them so that you can understand their interior cognition, their inner thinking, their emotional reactions, their guiding principles around this purpose. So, every time I ever go do a listening session, it starts with a germinal question.

And a germinal question comes directly from the purpose that we’re trying to understand. The purpose is defined as a person’s goal, so to speak, but there’s a lot of different layers. Goldilocks layers. You can have narrow purposes, you can have really broad ones. Really broad ones are harder because it takes a lot more money and a lot more time to get patterns to show up.

So, maybe it’s a broad purpose, but you frame the who you’re gathering the data from, the people you’re recruiting, a lot narrower. So, there’s all these little dials that we can shift and change to meet the knowledge that we need or that those stakeholders need because we don’t know what they need, and we need to know what they need and help them explore it. So, all of the work that I have done starts with two, three, four, sometimes eight weeks of discussions with the people who have asked me for this information, for this knowledge. It’s really a discussion going back and forth about well, what are you trying to get done? What’s around that? What’s behind that? Why did you make those decisions? Was it something that you did another company that you want to replicate here? Why do you think it’s going to work?

I want to understand your inner thinking around it. And I not only want to understand your inner thinking about it, but I want to understand the stakeholders that are also working with you who are asking for this knowledge. So, many times, I’d say at least a third of the times, people have asked me for some knowledge and I convinced them that’s not the knowledge that they need after doing all this listening to them. It’s like, “You’re really not after that,” or, “You’re not in a place to need this right now.” The knowledge you think you need is not going to be generated by the Indi Young approach of doing listening sessions and data synthesis to create patterns and empirical qualitative data. So, that is what happens up front and that is really important. You will get burned until you realize how important it is, or until you decide this is just not the career for you [laugh]. All right?

Brian: I agree. And we talk about that a lot on the show here, and I think you’re talking about what I might call problem framing or understanding desired future state. Where are we now, where are we trying to go, and how would we know if we got there, and getting a clearer picture of that? Which is not usually embedded in an ask that includes a solution inside of it. You know [laugh]?

Indi: Exactly. Well, so many times, stakeholders feel like they know what they’re doing, and so they say, “This is the solution we want.” And that’s where—in the beginning, I was very shy. Once I graduated college, for some reason, all that, I shed. Because people would come to me with these asks, and I’m like, “Well, wait. Why?” I’m very good at asking, “Well, wait. Why?”

Brian: I like to try to use instances to explain abstractions just so people can take it out of the clouds and bring it down. Can you give me an example of you know, you’re working with a team of non-user experienced professionals on how to do this work? I run a data science team; we’re asked to solve these complex problems for stakeholders. The stakeholders don’t frame problems well, they don’t really know what they want, except it has to have AI in it, of course, because that’s cool. So—

Indi: [laugh]. And a chatbot [laugh].

Brian: Yeah, or whatever. And this team rolls the eye—like, my listeners are rolling their eyes and laughing because they know this, and so they want to get behind what the desired outcome is. They know that much. Can you give me an example of where a team might—they might have not gone into the why part enough and it had something to do with not understanding the thinking style? And maybe we can use this HR example where the data science team is building some kind of predictive model for the HR team to use to prevent employee churn.

We want to keep our best talent, we’re losing A players from the organization. Let’s say it’s a giant bank or something, right? How do we keep those people? And that’s ultimately the goal is let’s not lose our best talent. And we think some of that is going to come from stuff we can track with computers, with data that we can track. Some of it, obviously, is not you’re going to have to go out and interview employees.

But the data team doesn’t know exactly what the head of HR wants and all of that. What I’m trying to get from you is that how might we misinterpret the thinking style of say, the head of HR? Show me where the thinking style thing would come into play that we could misunderstand that, or misread an ask or something like that. I’m trying to give an instance, an example of this.

Indi: Yeah, I can give an example, but the way you’re using thinking style there is not the way I was using it.

Brian: Okay.

Indi: We’ll get into that second. The first, though, is the answer to that question, which is, this is all about recognizing in yourself, your eyes are rolling, this is not the right solution, and even though there might be a lot of power hierarchy and distance between you and this other person who’s asking, if you go ahead and just do what they say, you’re messing things up for them. They want you to push back if there’s a reason to push back. If there’s somebody—and a lot of people have told me these stories, like, you tried to push back and the person is all just, like, stubborn, and I refuse to listen to you. And that’s the situation that the person is just really into themselves and doesn’t want anybody else’s [laugh] input. There’s nothing I can do about that, right? There’s nothing you can do about that.

You can decide whether you want to stay at that company or not. You can decide whether there’s a way to go over that person’s head or not. But the whole point is that we are all humans and we’re in teams, and teams communicate and they collaborate, and teams build relationships between each other. We’re very human; this is what we do. Even if we are introverts, even if we’re shy, we’re still doing it.

There is a native part of you that—[laugh] as much as I want to say, “Yeah, I’m not social,” [laugh] I am actually at my core. And so, for me, actually, it takes a little push. I’m not naturally going to just, you know, reach out somebody say, “Hey, can we have a chat?” But when I get in these situations, it’s like, oh, I’m not going to sit here and just roll my eyes and do what they say. I’m going to reach out and say, “Hey, listen, can we have a chat?”

And in this chat, I’m not telling them anything. I’m going to say, “Hey, listen. What I want to do is talk just about this one thing that you’re trying to accomplish and get my head around it and see where you’re coming from.” I just published a book called Time to Listen and I also have a course that runs alongside that to help teach people how to listen.

So frequently, we don’t listen. We go in there with our own upsetness, we go in there with our own idea of what should be done, and we fail to hear what the other person has to say. When we’re working with other teams, we say commands back and forth to each other. To me, I like to use this analogy of, like, throwing spears at each other. And we’re not listening to each other.

Now, listening has layers. And you might say, “Oh, I can listen.” I want them to explain how it’s supposed to work. That’s an exterior layer. “I’m going to listen to them tell me how many there should be or how fast it should be.” That’s an exterior thing. That’s called a statement of fact.

There’s another thing at the exterior, which is called scene-setting. A layer inside that is when people start telling you their preferences. “Well, I want it to be this way. I like it that way,” or their opinions, “Well, this doesn’t work because such and such and such and such.” That’s exterior. None of that is going to help you. You’re still at the throwing spears at each other layer [laugh] level, right?

What you want to do is get beyond the exterior and get to the interior, which is where somebody tells you what actually went through their mind when they did that thing in the past, not what’s going through their mind right now. And it’s that’s a very important distinction. If you ask somebody to tell you what went through their mind right now they’re going to make it up. You want what went through their mind as they were deciding that they needed this dashboard. How did that come out?

Probably took a couple of weeks, maybe some discussions. Was there something on Slack? What went through your mind? “Oh, what was that part you say about when you did this at that other company that you were at before here? What went on there?” “Oh, that came from another company before that? What went on there?”

And all of it, not getting what went on, like, explaining what happened, but what went through your mind. What was your inner thinking, that little voice inside your head? What were the emotional reactions that you had things that drove your thinking or that drove other emotional reactions? What were the guiding principles or personal rules that you used to decide between things or to take action? Those are the three things. Yeah.

Brian: I mean, I almost wonder if I should roleplay being a difficult stakeholder and play this out with you because I want to give people an idea of how you handle that. How do you navigate that, then when it’s, “Yes, we need this thing. I can give you 30 minutes in two weeks from now.” You have this vague ask for some, like, giant piece of technology, they have no idea what’s going into it, and they’re quote, “Not going to give you the time,” and all this kind of stuff. Are there ways to open up the doors to even get to the point where you can have a second conversation because you asked really great questions in that little 30-minute window that they said they—

Indi: Yeah.

Brian: Had time for?

Indi: That’s part of it.

Brian: How do you get that access and start increasing that access and not make it feel threatening? I know that some of the analytics community tends to be a little more introverted. My students are not comfortable pushing back sometimes, even though their management wants them to do this. They feel like it’s a threat. Like if I’m asking why, I’m challenging the authority—

Indi: Ah, right. Yeah.

Brian: And I’m not doing them service. And I’m like, no, you’re doing it in service to them—

Indi: You are doing it in service, yeah—

Brian: Right. So—

Indi: —you’ll mess them up if you don’t do it.

Brian: Right. They’re going to pay for it literally or some [laugh]—

Indi: Yeah [laugh]. Exactly.

Brian: Other way anyway. So, like [laugh]—

Indi: Here’s another way of saying that is that you are not being responsible. You’re not doing your job if you don’t push back. You built up a lot of experience, you got hired, they hired you and your thinking and your experience, and if what went through your mind is, like, “This is wrong,” but you don’t act on it, then they should not pay you a salary.

Brian: So, it sounds like you’re saying, “Step up.”

Indi: Yeah. It’s your responsibility. It is your responsibility. Now—now—there are lots of ways to step up [laugh]. Because we’re all human and I’m as scared of those stakeholders as you are.

So, part of it, one way to do it, is to do it without a particular project in mind. Say, “Hey, I’d like to get to know you a little bit better, I’d like to get to understand your thinking a little bit better. Over time, let’s just have lunch together once a month.” That is the old way of doing it where—you know, you’ve ever heard that phrase ‘office politics?’ Office politics is about getting influence and power.

And the only way to get influence and power is to build a network and relationships. Show people that you are there and can take on something, can be responsible, can do the things that you’re being paid to do. There’s another way of doing it, to be that superstar and, like, “Oh, my God, he made this amazing thing and now we all use it and it runs the world,” and now you’re a superstar. And that happens to you, like, one in a million people. You are probably not that person [laugh].

Brian: I’m definitely not, by the way.

Indi: I’m not, yeah.

Brian: [laugh].

Indi: I’m not [laugh]. But the idea is that if you have to fall back on the old-fashioned way, which is doing these networks, don’t do them when you have to, when you’re, like, rolling your eyes and you’re upset because they did a stupid thing. Don’t start there; start now. Start now.

I mean, the old way of doing it was to have lunch together because everybody has to eat. Well, now if we’re all on Zoom, who’s going to eat on Zoom together? So, you could go on a hike together or walk together, you know, walk downtown, or maybe you are going into the office every once in a while and when you’re in the office, a lot of executives are saying hey, we’re not in the office to go and sit down in front of our screen; we do that at home. In the office, we’re there to build our relationships, to talk to people, to not sit there with your arms crossed, say your ideas are stupid because I got better ideas but I’m not telling you. I’ve seen a lot of people leave their perfectly promising career because it was too hard to get to the point of accepting that you have to network, that I’m not going to be that one-in-a-million person who’s the brilliant person with a brilliant idea and get my just rewards that way.

So, the nice thing, though, is that lunch is fine. We all got to eat, and it’s fine. And we can just sit there and chat. And what happens is that you don’t have to say anything about yourself. You say, “For this lunch, I really want to understand your thinking around, I don’t know, some old project that you worked on or that you know about. I want to know your thinking about why you chose this job”—maybe it’s a new person—“Why did you decide to come work with us, right? What was your thinking there? What went through your mind when you saw, you know, the ad for it and when you went through these interviews.”

I don’t know something that is not fraught. Maybe somebody higher up would not want you to ask them why you decided to join this company, [laugh] but you’d be surprised we’re all human. When we do this kind of listening, the other person feels heard. And feeling heard is such a rare thing.

I just did a demo of this for a group yesterday, and the demos are alway—they’re never preset, right? So, as the person who didn’t know he was going to be part of a listening session—and also listening sessions are one-on-one. This is super important. You don’t do a listening session in a group because the person will feel too vulnerable. However, in this example yesterday, he went ahead, he’s like, “I’m fine doing it in the group because it was demo for learning how to listen.”

And at first, he was talking about generalizations. Like, I always do this, this always works this way. And doing explanations: “Here is how it works,” doing opinions: “I don’t like how it works.” And I kept at it using the techniques that are used for deep listening, micro-reflection, reflection, asking about the root, where did that come from, I got him to start speaking about some things that he has developed when he actually doesn’t feel heard [laugh] in his work, we got to his inner thinking, we got to lots of guiding principles. He was talking about wanting to recognize the other person and meet them at their level. Where did that come from? There’s a lot of stuff behind that, that he came to that point where he wants to do that.

So, this is what we’re after. If we do this kind of relationship-building with our stakeholders, and then a project comes along, and you say, “Hey, I just want to get inside your head about this particular project,” they will be ready to do it. They will recognize the way that you’re asking about it.

Brian: Indi is talking a lot about listening sessions, and you have a bug about the word interviews. And I want to say, effectively, we’re talking sort of about the same activity here; there’s a different label. And I actually really like this framing, it’s a very different framing.

Indi: It is a different activity.

Brian: So, I wanted you to talk about that, but before you go into that, do you know when you hit, what I call the nugget, and like, you know the term laddering, I’m sure, with ‘whys’ or using the ‘so what?’ Framework. I generally tell my students, you’ll probably know when you hit the nugget because you’re going to hear something new that you’ve never heard before, and then you can start reeling that fishing line back in and you can bring the fence inwards a little bit and get more deep on that. Do you think that person that’s new to this technique will know when they get to that point, past the surface, past the generalizations, they’ll know it?

Indi: Not at first.

Brian: Not at first? Okay.

Indi: No. So, listening deeply is not an interview. Listening deeply is about, over time, building a sensor for yourself. And what you’re doing as a host is a form of listening but not listening deeply. Because you’ve got ulterior motives [laugh] and you’ve got an audience. It’s different.

What you want to do is build a sensor, and that sensor tells you whether the person is speaking at exterior level or speaking at interior level. Once you have that sensor built, then you’ll know when the nugget comes. All the time that you don’t have that sensor built, you will not know, you will not recognize it, and you will not get to that point where the person who’s doing the speaking—or the texting, or however you’re communicating—actually starts to flow, decides, “Okay, for this little bit, I’m going to trust you and I’m going to tell you all this stuff.” And that’s when it becomes fun for them. That’s when they start feeling heard.

The sensor is also going to recognize how safe that person feels. You’ve got to build a sensor that keeps their comfort in mind, make sure you’re not triggering them, make sure they’re not withdrawing or we haven’t gone too close to the vulnerability edge. That sensor is also going to notice whether they’re speaking about a memory or whether they’re back here in session mode with you. You don’t want to be in session mode very much. I mean, you have to be for logistics purposes, but you’re going to get your interior cognition from memory mode.

And there’s another thing that your sensor is going to notice, which is topic shifts. So, a person is going to go through a lot of topics, and one of the huge differences between an interview and a listening session is that an interview has a list of questions, and a listening session only has the germinal question, which is based on the purpose as its root. So, I don’t bring up topics. The topics that come up are the topics the person brings up. So, that makes it something that’s really accessible to a lot of us, especially a lot of us who are quite introverted, or like, “Ah, I’m not so sure, you know? There’s too much of a power gap between me and this other person.”

It’s a tool that allows us to actually bridge that gap because we know what we’re looking for, we’re sensing these things, that sensor is there so that we can pay rapt attention. We might have to jot a couple—like, one or two things down, like you were just saying, “Oh, there was so many things you talked about I want to get back to,” but we’re recording, often—when I’m doing it formally, I’m recording. When I’m doing it informally with a stakeholder, I’m not recording but whatever comes up and whatever I remember to get back to is whatever I remember to get back to. That’s okay. Have you ever been to a wedding where you got seated next to somebody you didn’t know?

Brian: Probably.

Indi: [laugh].

Brian: I don’t remember [laugh].

Indi: [laugh]. Okay, or any—

Brian: The only wedding I go to now, I’m usually playing at them. So, I’m sitting—

Indi: Oh, okay.

Brian: Next to my bandmates [laugh].

Indi: [laugh]. Man.

Brian: Sometimes I haven’t had to draw—you know, like, oh, the bass player; when did you get—how long have you guys been playing together? Um, 15 minutes.

Indi: Right, right. Yeah [laugh]. Right?

Brian: That’s a good jazz joke [laugh].

Indi: Yeah, yeah, exactly. My partner’s dad is a jazz musician, as well.

Brian: Yeah [laugh].

Indi: But the idea is, like, you’re sitting next to somebody that you don’t know, and you chat. And sometimes it’s awkward chat and sometimes you find some sort of subject where it flows a little bit better. And then you’re done with that and then you’re like, mmm, oh, they said something else, and you might go back to something that was brought up. And you know, it goes. It goes wherever the heck it goes. It doesn’t matter. And that’s pretty much the same for a listening session.

Now, we have a purpose that we framed it by the person’s purpose. And we want to understand their thinking as they address that purpose in the past. But they’re probably going to take it off in other directions that we didn’t really think about. And that’s fine. And we go there, and actually half the time, a direction they took it in is actually really key to them and we didn’t even realize it [laugh] and it’s part of the purpose.

So, it’s what’s really interesting about a listening session is that it doesn’t—aside from building this sensor and learning what the techniques are for helping a person get to their interior cognition rather than that exterior, and, you know, explanations and preferences and opinions, to get past that into the inner thinking, the emotional reactions, and the guiding principles, aside from the sensor and those techniques, there’s not much to it.

Brian: You might disagree with this. One of the ways, when I’m teaching my students in the data field to get started with doing this kind of interviews, is yes, we’re going to come up with a quote script of questions. The point of the script is not to get every—it’s not a survey. It’s just there to get the conversation started. And actually, part of the goal is to let the conversation tangent because in the tangents is when we find out we didn’t even know what questions to ask.

The only purpose of the script then is just to reel it back in when you’re dead. If you hit a dead wall, then go on to the next one and then open that up again. Let it drift and you probably will find out you’re going to easily fill the time [laugh] with stuff, and you’re going to find out the things you never knew to ask about, which so many times for me doing product design research is that’s the best stuff you get is the questions you didn’t know to ask about. That’s the more interesting stuff. It’s not the, “How did you do it last time?” Or, “Show me your workflow for whatever,” that’s not the juiciest information you get back. Any comments on that? Do you think that’s too steered as well?

Indi: N—I actually started doing that three decades ago, I was doing that as well. And I would use that to sort of fill in dead space. You’re exactly right. The idea is not to go through a list of questions because that would just be doing a survey—

Brian: A survey [laugh]—

Indi: Spoken aloud [laugh]. Why would you pay for that [laugh]?

Brian: The only worst kind of survey possible [laugh].

Indi: Exactly. I don’t know. Well, actually, to Indi, the only good survey is an essay question [laugh].

Brian: [crosstalk 00:34:46]—

Indi: I’m very opinionated about surveys. I made somebody cry with my opinions about surveys [laugh].

Brian: Wow.

Indi: So anyway, I will try not to [crosstalk 00:34:53]—

Brian: Don’t you have a book about empathy, and you’re making people cry [laugh]?

Indi: [laugh]. I know, right [laugh]?

Brian: Practical Crying.

Indi: Yes [laugh]. But yes. So, that’s where I started. And what I did was I let go of having something to go to in the dead space because if there’s dead space, maybe the session is over, okay, and you got to leave it. One of the really important things is that there is no time. You might tell the person, “Hey, we’ll take an hour,” but if you’re done before an hour, you’re done before an hour. Don’t force them. Don’t torture them, right?

If you go over an hour—I’ve had a lot of people, like, they’ll say, “I’ve got a hard stop at three o’clock.” Three o’clock rolls around. I never mention time, but if there’s a hard stop that they mentioned, I’m like, “Oops, we’re at the hard stop.” They’re like, “Okay, well wait. That can wait just a minute while I finish telling you my inner thinking about this thing,” right? And it goes on for another ten minutes.

Because we’ve reached that point where we’ve got rapport, where the person is trusting me to hear them, to let them pick the topics, and what happens is when there is a topic that is finished, there’s the dead space and then I let the dead space double, and usually, the person will jump back to a different topic. If they don’t, then I might jump back to a different topic that they said earlier, and I will say—I want them to own the space. So, I never say, “Okay, well, let me switch gears and ask you about—” it's, “Earlier you said…” and that keeps them in control of the conversation. I mean, there’s a lot of nuance to learn about it, but the key—I mean, to get started is to just start building that sensor about exterior versus interior. And if you can, about memory mode versus session mode and about safety.

And once you start building that, and this idea of just having one generative question about the purpose—because the whole thing is framed by the purpose—there you go. Get started. You have to practice. So, it’s like riding a bike. Go for it. You won’t have those sensors at first, but you’ll start to learn how to build them.

Brian: That’s great. I love that summary. And that is something so hard to do is not jumping into that silence too early. It’s so hard. Like for me, it’s not—

Indi: [laugh] I know, right?

Brian: —because I like to talk to people; it’s so hard not to jump in too soon. I’m like, give it ten seconds. And it’s going to feel like a minute. It’s, like, so awkward.

Indi: Yeah.

Brian: But you got to kind of sit on that and sometimes a real revelation comes at the end of that silence, especially when someone’s like, “Let me think about that for a second,” and it feels like a minute [laugh].

Indi: Right. Right.

Brian: It’s so easy to—

Indi: Yeah.

Brian: Yeah, not jumping in there is important.

Indi: In a formal listening session, definitely. Yeah.

Brian: And you literally wrote a book on this, among other books. Can you rattle off your book titles, but jump into this latest one Time to Listen, and I want you to actually, if you could recommend for this audience, if they had time to read one and jump in on one, should they start with the latest?

Indi: Yes. Start with the latest. They’re all—they’re an evolution, each one is an evolution of the other. So, the first one I wrote in 2008 and it’s called Mental Models with some subtitle. For some reason, my brain cannot remember subtitles, it has some subtitle [laugh].

But that’s all about the other end, so after I gather this data through listening, I do data synthesis. I don’t do analysis, I do bottom-up emergent patterns. I do that because I don’t want to apply my own thinking to the data. After that, I build something called a mental model diagram, and that’s what that book was about is like, how do you build those things? What do they look like? They look like a city skyline.

What happens is beneath each of the towers, you try to put your organization’s solutions and features, and you end up realizing how many gaps you have [laugh] and how weak your support is, or even harmful. And so, that’s all about opportunity maps. The next book that I did was 2015 and that’s Practical Empathy. And that was focusing a little bit more on the listening.

Brian: Making people cry—

Indi: Oh exactly.

Brian: —during interview [laugh].

Indi: [laugh]. In my defense, I have—I spent a long time listening to that person after she was crying [laugh].

Brian: Sorry. [crosstalk 00:39:08]—

Indi: I was shocked.

Brian: Tell me about Practical Empathy.

Indi: Practical Empathy is basically the mental models book but evolved; a little bit more mature. I did an audible version of that which was the beginning of how I started. When I talk about these concepts, I try to talk about them in a lot of different ways so that there’s a lot of different potential ways other people can meet with them. Because other people have their own way of thinking and their own way of bringing in new concepts. I’ve had people—so the latest book is called Time to Listen.

I’ve seen people—this one person tweeted, she’s like, “Oh, my God, I had to put it down after chapter four.” And I’m like, “Uh-oh.” And she’s like, “It is such a mind shift, and I mean that in a good way.” So, the books are just each a little bit more mature versions of each other.

Brian: What’s in chapter four?

Indi: Ugh… [laugh].

Brian: Like, can you give me, like, a two-second—

Indi: I’m—

Brian: Like, quick highlight—

Indi: Yeah, talking—

Brian: Like, something stu—something triggered that.

Indi: Yeah. I’m talking about what listening is not and what’s wrong with the idea of building just one solution for everybody. And in chapter four, I talk about setting the purpose. So, one of the things—you know, I talked about thick data—if you don’t have, can we say skeleton? It’s close to Halloween right now—if you don’t have a skeleton that you can layer your data together on, like, “Oh, this bit goes on this rib and that bit goes on this rib, and this bit here also fits on that rib,” you don’t have a way to layer.

Purpose is the skeleton. So, that’s how we can layer. If we choose that purpose and we do knowledge-building the way I’m doing it, which is for design research—and we do knowledge building for market research, and we do knowledge-building for evaluative research, and we do knowledge-building for all these other things—we can layer those together if we framed each one by the same purpose. And there’s going to be a lot of different purposes that we’ll frame for, but that’s the big difference maker. What I’m trying to do is insert—okay, we’ve got a strategy space, right, we’ve got problem space, which is understanding a person’s approach to their purpose.

It’s just the person that got a lot of solutions, they’re trying to get their purpose done. We’ve got the solution space, where we’ve got our team trying to build solutions for that person or those kinds of thinking styles. If we’re talking about the dashboard, we’ve got the purpose of an employee leaving the company. That’s not the HR purpose. The HR purpose is the organization’s purpose: retain these employees.

But the data is about the employee’s purpose, which is leave the company. In between those, we have a strategy space. And right now strategy space is pretty walled off from us. Strategy space is mostly where higher-up stakeholders are guiding the direction that we’re taking as teams. And I want us to give those people stronger data.

I want us to give them this layered, purpose-focused data so that their strategies then can recognize what gaps there are, what harms there are. And there’s going to be, I don’t know, 160 different potential harms that we’re doing. Which when we start with? Well, we’re not going to decide that. They’re going to do the prioritization, but we’re providing deeper knowledge.

Brian: I love that, thinking about the skeleton and putting that purpose at the center of this. It’s been great. Indi, this is so good to talk to you. Where can people find out how to work with you and your—I know you have some training on some of these topics as well as the book. It’s indiyoung.com. Is that right?

Indi: Yeah, indiyoung.com. There’s a lot of free stuff up there, too. Other presentations have visuals, if you want visuals.

Brian: Any social? LinkedIn or any of that?

Indi: LinkedIn and Instagram. They’re all indiyoung, but on Instagram, I had to do indiyoung with an underbar at the end [laugh].

Brian: Okay. That reminds me of the old screen readers. We’d use, like, the pipe character between links like in nav bars at Lycos, and it would say, like, autos, vertical bar, finance, vertical bar—

Indi: Right? Yea, exactly.

Brian: Do you remember that?

Indi: I remember those.

Brian: [crosstalk 00:43:20], like, version 4.

Indi: Exactly [laugh].

Brian: My account, vertical bar, help, vertical bar [laugh]. Anyhow.

Indi: Oh, my God, right? So—

Brian: On that note [laugh].

Indi: —so much fun, right [laugh]?

Brian: Well, it’s been great to talk to you. Thank you so much for—

Indi: Yeah.

Brian: —coming on the show and sharing your ideas and thinking.

Indi: Yeah, I hope it’s helpful to people.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe for Podcast Updates

Join my DFA Insights mailing list to get weekly insights on creating human-centered data products, special offers on my training courses and seminars, and one-page briefs about each new episode of #ExperiencingData.