When It Comes to Research Ops, Sometimes You Have To Get Scrappy

After a few months into my first UX research lead role, I thought I had my bases covered.

Explaining what you do to all sorts of different people who all have different assumptions about what research is and researchers do? Check.

Figuring out who your key stakeholders are, going about the hard work of growing essential relationships with them, even though they think they were working just fine before you came? Check.

Setting up a research project that’s actually a research project, and educating your stakeholders along the way about what research can and can’t do? Check.

It took me a while to figure out that in order to actually scale this practice, we would need to invest in something we hadn’t thought about before: research operations!

This article details my process of realizing the necessity of a support structure for research, and the best ways to get your non-research stakeholders on board with creating this structure.

Discovering the need for research operations

I used to be an academic researcher—I come from a university setting. Sure, we had systems in place for doing research. Two areas come to mind. For students, we had things like timelines for thesis completion and standardized assessment criteria.

For our research as faculty members, we were obliged to upload our publications to an internal system where others could assess our work. This also served to track our publication productivity, an always vital metric in the academic world.

But there were plenty of things we didn’t systematize. For example, how our students found participants for their research. There was software available for analysis, but not all students used the same software (and some used none at all). The same held true for faculty conducting research.

The thing is, although we were in an academic department, teaching and doing research in a related area, we were mostly working solo or in small groups. There was no need for an all-encompassing, overarching operations strategy.

Cue a career pivot to UX research, and it turns out the best reasons to invest in research operations are also great arguments to pass onto your budget holders. First, inside a company you all have the same users. Second, research is a team sport. Third, your pain points are your stakeholders’ pain points.

Pivoting from academia to B2B

Soon thereafter, I started my lead research role in a B2B company. A major difference between academic research and applied research is this: If you’re in-house, you share the same user/customer base with everyone else at that company—not to mention sharing a vision and mission to work towards.

Let’s highlight our commonality here. We all want to talk to the same people, even if we have different questions to ask them. This can be a team effort, and that helps us to grow relationships across the company, too.

Being a fledgling research practice, we didn’t have the time or the budget to set up our own panel for user research participants. But we knew other functions at the company spoke to customers regularly. So we got scrappy.

For already accessible users/customers

We made friends with customer success managers and product leadership to get access to existing customers. We found a way to meet them where they saw the need, and use our research skills to approach these customers in innovative ways which led to previously unearthed insights.

For hard to reach users/customers

We worked closely with a particularly research-friendly PM, and secured a budget to recruit users for one research project. This helped us create a case study to build on for future projects.

Promoting research as a team sport

Research is a team sport. This was another revelation to me coming from academia. As an academic tackling a new research project, I envisaged the research question, the theoretical framework, how I would find and interview suitable research participants, how I would conduct the analysis, and the best ways to share my findings.

Yes—my colleagues were certainly helpful along the way, giving insightful comments on my research set up, passing along tips for recruitment or useful tools, and giving strategic advice on where to publish.

But, they didn’t have a stake in the project the way I did. Unless their name was going to be on the conference paper, the journal article publication, or the grant application, they weren’t as invested.

This brings up one definition of team: Team = your stakeholders who have a direct stake in a research project.

But that definition can also be expanded.Team also = others at your organization who can benefit from a shared operational setup and insights base.

After this realization, we were starting to get some traction. We got approval to invest in a research analysis and repository platform. This allowed us to share our insights more broadly, and get people involved and aware.

But even without that platform, we were active elsewhere. We got approval to post our insights decks and research roadmaps on a company-wide platform that was used primarily by marketing and their closest stakeholders. This got our work in front of people that we either didn’t have access to or hadn’t had time to reach. This, in turn, grew awareness of our fledgling practice.

Related: When "Admin" Work Has Really Been Operations All Along

Building the case for research ops support

Things were starting to happen for us. Product managers were excited about our research insights and were asking for more. Customer success and product marketing managers were asking to join interviews.

But things still took a while.

It may feel like the only way out of this is to get dedicated staff. And I would absolutely encourage you to use all the points above to advocate for a dedicated headcount for research operations staff.

The impetus for us to get buy-in to hire our first research operations specialist was getting a couple heavy-hitters to join a UX research maturity workshop, where we mapped out our strengths and weaknesses via an online white board. That exercise was what finally got us over the line, and had me happily writing up a draft job description to hand over for my team for comments and improvements.

But it could be that getting a research operations specialist doesn’t happen. Or it’s not going to happen yet. And you have to make do with what you have—whether it’s just you, or you and a couple other IC researchers who thought they were just going to be focusing on project work.

The truth is, joining a company that’s just getting set up for research means you have to do a lot of things that probably weren’t what you expected. Do your best to divvy up the tasks, and do what you can to ensure that your stakeholders know that your pain points are theirs, too.

And don’t forget to appreciate how much you’re learning.

Even on the most frustrating days, that’s how I tried to view it. After all, here I am writing this article, telling you all the things I picked up in the process. You’ve got this!