The challenge of research staffing
I lead research for 2 product organizations at Pinterest, a consumer tech company that builds a software product used by almost half a billion users a month. We are nowhere as large as a Google or Meta, but we are also not a startup. Being somewhere in between, I expect these learnings can be abstracted to companies of varying sizes. I will use the term “research” throughout this post to refer to what is often called “UX research” or “product research” functions — the folks responsible for delivering insights about users to inform product decisions and directions.
One of my most important responsibilities is to set up research staffing models by considering the needs of the business, the research readiness of teams, & researcher skills and needs. But getting research staffing models right can be quite a challenging task.
There are often fewer researchers than there are product managers and designers, and far fewer than there are engineers. Research resources must be leveraged wisely, but not every team may be ready to work with researchers. There may exist established processes where research hadn’t been a necessary step, or a lack of understanding of what research can do, or even not seeing a researcher as a thought partner.
Researchers also come with quite varied skillsets. It’s generally understood among researchers that the best practice is to start with the research question, and then choose the right methods to answer the question (never lead with the method!). But researchers are constrained by timelines, and more often than not, researchers have methodological strengths in particular areas and may have only scratched the surface of other areas (this is a very natural thing because developing proficiency in any method requires a certain depth of knowledge and skills).
Despite all this, when leveraged well, research can transform the way a team approaches problem solving. It can illuminate unseen opportunity areas, identify which segment of users to focus on, and prioritize the most critical user problems to solve for. Research can transform a team operating on assumptions and hunches to one steeped in insights.
But to get to that promise, we need to staff researchers to not only the right problem spaces, but the right teams that are ready to partner with researchers and make use of their insights.
This post will help folks think through how they might design their research staffing models, whether you are a product manager at a startup thinking about hiring your first UX researcher or a research manager growing your team.
3 models
Last year, I implemented 3 kinds of research staffing models that I’ll share in this post.
Note that these are simplified models where I purposefully create differentiation to make it easy to articulate differences and how to think about structures. The reality is far messier.
There isn’t an inherently correct model, but there are conditions that lend to certain models being more suited in a scenario than others. My job is to understand these conditions and correctly diagnose what circumstances I’m dealing with, knowing that these conditions can frequently change (i.e. re-orgs happen, people join or depart, etc.). Getting staffing right is an ongoing process.
The Embedded Model
In this model, a researcher is “embedded” within a product team. The researcher conducts research solely for this team and attends recurring team meetings where they can soak in contextual information and have abundant touchpoints to contribute to team conversations. The Embedded model enables the researcher to have focus, in both subject matter and relationships, and offers the team a reliable person they know they can go to for questions. Of the 3 models, it has the least amount of complexity and scope for a researcher to navigate.
This model is only useful when a team has a clear need for research and is prepared to action on it. Early career researchers particularly benefit as well because they can focus on honing their research craft without the overhead of having to navigate organizational complexity that comes with other models.
BENEFITS
Strong product intuition
The researcher develops deeper subject matter expertise due to the ability to focus on a problem for an extended period of time. This focus allows their knowledge to expand beyond user needs to an understanding of product differentiation and the competitive landscape. Their research recommendations become more refined and they develop a strong Point of View about what the team should and should not pursue. The team will more quickly hone their intuition and be able to generate better hypotheses, freeing up the researcher to explore questions for the biggest unknown areas.
Clearer planning process
Perhaps one of the greatest advantages of this model is the clarity it provides about research resources. For the team, they know they can expect research support and can incorporate research into their operating model and milestones. For the researcher, it’s clear who they work with and what problem they work on. This significantly reduces the operational overhead required when a researcher is responsible for multiple teams with competing objectives and timelines. The researcher can now build out a research vision & roadmap for the team looking months in advance, and the team can plan their learning agenda thinking holistically about the roles of research, experimentation, and other forms of learning.
Sense of belonging for the researcher
A non-trivial component is the researcher’s own sense of belonging to a team. In the embedded model, researchers build stronger relationships and feel like they are a part of a team, not floating project to project. Researchers can often feel like their function is misunderstood, so the value of having deeper relationships and stronger rapport can help them combat these downsides. An added benefit I often see here is the researcher feels greater ownership in their team’s success and can find themselves taking on more collaborative kinds of work or culture-building roles (i.e. teaching the team basic researcher skillsets, partnering with designers to conduct co-creation sessions, setting up ongoing empathy moments to inspire their team, etc.).
DRAWBACKS
Missed opportunities for greater company impact
By having a researcher focus on one thing, there are more things they are not paying attention to, such as higher leverage research opportunities that could influence more important decisions across a company. Just like with any team, there’s a risk of silos creating inefficiencies; the researcher may not realize their insights could be useful for another team, or may not feel motivated to scope their study to address other teams’ needs regardless of synergies.
Skills mismatch leading to waste
Sometimes the product team needs fluency in specific skills to accomplish their objectives and the researcher can only lead with what they know or are able to learn in a short time. What if it’s a 0 → 1 space and a researcher has only done usability studies? Or perhaps a team needs to prioritize user sentiments via data at scale, but they’re staffed with a qualitative researcher who hasn’t had training in surveys and statistical analyses. These mismatches are harder to identify when people who are less familiar with the research discipline are making the staffing decisions.
Researcher feeling stuck
The embedded model puts more pressure on finding a match that will meaningfully challenge and stretch the researcher. Researchers are often motivated by their own curiosity (there’s a reason they chose a career path of ‘research’), and spend hours studying people and making meaning out of these observations. Sometimes the researcher’s interests won’t align with the topic the team is working on. Or the problem isn’t intellectually stimulating. Or the team doesn’t understand the value of research. A researcher can become frustrated in these situations and begin looking elsewhere for better options. Furthermore, more experienced researchers may feel limited by the narrow scope, and would look for other attributes for this model to feel compelling. (i.e. the problem space being the most critical company priority, the opportunity to work with a very strong product leader, working on an exciting 0 → 1 problem, etc.).
The Horizontal Model
In the Horizontal model, a researcher is staffed to an organization or “org” (essentially a collection of teams that ladder up to the same product leadership; different companies will call this different things). Unlike with the Embedded model, here the researcher often shifts topics / teams project to project based on the most important business need.
This model is often under consideration when research resources are limited, or cases where a researcher has a specialized skillset (in my case, a quantitative researcher with deep survey science and behavioral analyses expertise on my team stretched across 2 orgs while our more common qualitative researchers were embedded to specific teams in those orgs). But with such broad territory and potentially shallow interactions with any one team, it is not uncommon that teams may not have built the muscle of working with this researcher. Consider investing in educating teams on what this researcher can help them with and how to work with one.
Also in cases where this horizontal researcher is working alongside other researchers who are more closely embedded to individual teams in the same org, it’s valuable to set the expectation that the horizontal researcher partners closely with those embedded researchers to download valuable context and scope the right research questions. They both benefit — the embedded researcher shares their relational capital and subject matter expertise while the horizontal researcher shares their time and unique skillset.
The horizontal model also requires a broader needs-finding and ruthless prioritization process that determines what problems get tackled, and when. Ideally, involve a Product Leader at the org level (who sees the entire territory) and can review the portfolio of requests (or make their own research asks) to give quick input on research prioritization decisions.
BENEFITS
Prioritizing what’s important
This model allows the flexibility for the highest priority research needs across the org to get prioritized. By not committing the researcher to a specific team, it invites more decision points to consider what is the best use of the researcher’s time at any given moment. It also allows top-down strategic needs to be addressed by the researcher who’s serving the broader org.
More research coverage
Sometimes, an org benefits from having more teams get a little research support. For example, this can help org leadership get a broad understanding of different problems in a short period of time. It can educate more teams on what research can do as they build research capacity long-term.
Broad scope & holistic understanding for the researcher
The horizontal researcher gets to investigate a breadth of topics. This allows them to build a holistic knowledge of the entire org and how it works vs. feeling siloed to one team (Embedded model) or one problem area (Initiative model). For the researcher, this can help them build business intuition (seeing the relative importance of different product areas) and provides a wealth of interesting new domains to explore next. The broad exposure also enables the researcher to identify overlaps across teams and craft more foundational questions that no one team is explicitly asking for, but can solve unmet needs for many.
DRAWBACKS
Poor prioritization of research
The reality is that many teams do not understand how to leverage research and formulate useful research questions. Without a dedicated researcher actively partnering and educating them about research, the best research questions may not surface. What might end up happening, then, is the researcher more frequently tackles problems surfaced by the teams who have more research maturity and stronger relationships with the researcher, rather than tackling the most critical problems.
Many problems, poor product intuition
The horizontal model may require the researcher to quickly ramp up to speed on a variety of problem spaces. This can be both interesting and overwhelming. Developing product intuition takes time and repeat exposure to a problem space, but researchers in ths model may only be able to get to a shallow understanding of each space and feel more like an external consultant. They complete one project, and then may have to move to another area soon after.
Too many stakeholders, too few relationships
The researcher may have to deal with many different teams, and therefore different people, personalities, and functions. This is no easy feat as rapport building takes time and shared contexts. Meanwhile the researcher can feel rather isolated and like they don’t have a “team”. Unlike with the Embedded model, they are often excluded from regular team meetings and social gatherings among folks staffed to specific teams. This can make the work feel more transactional and the researcher may find they are constantly building trust from scratch with each project they work on.
The Initiatve Model
In this final model, a researcher is staffed to an Initiative, which I use to mean a cross-company problem space that cuts across teams and is a priority. For example: South East Asia market, GenZ, Tablet users, etc.). Unlike the Horizontal model, there isn’t a specific org this researcher maps to; in fact, Initiatives often cut across org and require more complex stakeholder navigation dynamics. In the Initiative model, the researcher is responsible for becoming the subject matter expert and developing a research roadmap for the Initiative that they then execute on. They will often connect with a wide variety of stakeholders, but will lack the depth of relationships or understanding of any particular team.
Ideally, the initiative is important enough that the company sets goals for making progress in the Initiative, and that specific teams share responsibility in adopting this goal. This ensures teams have enough skin in the game to care about it. Even better if there’s an Initiative Leads group responsible for defining success, tracking progress over time, and holding other teams accountable. Having this infrastructure in place provides enough structure for the Initiative researcher to tap into and have a greater likelihood of impact.
BENEFITS
Centralized insights & thought partnership
Often times, teams without a researcher find themselves having to make guesses with limited information in order to move forward despite feeling like they’re stumbling through the dark. Or even worse, they don’t consider the user problems at all. The Initiative model positions a researcher to be the person any one can reliably seek out for thought partnership for the researcher’s specific topic of expertise. This researcher has deep intuition about the problem space they represent, so even if they haven’t executed research on a specific question, they can still formulate well-informed hypotheses to guide teams. They are like a walking encyclopedia of insights, sharing knowledge with product teams and their embedded researchers whenever they have questions.
Foundational understanding (not getting lost in micro-learnings)
When numerous teams are all tackling parts of the same problem, having a researcher that sees the forest for the trees ensures research studies can guide broader strategy and not just tactical questions of one specific team. It also helps avoid a scenario where product teams just want the researcher to test what has already been built (regardless of user desirability) due to where they are in their product development cycle. By freeing the researcher from any one product team, they have greater freedom and perspective to identify bigger and more enduring research questions to tackle. Rather than rushing to figure out “how do we make our feature better?”, the question might start with “What is X and how should we be thinking about approaching X?” or “What are the biggest unmet needs for users and where is our opportunity to play?”
Intellectually stimulating for researcher
The Initiative Model researcher benefits from both depth (getting a deep understanding on their topic) and breadth (relating their knowledge to a variety of teams). This can be intellectually rewarding for a researcher since they have opportunity to devise varying questions, methods, and scope. Intersecting with more teams also gives a unique perspective about how a product, or business, as a whole works.
DRAWBACKS
Teams feel unsure how to get value from research
Individual teams operate on each of their own objectives and timelines. Decisions need to be made and they cannot wait for research resources to be available to act. Meanwhile, a researcher in the Initiative model is purposefully taking a zoomed out view and may not be beholden to any particular team’s deadlines. This can leave some teams unsure how to influence the research priorities or even get frustrated by the relative lack of urgency from the researcher.
Research insights lack actionability
Strong research insights and recommendations require an attunement to what matters most for the team — those decisions, ambiguities, and constraints the team is dealing with. In this Initiative model, the researcher is less connected to individual product teams and their operations, and therefore won’t know the ins and outs of their operating context. This can put the researcher’s work at risk of lacking clear “So What’s” and actionable recommendations.
Operational complexity for the researcher
This model requires the researcher to navigate significantly more organizational complexity than the embedded model. This looks like more teams and more stakeholders with their unique operating models and personalities. These teams will have different perspectives, different goals, and sometimes speak in different languages. So as much as the researcher might love nothing more than to go deep on understanding a problem space, they may instead find themselves drowning in operational overhead.
Implementation
Lastly, be ready to be wrong.
One thing for sure is that your expectations and assumptions are going to be put to the test when using these models with real people. We make staffing decisions off of incomplete information. Re-orgs happen, skills gaps reveal themselves, people conflicts emerge, and important work gets overlooked. Expect these to happen, update your understanding of current conditions, and make adjustments. And be ready to be wrong again.
In summary…
I love thinking through research staffing models. If you’re grappling with some tough questions here, I’d be happy to advise. Feel free to send me a message via LinkedIn.
Appendix
As I mentioned earlier, these 3 models are an oversimplification of reality. Here’s a somewhat closer illustration for how these might actually look in practice across 2 orgs (modified from reality for confidentiality reasons).
