How researchers collaborate with cross-functional peers
To be impactful, researchers must ensure that their insights get buy-in from across the organization. Understanding stakeholder perspectives when making decisions is the best way to grow a user insights-driven culture.*
What does stakeholder management have to do with research? Researchers fresh into the field might expect their job to be all about researching users. They’re eager to become experts on their company’s users, and they want to use their specialist knowledge of the research process to do so. Being a research expert is indeed how you get your foot in the door. But that’s not the whole story. The truth is, it doesn’t matter how much you know about the research process or how well you can put together user research findings if you can’t get your stakeholders on board with your insights.
Why it's so important to understand the perspectives of your key stakeholders
To be impactful, researchers must ensure that their insights get buy-in from across the organization. Getting every professional – especially those in leadership roles – to consider the user perspective when making decisions is the best way to grow a user insights-driven culture. This is a huge challenge. But with such a challenge comes a great opportunity. It means that research serves the incredible function of bringing the whole company together. After all, we’re all here to serve the same customer base, right?
Every organization will have a slightly different attitude toward their users and varying cultures of decision-making, which is why it’s essential to get to know your own stakeholders well. Before we talk about some common stakeholders that researchers need to engage, let’s first reflect on what your own priorities as a researcher are.
Why do we work as researchers? Our mantra is that we want to create products that meet our user’s needs – that are useful and usable. Our role is to conduct user research, to understand their needs and pain points. Through our research insights, we then advocate for these perspectives to the rest of the organization. Inherent in this perspective is the view that we cannot know what our users need without observing or speaking to them directly. In every meeting, we are there to wave the user flag. To us, it seems only logical to build products with the user perspective in mind. However, everyone else in the organization – depending on their background, and their role – will approach their “why” in a different way.
Key stakeholders for researchers and best ways to approach them
Who are your stakeholders? A stakeholder is anyone who has an impact on your work and, conversely, anyone you can impact with your work. Stakeholders outside of research can most definitely impact what we spend our time on as researchers. That’s a topic for another article. But we can also impact those stakeholders with the work we do.
Let’s talk about some key stakeholders that researchers encounter in digital product companies. It’s worthwhile to describe their role and what they care about in their work, and discuss some best practices for approaching each group.
Research Stakeholder #1: Product Managers
A product manager is responsible for setting the vision and strategy for one or more products. They need to take into account the constraints of time, resourcing, and technical feasibility and still manage to achieve specific business outcomes – and on time. PMs are the decision-makers at the product level. They decide not only what to build, but also when and how. Because this is their responsibility, they need to gather all the requirements necessary to make the best possible decision. PMs care about the user perspective, but they have to take multiple perspectives into account, because their main concern is making the product viable in the market.
The PM/research relationship is key to cultivate. As researchers we need to understand the PM’s views toward the users (and toward research) in order to identify the most fruitful ways to work with them. This entails asking them about their background, their current understanding of their users, and the role they see research playing in their decision-making process.
If a PM has directly requested a particular research topic, it’s crucial to include them from the beginning to scope the project. It’s also wise to find out what they expect to get out of the research, and communicate clearly if it seems their expectations are beyond the scope of what research – or the particular project – will be able to deliver.
Becoming a key partner to our relevant PM is vital. Building a solid relationship with product leadership means we have a much better shot at having an impact on decision making and roadmap planning, not to mention buy-in to on topics that are most key to understanding our users.
Research Stakeholder #2: Designers
Like researchers, designers care about creating useful and usable products for their customers, and they have the skills to create those products. Designers come from a wide variety of backgrounds: Some may have performed the role of researcher themselves, and be 100% supportive of research in the design process. Others may have come from an environment where PMs simply passed on requirements to them, and they executed. UX Designer or Product Designer, a title does not reveal a background or mentality, so get to know the designers you will work with to understand their background and approach.
One key to working with designers is to ensure that the research insights you are sharing with them are actually applicable to their design work. Sharing insights as general themes will probably not be very effective. One technique is to come up with “How Might We” statements to articulate how to move insights into action. Another technique is to co-create design principles that can guide design decisions at a higher level. Always check in with designers to ensure that the process you choose is clear and useful. When designers are discussing their decision-making process to their manager and product leadership, they should be able to articulate the research insights that led them to make a particular decision. This will benefit everyone in the pursuit of creating an insights-driven decision-making culture.
Research Stakeholder #3: Data Scientists
Data scientists are skilled at both the organization and analysis of huge quantities of data. They have the ability to extract value from what others might see as incomprehensible. Where researchers may find it challenging to find enough participants in their projects (depending on the maturity of their participant recruitment processes), data scientists have the opposite challenge: While examining enormous amounts of data, they need to discover and communicate what information is crucial for their business stakeholders.
Unfortunately, in many organizations, data science lives in a separate part of the company than research. They are asked – sometimes by the same stakeholders that research deals with – to analyze different things. This can be because leadership does not yet recognize the incredible value that is produced when the quantitative insights created by data science are combined with the qualitative insights from user research.
Just because your organizational structure has not placed data science and research side-by-side does not mean you can’t collaborate. Get to know your data science counterparts. Learn what their priorities are. Learn what they are asked to focus on and what they would like to focus on. When it comes time to plan your next quarter, see how you can work together to create a project that showcases both quantitative and qualitative insights. Data can reveal interesting patterns that allows research to step in and answer the “why.” But only if you’ve established the relationship first.
Research Stakeholder #4: Customer Success Managers
A Customer Success Manager forms close relationships with customers in a B2B context. Their goal is to advocate for their customers, and ensure that the product is meeting their needs in the very best way. If, for example, a customer is complaining about the lack of a particular feature, a CSM may push product to create that feature.
On the surface it sounds as if CSMs and researchers may have the same motivations. But there are important differences. Researchers would caution against product development and decision-making based on the needs of one particular customer. Also, the “users” that the CSM knows best may be the buyers, or quite high up the food chain in the customer organization – they may not be the direct users of the product.
It’s important that CSMs feel valued by research, and they should: the expertise they have into their customer’s experience is unique and valuable. Further, any researcher who’s worked in a B2B setting understands the unique challenge of finding users to participate in UX research studies. CSMs can be key to getting access to users in a B2B context. Since these customers are their primary focus, they should always be kept in the loop if research wants to conduct research on their customers.
There are other key stakeholders too numerous to mention here: Marketing and sales professionals, operations specialists, engineers, customer service representatives – the list goes on. The key to remember is that research can only reach its true potential through collaboration. It’s your job as a researcher to uncover who your most valuable collaboration partners in your organization are – and these people may not be introduced to you in your first week on the job. Gaining this holistic view is both an opportunity and challenge of research.
Wrapping Up
I’ve covered some key approaches to building relationships with these various stakeholders. Remember, you can use your research skills to uncover the needs and pain points not just of your users, but your stakeholders, too. Research can work its magic in an internal context as well as out in the field with users. Then, use this deep understanding of your stakeholders to customize your research practice – what you study, and how you report your insights – so you can craft your research to be the very best fit for your organization.
*This article was originally published on Sprig.