Stakeholders and Users Are Different

In many ways, talking to users seems like it should be the easiest part of a product manager’s job. I mean, how difficult can it be? Find some users, talk to them. BOOM. But talking to users can actually be the most difficult thing for a product manager to learn. Why? Because many of the behaviors and approaches that can help a product manager successfully work with stakeholders are exactly the wrong behaviors and approaches for talking to users.

When talking to your stakeholders, you want them to walk away feeling deeply invested in whatever it is you’re building. You want clear and affirmative commitment. You want to connect high-level goals with specific executional details. You want to build alignment and camaraderie.

When talking to users, your goals are very, very different. You do not want them to walk away feeling deeply invested in a specific solution. You do not want a clear and affirmative commitment that they will use your product. And, if you approach your conversations with users hoping that they will simply validate your current product direction, you are setting yourself up to learn very, very little.

When talking with users, your job is not to convince, or to impress, or to align. Your job is simply to learn as much as you can about their needs, their world, and their perspective. If you are to follow the guiding principle “live in your user’s reality,” you must understand your user’s reality in bright and vivid detail. In many cases, this means that your best approach is not to sound smart, but rather to “play dumb” and create as much space as possible for your users to communicate with you in their own words and on their own terms.

Yes, You Need to Learn How to Talk to Users

In some organizations, a product manager might be the sole “voice of the user.” In other organizations, a product manager might be working with an extensive team of user experience designers and researchers who are tasked with conducting exploratory interviews, developing user personas, and overseeing usability tests. To my ongoing consternation and disappointment, I often hear about product managers who dismiss or devalue the work of their counterparts in user research. This, to me, is not only a dereliction of a product manager’s connective duties, but also flat-out counterproductive. If you are lucky enough to have people in your organization who are trained experts in learning from users, why wouldn’t you want to work closely with those people?

The answer, I think, comes back to the same insecurity that drives our five archetypes of bad product managers. “Owning” the relationship with your user can seem like an important source of authority for a product manager. And the specific tools and techniques deployed by user researchers can feel like implicit accusations that you don’t really know as much about your users as you should. But the truth is, you could always stand to learn more about your users. And any new tools or techniques that can help you learn about your users should be taken as a gift.

I did not always subscribe to this belief. Early on in my career as a product manager, I straight-up threw a fit when a UX designer I worked with suggested that we create some user personas—composite profiles of user needs and behaviors designed to help us get out of our own heads and focus on the people for whom we are truly building. Yeah, um, I don’t have to make up a bunch of fake users because I understand our real users, thank you very much.

For all of my attempts to sabotage and undermine the efforts of my persona-peddling colleague, I actually wound up finding this tool tremendously useful. Yes, we were building for “fake” people, composited from interviews with real users. But having anybody other than ourselves in mind as we designed our product assisted us in making better decisions. User personas—like any tool or technique—is not without its limitations and pitfalls. But reflexively dismissing specific tools for user understanding does nothing to help you understand their respective limitations and pitfalls—and guarantees that you will enjoy none of their benefits.

Long story short, you can always learn more about how to talk to your users. You should read books and articles about user research. (I’ve recommended one of my favorites in the appendix of this book.) You should seek out the user researchers in your organization and ask if they can mentor and guide you. Practice every new technique you learn whenever you can. Remain open and curious not just about learning from your users, but also about learning how to learn from your users.

“Quick Wins” for Better User Research

The extent to which a product manager is formally tasked with doing “in-the-weeds” user research can vary enormously from organization to organization and team to team. But informal user research happens everywhere—from coffee lines to family barbecues. Even if user research is officially somebody else’s responsibility, there is always something to be learned from speaking directly with your current and prospective users, and it is always in your best interest to have a few quick and dirty tools at your disposal to ensure that you’re getting the most out of these interactions.

Over the past handful of years, I have been extraordinarily lucky to work with some fantastic user researchers and ethnographers, including my business partner and research mentor Tricia Wang. The single biggest thing I’ve learned is that user research requires skill, discipline, and lots and lots of practice. That said, there are a few relatively straightforward tips and tricks that I have found particularly helpful when talking to users:

Ask about specific instances, not generalizations

This one comes up a lot in books and courses about user research, and it remains the single most helpful on-the-ground tactic I’ve absorbed. In practice, this means that rather than asking, “What do you usually eat for lunch?” or “What is your favorite food,” you might use a prompt like, “Walk me through the last meal you ate.” The idea here is that people will be able to more candidly and directly walk you through their own experiences when relaying a specific instance, as opposed to trying to synthesize a general statement about their tastes and preferences. I’ve found this tactic particularly useful when speaking to users about things like music and food, for which there might be significant value judgments associated with certain tastes and preferences. For example, people are generally pretty quick to talk about specific instances of listening to music (“I put on the new Kendrick album on my last run”) but freeze up instantly when you ask them about their “taste in music” or “favorite artists.”

Don’t get too excited if you hear what you thought you wanted to hear

Sometimes, a user will outright volunteer the exact thing you were hoping they would say fairly early on in a conversation. When I began talking to users, I would often jump in with, “Wow, you know, that’s exactly what we’ve been talking about doing! AWESOME! Thank you SO much!” It took me time—and some gentle redirection by my mentor—to see how this was actually stopping me from getting a deeper understanding of the user’s real needs. It is entirely possible that a user will describe the same solution you were imagining for entirely different reasons. And having a clear understanding of those reasons as you go into actually building the product gives you much more room to think through implementation details without compromising the product’s core value.

Don’t ask users to do your job for you

There is a great story that is often trotted out in design and design thinking workshops about the OXO measuring cup. When the company’s researchers asked customers “what do you want from a measuring cup?” they rattled off a list of reasonable-sounding features. “I want it to be sturdy! I want it to have a comfortable handle! I want it to have a smooth pour!” When those researchers asked users to actually interact with a measuring cup, they saw a consistent pattern: after filling up the measuring cup, the user would squat down next to it so that their eye was level with the reading on the side. And so, the “read from above” measuring cup was born (Figure 7-1).

Figure 7-1. The “read from above” measuring cup

This story illustrates the pitfalls of asking your users to do your job for you. If you ask users to rattle off a list of features, you might feel emboldened going back to your team and saying, “I know this is a good idea—our users specifically asked for it!” But your users are not aware of all the organizational intricacies, all the internal trade-offs, and all the specific downstream concerns that go into building a product. In many cases, they are not even aware of their own needs because they are so accustomed to addressing those needs with the tools that they already have. Understanding and clearly articulating the needs of your users is your job, not theirs.

Leveling Up Versus Zooming In, or Another Way to “Why”

In the interest of uncovering high-level user needs and motivations, the word why can come in tremendously handy. But it can also be dangerous. In many cases, why can feel like an accusation. “Why are you doing things that way?” “Why do you like that band?” “Why did you go shopping on a Saturday morning?” The word why has a particular way of putting people on the defensive. And when people are on the defensive, they are generally not inclined to share very much with you about their needs, behaviors, and rituals.

So how do you ask why without asking “why”? In my own work, I’ve found it helpful think through the following prompt before asking a specific question (see Figure 7-2): is my intent with this question to zoom in on specific details, or to level up to overall goals and experiences?

Figure 7-2. Leveling up versus zooming in

If a question you are planning to ask is designed to “level up” the conversation, you are effectively asking a “why” question—even if that question begins with “tell me about the last time…” or “what was it like to…” or “how was the experience when you….” Having a clear framework for thinking about whether you are directionally moving the conversation upstream and out or downstream and in gives you a way to ask why without reflexively turning to that exact word in a way that might make your users feel defensive.

But the value of this framework goes beyond providing us with another way to ask “why” questions. Applying this lens to the questions I ask has helped train me out of one of the worst habits I displayed as a novice user researcher: asking lots and lots of “zooming in” questions for the sake of sounding knowledgeable and keeping the conversation moving.

Let’s look at an example to see why this habit was so bad in the first place. Imagine that you are doing research on behalf of an ecommerce company to better understand people’s needs and behaviors with respect to shopping. You ask a user about the last time she went shopping. She thinks about it for a moment and responds, “I went to the supermarket earlier today and bought apples.”

In the interest of keeping the conversation moving and asking some questions, you might begin asking some very specific questions. “How many apples did you buy?” “What kind of apples were they?” “What did you do with the apples?” Before you know it, you might find yourself embroiled in a deep conversation about the finer points of Granny Smith versus Red Delicious. If you are simply trying to ask “why” questions, you might find yourself asking a question like “why are Granny Smith apples better than Red Delicious apples?” Although this question technically begins with the word why, it can easily come off as both accusatory and trivial.

The bigger problem, though, is that you are not there to learn about apples. If the purpose of your interview was to better understand user needs about shopping, and you spent most of the interview asking questions about apples, you are unlikely to discover anything new, interesting, and actionable. Instead, think about some questions you could ask to “level up” to the core issues you are trying to learn about. Use questions and prompts like, “What was your shopping experience like?” or, “Walk me through the whole shopping trip.” In both of these cases, you are giving the user the opportunity to lead you to what she thinks is important, rather than zooming in on a specific detail that might or might not be significant to the user’s overall experience.

Summary: No, Seriously, You Need to Learn How to Talk to Users

As all of these examples illustrate, talking to users is not something that comes easily or naturally to every product manager. Developing the skills needed to “live in your user’s reality” often means unlearning specific behaviors that have helped you to successfully manage internal stakeholders. And it always means taking an open and curious approach to anyone and anything that might help you to better see the world from your users’ perspective.

Your Checklist:

• Talk to your users!

• Accept and acknowledge that talking to users is a real skill that takes time to develop.

• Remember that talking to users and working with stakeholders are different things, and require different approaches.

• Don’t try to impress users with your knowledge or expertise. Create as much space as you can for them to explain their reality to you, even if it feels like “playing dumb.”

• If there are user researchers in your organization, reach out to them and ask for their help walking you through the tools and approaches that they use.

• When talking to users about their experiences, ask about specific instances rather than broad generalizations.

• Don’t ask users to do your job for you! Do everything you can to understand their needs, and then think about the specific products and features that might best address those needs.

• Use “leveling up” questions and prompts to get to core goals and motivations without an accusatory “why.”

• Let your users lead you to what they think is important, rather than making that assumption for them with lots of detailed “zooming in” questions.