Are you really understanding your users or going through the motions?

Product folks are more excited than ever about talking to users.

Even before the rise of AI, there was already a movement to democratize UX Research. Many tech companies started enabling product managers to engage directly with users, without relying on UX Research professionals as intermediaries.

Now, with AI tools evolving to support both research setup and analysis, there’s even more momentum for product folks to speak with users.

Recent layoffs and a shift towards frugality in tech have added to this trend. Talking to users has become a key part of the product manager's role, especially when full-time researchers are laid off and product designers are overburdened by executing new design iterations. 

I’m not against product folks engaging directly with users. I support it. I believe product releases shouldn’t be based solely on data experiments. Interacting with users is essential to creating user-centric products.

When product managers receive instructions from leadership to get closer to users, this practice can easily become a box to check. It might turn into a requirement that doesn’t necessarily create conditions for learning.

I’ve been leading UX Research practices for over a decade. I’ve seen the good, the bad, and the ugly. This experience motivates me to discuss what’s tempting to do with users and what’s a better way instead.

The difference between these concepts lies in whether teams are willing to explore the problem space openly. It’s about whether they need to be “seen” as doing research or to be proven right.

A knowledge-gathering practice involves creating a safe space for users by building trust and intimacy first. Then, it’s about asking open-ended questions to explore their points of view.

In contrast, knowledge performance happens when a product person skips building trust and starts asking what might feel like random questions. They might express strong opinions that they want users to agree with.

Those focused on gathering knowledge are humble. They know that no detail is irrelevant and no information is final. 

At its extreme, “knowledge performance” can resemble the work of a social media influencer. In this case, learning from users becomes secondary to creating publicity around meeting them and making the event seem big and bold.

As I draw this distinction, I want to clarify one thing. A knowledge-gathering practice doesn’t have to be like academic research, where we seek truth for its own sake. UX Research happens within a business ecosystem and must help products generate more revenue. That's why getting buy-in from leadership is essential. Leadership needs to understand what research we're doing, how we're doing it, and why it serves the business purpose.

We can achieve this by understanding what leadership cares about and the language they use. We can then frame our work in ways that make sense to them and present it when research input is most valuable. There are ways to do this without turning our practice into a knowledge performance. That’s what I invite us to discuss in the rest of the piece.

…and host a big event.

Tech companies compete to brand themselves as user-centric. It’s no surprise that big events where product folks meet end users are appealing. These events allow conversations with users and also serve as public displays of the company’s commitment to its users.

To be clear, I’m not against big events at company headquarters. They can be fun and engaging for everyone involved. But the key is intention:

When we invite users to our offices, whether for a one-on-one interview, usability testing, or a larger event, what do we really want from that encounter?

Location matters when we engage with users. It’s a key factor in the power dynamic between users and those who build products for them.

For example, the first two questions can be addressed by inviting users to our location. But the third and fourth questions require us to ideally meet them where they are. If that’s not possible due to logistics, meeting in a neutral place (online or offline) is the next best option.

The reason is simple:

When users are taken out of their natural environments and brought to a location where the host controls the space, they might not feel comfortable enough to share their true thoughts. They might feel obligated to be polite to their generous host. As a result, we risk getting answers based on what they think we want to hear, rather than what we need to hear.

Elwood and Martin explain it well:

“The interview site itself embodies and constitutes multiple scales of spatial relations and meaning, which construct the power and positionality of participants in relation to the people, places, and interactions discussed in the interview. We illustrate how observation and analysis of interview sites can offer new insights with respect to research questions, help researchers understand and interpret interview material, and highlight particular ethical considerations that researchers need to address.”

Although Elwood and Martin’s work is intended for academic researchers, the point also applies to product folks who talk to their users.

Building on their work and my experience, I suggest product folks find ways to meet users where they are, in smaller, more intimate groups. Visiting users at their homes, workplaces, or even on the streets while they go about their day is more likely to give us a truthful picture of what they think and how they feel about the product.

When that’s not possible, the next best option is to meet in neutral places, including online sessions where users can join from the comfort of their own spaces.

In my research career, I’ve met product folks who often prefer numbers and quantitative data.

They might run A/B tests on existing digital products, but when exploring unknown terrain, surveys seem to be the go-to solution.

I’ll be clear: I’m not against running surveys, just like I’m not against inviting users to our offices. But the why and the how matter.

Senior leadership and product directors might be more comfortable with numbers than with ethnography or interviews. They might trust reports more when percentages are shown and conclusions are drawn from numerical data. This can create a false sense of confidence among decision-makers. The numbers seem final, after all.

But that doesn’t mean those numbers are leading us in the right direction. This is especially true if surveys are conducted without the support of experienced UX Researchers who know how to avoid asking biased questions.

If the goal behind running surveys is to get quick outcomes that impress leadership, that’s probably not a good idea. It might signal knowledge performance rather than a knowledge-gathering practice. A better approach is triangulation, where we use both qualitative and quantitative methods to get a more holistic understanding.

For example, preliminary user interviews can help us understand how a smaller group handles a challenge. We can then run a survey among a larger group to see if what we learned scales.

Or, surveys can highlight a phenomenon we don’t fully understand. We can follow up with a qualitative study, like usability testing, to see users in action.

There will be times when we need to run quick and dirty research. We won’t always have time to triangulate. But even then, it’s worth asking ourselves before running a survey: What’s the best way to move forward given our constraints?

If I had to describe Product Managers to my four-year-old, I’d say they’re people who work on building solutions.

They don’t design or code (except in rare cases). They might not even do the research. But at the end of the day, they’re responsible for making sure the solutions work and get results.

So, it’s no surprise that product folks are invested in their solutions. There’s something almost emotional about validating hypotheses. Like:

“Ha! I knew I was right.” “That’s exactly how it’s supposed to work.” “I knew it.”

That’s why it’s hard for many product folks to resist the urge to validate what they think they know through research. Being too invested in their anticipated solutions—what we might call product intuition—can turn research into knowledge performance rather than knowledge gathering.

I don’t disagree that some of the best product leaders have great intuition. They make bets based on their experience and express curiosity through experimentation.

But what’s a strength in product management can be a weakness in research. Especially if we can’t start with a blank canvas.

If we seek to validate what we believe through biased questions or inappropriate research methods, our research activities might give us false confidence. This knowledge performance can make it look like we’re making data-driven decisions. But the data we gather isn’t trustworthy if we’re just validating our hypotheses.

Instead, we should engage with users not to validate, but to understand, without preferring one solution over another. Product folks need to create psychological distance from their hypotheses by listening to users openly without worrying about how they’ll respond. Gathering feedback from other teams who aren’t invested in the same product area can be helpful, too.

In today’s fast-paced tech environment, talking to users has become a vital part of product management. But it's important to distinguish between gathering knowledge and simply performing it. 

Whether we’re inviting users to our offices, running surveys, or validating hypotheses, the intention behind these activities is key. Are we truly seeking to understand our users, or are we just going through the motions? 

As you reflect on these ideas, I’d love to hear your thoughts. How do you build user-centricity? Share your point of view in the comments, and connect with me on LinkedIn.