All those tools for customer research aren’t really about understanding customers. They’re about understanding other humans. You can use customer research tools—sometimes with a little adaptation—to understand needs, problems, and possible solutions for anyone in almost any context. In this sense, they’re all customers.
In this episode, Richard and Peter look at how customer research tools are useful in all kinds of contexts beyond product development. Got a relationship with a stakeholder at work that you’d like to improve? Learn how you can use customer research tools to better understand that stakeholder’s needs and how you and your team can help solve them.
Welcome to the Humanizing Work Show!
Here at Humanizing Work, we’re big fans of Jeff Gothelf’s work. If you’re not already familiar with Jeff, please check him out. His book Lean UX, which he co-wrote with Josh Seiden, is fantastic, and if you like our stuff, you’ll find a lot of great ideas in all of Jeff’s work. Jeff recently wrote an article encouraging us all to think about organizational change through the lens of product thinking, and once again we found ourselves in complete alignment.
We’ve been teaching a similar idea for a while, and have done conference sessions over the past couple years about this topic called “They’re all customers.” We like to use a number of tools from the product space to think about and approach and lead organizational change, and in today’s episode, we look at how the tools we use for customer research—like customer profiles, interviews, product assumption tests—can transform your relationships with other stakeholders who aren’t exactly customers in the usual sense.
But before we jump into it, we want to help you with whatever challenges are most frustrating you right now. If you’re feeling stuck on something, whether that’s trying to take a more human-centric approach to your work, trying to make your product or business outcomes better, or if you’ve just got a tactical, process-related question, let us know about it. Send us an email at firstname.lastname@example.org with a few details about the situation, and we’ll share how we might think through your challenge right here on the Humanizing Work Show.
And just a quick reminder to rate and review the Humanizing Work Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. Your help spreading the word is super meaningful to us!
And, if you want to get access to more of our free content, not just the show, Sign up for our newsletter where we share one key idea every week. You can sign up at humanizingwork.com/hwnews.
We treat stakeholders, bosses, etc differently than we do customers, but…
If you’re in or even just near product development, think about the things you and other product people you know do to try to understand customers, to explore their problems and needs, to test what solutions might address those problems. There are probably quite a few different practices in your toolbox for this: customer profiles or personas, customer interviews, observation, A-B tests, MVPs…I could go on and on.
Now think about the tools and practices you use to understand your team’s stakeholders; understand your boss– your team members.
You probably don’t have as many things coming to mind for this crowd.
Here’s the big idea we’re going to explore for this episode:
All those tools for customer research aren’t really about understanding customers. They’re about understanding other humans. You can use customer research tools—sometimes with a little adaptation—to understand the needs, problems, and possible solutions for anyone in almost any context. So in this sense, they’re all customers.
Let’s look at some examples. First we’ll look at the usual product context to make sure we’re talking about the same thing, and then we’ll look at it in this extended way applied to other stakeholders.
Our Approach to Customer Profiles
To capture and communicate the results of customer research, we really like the customer profile from the Strategyzer value proposition canvas. It has 3 parts, 3 lenses through which we’re looking at the customer segment. They’re called jobs, pains, and gains.
Jobs are from the “jobs-to-be-done” literature, things the customer wants to accomplish or progress the customer wants to make. They’re not about our product. They’re expressed in customer terms. So, in the context of something like a music streaming service, for example, the customer job is actually “Get motivated to do my workout” not “Build and play a high-energy music playlist.” The customer doesn’t want to build a playlist. They might “hire” the playlist functionality in an app to help them with that job, but the job isn’t really about playlists. It’s about getting motivated.
We find it useful to make two distinctions within customer jobs. And then, those two distinctions intersect to form a 4 part matrix. On one dimension is individual vs social. Some jobs are me doing things for myself. Some jobs are me doing things for or with other people. On the other dimension is tactical vs psychological or emotional. Tactical jobs are about just getting a thing done. Psychological jobs are about feeling or thinking a certain way.
Let’s intersect the two dimensions and look at some examples for that music streaming service Peter mentioned:
Individual tactical jobs are practical things I want or need to accomplish or make progress on. For example, listen to a specific song, or discover new artists or songs I would like.
Social tactical jobs are practical things I want or need to help others accomplish or make progress on. For example, make a “mix tape” playlist to share with a friend.
Individual psychological or emotional jobs are things I want or need to do related to my internal state (how I feel or think), like get that earworm song out of my head, motivate myself to work out or pass the time while driving or doing a boring task.
(We frequently “hire” music to do individual psychological jobs for us. This is probably the biggest category for this context.)
Finally, the fourth kind of job; social psychological jobs are things I want or need to do to affect others’ internal state (including, quite often, how they think about me). Examples for music include get people dancing at a party; or be perceived as the friend who finds cool new music
(Those status jobs like the last one are really important. We “hire” products and services all the time, from cars to lawn care to clothing, to influence how other people perceive us.)
So, that’s customer jobs. Things people in the target customer segment want to accomplish or to make progress on, expressed in their own terms, apart from the product or service we’re offering.
The other two parts of the customer profile are pains and gains. Pains are simply things that get in the way of accomplishing jobs: Impediments, inconveniences, or frustrations. Like, “Building playlists is tedious; ads interrupt my music and kill the mood I’m trying to set.”
Finally, gains are dreams, aspirations, or ideal outcomes. For example, I can easily find new music I like as it comes out; or my friends are impressed with my eclectic but tasteful playlists.
Now, all those examples, of course, were in the usual context for customer research: product development. But we discovered that it can be really useful to apply the same model to understanding the needs of other stakeholders. Stakeholders have jobs to be done as well, and it’s helpful to think of the changes we’re interested in, or even our team or our own work, as products that they may or may not want to hire to get those jobs done. Let’s play out an example.
One example that comes to mind for me is that I was working with a software product team, and they were really interested in adopting a more agile approach. At the time, the team was broken out into three specialties: engineering (or programing), testing, and design, each had their own management chains and reporting structures.. The engineering and testing groups were pretty excited about adopting Scrum and creating a cross-functional team around that. But the designers, who had a lot of political power and reported up through a different vice president, were fairly hesitant and even sometimes resistant. They weren’t sure how design would fit into a Scrum approach.
Let’s look at the design group from this customer profile perspective. The designers might have had tactical customer jobs like:
- Create a good user experience
- Make the product look beautiful
- Create a unified look and feel across all of our products
- Create design assets that are easy to implement in our product
They may have had psychological jobs like:
- Feel like I’m good at what I do (on the individual side)
- Feel like I’m in service to our customers and their needs
- Be perceived in the design community as a great designer (on the social side)
Pains might have included things like:
- Design is never given enough time to do great work
- Other people don’t appreciate the value of good design
- Design is viewed as just the “visuals” instead of integral to the customer’s needs
And gains might sound like:
- I want to be proud of the product I’m part of creating
- I want to get recognized for the quality of my work
- I want to make our customers’ lives easier and less frustrating.
Now, as I list through these jobs, pains and gains, you can probably imagine how the move to adopt Scrum could feel like it threatens some of those jobs, like it might increase some of the pains, and like it might put those gains at risk. From that perspective, the design group’s wariness about Scrum makes a ton of sense.
Customer research applied to people who aren’t customers as we normally think about them
High Level Overview of Situational Interviews
Customer profiles are the canvas for capturing what we know about a customer, or about a stakeholder. But how do you get the information to put on a profile? You don’t want to just guess or make it up.
There are a variety of customer research techniques, and many of them apply outside of the usual product development context. One of our favorites, which we use all the time, is the situational interview. At a high level, here’s how it works…
You arrange a 20-30 minute conversation with someone you think may be in a customer segment for your product.
Before the interview, you brainstorm a few situations in which someone in that segment might “hire” your product to help do a customer job, resolve a pain, and/or create a gain. Now, they may not hire your product or service to do that today, but you can imagine them doing it in that situation. Once you have those situations in mind, forget about your product. You’re not going to talk about it in the interview at all. We were just using it to pick a good interviewee and set it up.
Now, in the interview, you’ll prompt the interviewee to tell you about an example of the situation. Back to the music context, “Tell me about a recent time you played music, whether via a streaming app, radio, vinyl records, or whatever. What were you hoping to accomplish with the music? What was hard about that?”
Then, as that story slows down, you prompt for another example. “What’s another recent example that was different from that one somehow?”
You’re not taking feature requests when you do this. You’re not asking the person to predict their future preferences or behavior. You’re just asking about real past examples. In the process, you’ll learn about the customer’s jobs, pains, and gains. You’ll probably get ideas for your product. You’ll certainly understand that kind of customer better.
So, how do we adapt the situational interview for other stakeholders? You might set up a conversation with a stakeholder like this, “Hey, I’m trying to improve how our team works with your team, so I’m having conversations with a variety of people to understand their needs, challenges, and contexts better. Would you be willing to spend a half hour chatting with me? No need to do a lot of prep—I just want to have a short conversation.”
Let’s return to the design group we talked about a moment ago. Imagine what the interview with a designer might sound like.
We want to start with a situation that could tell us something about the customer’s jobs, pains, and gains. Perhaps, for this design group,“Tell me about a project you worked on that felt like it went particularly well.” And then ask follow up questions to get a sense of what made it feel successful. Then, I might move to, “What’s an example of something you worked on that was also successful but was different from that first example in some significant way?” With this follow-up, I’m trying to tease out the commonalities and differences between the two examples. This helps me avoid assuming some incidental detail in one example matters more than it does. Like, “It was summer during the first one, and apparently it’s really important for this designer to take on projects during the summer.” That was just an arbitrary detail. I’m going to get a different example, that shows me what things really matter in there. After a couple positive examples, I might explore a more challenging one. Maybe, “Tell me about a project you worked on that felt hard or frustrating.” And again, ask follow up questions to explore the details.
Customer interviewing is a skill that requires a lot of practice to develop. We spend about a quarter of our Advanced Product Owner program on customer interviews, and participants often say things like, “I’m getting good results with this already, but I see that I have so much more practicing to do to get really comfortable interviewing people.” So, don’t be surprised if it doesn’t go as smoothly as you imagined, the very first time. You need a lot of reps to get good at it.
More Informal Ways to Do This
You don’t even have to do a formal interview to use this approach. It’s also useful when people complain, vent, ask for a specific solution or process change, or whatever. For example, if someone comes to you asking for a process change, you might say something like, “Oh, that’s an interesting idea. What was happening the last time you wished that was how things worked? What was hard about that? If this change is successful, what outcome would that produce for you? What makes that outcome important?”
Notice how those questions express curiosity and how the answers are likely to reveal jobs, pains, and gains. Then, you can think about the best way to address those jobs, pains, and gains along with all the other ones from different stakeholders you know about. You might not be able to do the thing this particularly stakeholder wants you to do. But you may be able to propose something else that meets the underlying need. Worst case, you can’t address the underlying need but you at least understand it and can try to mitigate the downside for the person, and kind of sympathize with what’s hard about it.
The Laloux Model
As we’ve used this approach, we’ve found a useful connection with some categories of psychological jobs described most popularly in the book Reinventing Organizations by Fredric Laloux. (Our video about the model) When I first read that book, I got pretty fired up about it, made a big illustration of it that kind of went viral. The underlying model, adapted from Clare Grave’s stage development theory, seemed to answer some frustrating questions I had about why agile adoptions might fail. In the years since then, I’ve come to see that approach as less of “how the world works,” and more of “what might be driving someone’s choices today?” People are not categories or colors, they don’t move in a single direction. They are people interacting with ever changing situations and a complex, unmappable set of influences.
So, with that caveat aside, thinking of that model as a set of common categories of psychological jobs has still been really useful. Here are a few categories from that model that really stand out in this scenario:
- People might have a need for stability and consistency, what Laloux referred to as “Amber”
- People might have a need for achievement and innovation or recognition of their merit, what Laloux referred to as “Orange”
- People might also have a need for connection and fairness, and equality what Laloux referred to as “Green”
Another idea from the model is that those categories are often in conflict, like a person who gets frustrated with an over-emphasis on consistency at the expense of innovation and achievement.
The designer from our example might have needs for recognition and connection with the customer, for example, and be frustrated that Scrum feels like an attempt to standardize everything even where it might not be useful.
Having these categories as shorthand is sometimes useful to us, to more quickly focus in and empathize with stakeholders during situational interviews and the more informal situational conversations we described earlier. But it’s important to remember that these are just hypotheses, going back to this idea of how complex our motivations really are. So in those interviews, in those conversations, ask questions that might give you data that your hypothesis is wrong about those categories. If, for example, my hypothesis is that our designer is driven by individual innovation and is in conflict with standardization, I may ask about a time when a standard approach was a good choice. If they can think of some examples, those categories might be oversimplified in this context. If they have a strong negative reaction to the idea that any standardization might be useful, my hypothesis might be true.
What’s a relationship at work you’d like to improve? Think about that other person or team as a customer of your work or of your team’s work, and try out some customer research tools in that context.
Please like and share this episode if you found it useful. Let us know what you notice as you start thinking of your stakeholders as customers of the change you’re excited about.