Building a UXR practice in a thriving organization: how to achieve quick wins

Starting my role as a User Research Lead at Lightricks was exciting, but being the first researcher at an already thriving, fast-paced startup is overwhelming. By the time I was given the role and asked to build out UXR, Lightricks had already achieved unicorn status and had more than one internationally recognized brand in its product portfolio.  

The challenge as the first researcher at an already accomplished company is that not everyone is so sure that they need you in an organization where they’ve already achieved considerable success without you. Not only that, but you’re also in a situation where there are already established product development practices, and you have to provide tangible value without teams feeling like you’re disrupting their flow.   

At the start of my journey, I knew that the conventional wisdom for new researchers was to seek quick wins that show the value of user research to key stakeholders, and that was my stated mission at the beginning. I soon learned, though, that there are a lot of nuances to consider even as I moved forward at full steam, chasing my initial quick wins. Now I’m a year into my role. We’ve grown from one solo researcher preaching the gospel (yours truly) to a team of three that’s significantly more integrated into product development and has more backlog than it can handle. Here’s what I learned about quick wins. 

Align wins with current business goals and what people are excited about

My manager, the VP of Product, gave me a good sense of what the key business goals were from the perspective of senior management, and I made sure that all of my proposed projects were aligned. One of the main KPIs involved exploring new ways for our target audience of visual content creators to grow their audience and monetize their content. These goals lent themselves well to generative research, and I designed a few different projects with varying methodologies.

The main win in this first set of projects was that my insights and recommendations got a lot of internal visibility. I saw them incorporated into Product Requirements Documents, roadmap presentations, and other internal documentation showing how we were moving forward and why. 

Another small but notable win was that after distributing results from our initial projects, my calendar filled up pretty quickly with stakeholders all over the company wanting to know if user research could help them in their area of the business—curiosity was definitely piqued.

When you ask for current business goals, you often look at a set of north star metrics. But in my case, what set me up for initial success was that my findings were aligned with key metrics, and I was focused on an area of the business that everyone was buzzing about.   

It’s not always immediately intuitive how important KPIs translate to research questions. Meeting with stakeholders and asking the right questions is obviously the way forward, but I found it helpful to take a step back and ask myself: what’s everyone excited about at the company right now? What assumptions are we making? What do we need to know to succeed in the current path? It’s more likely that your initial projects will get the visibility and impact potential you’re looking for if you answer questions related to key business metrics and research an area of the business that has a buzz around it.

Keep your initial projects as focused as possible

I mistakenly assumed that the more information I delivered, the more impact I’d have. But I learned that quick wins are ultimately determined by impact, not the scope of the research. When you deliver too many insights, you risk stakeholders using the insights and recommendations that are easiest to swallow while the rest gets forgotten.  

Even if your initial research is largely generative and exploratory, remember that keeping the scope manageable makes it more likely that stakeholders will find your results interesting and actually use them. Though I’d argue that this is always true, it’s especially important when looking for your initial quick wins as a new researcher.

Embrace long-term advocacy from the start

While I didn’t have trouble explaining my findings when asked, when I saw things in motion that contradicted or ignored research findings, I saw it as my own failure to communicate and vowed to do better next time. What I’ve learned over time is that the understanding and integration of research insights is a part of the ongoing product development process. Taking an approach where you present your findings and cross your fingers doesn’t lend itself to true impact unless you get lucky. The key is to see yourself and present yourself as a resource throughout the product lifecycle. What that means depends on the structure of your organization, but here are a few things that worked for me:

• End your presentation or other deliverables by letting key stakeholders know you’re available to help brainstorm next steps. Many times, especially when research is new, stakeholders don’t realize that you’re a great resource and brainstorming partner even after you deliver your findings

• Check in with key stakeholders a week or two after presenting your findings. This is a good opportunity to get feedback on the utility of your work, but it’s also a great time to ask about the status of your insights and recommendations. Are they moving forward with anything that you recommended? Why or why not? Could you address any additional research questions to help them move forward with key initiatives?

• Stay on top of what’s going on in Product and ask questions. At Lightricks, I have access to roadmap presentations. When I saw something related to recent research results, I ensured that the relevant stakeholders had access to our findings and reminded them that I was available to discuss further. On more than one occasion, I’ve reignited interest in pursuing some of our team’s key recommendations by initiating these conversations

Keep insights alive with a repository from the start

As I was settling into my new role, I’d read a lot about research repositories. Still, my initial assumption was that it was premature to invest time in this type of documentation when I was a solo researcher who hadn’t exactly done an abundance of research yet. However, I noticed that the initial splash made by my first set of research projects was relatively short-lived, and stakeholders forgot about my previous findings whenever I released new ones. 

Once I’d hired another researcher, I prioritized creating an organizational memory of insights and data with Dovetail as our primary tool. We’re still iterating on our repository approach, but we’re reaping some benefits even at the outset of our journey.

Tagging raw research data, such as interview recordings and project insights, with relevant nomenclature gives us an easy way to refer stakeholders to cross-project information when they’re working on something specific. This helps avoid situations where the product team only works with the most recent data and insights simply because that’s what’s top of mind.

My recommendation to all new researchers, solo or with a team, is to start documenting your work, sharing insights, and developing an initial taxonomy from the start. It’ll help you create a practice whereby your research findings build an organizational narrative among stakeholders rather than dying out a week after you send out your deliverables. Building your repository will inevitably be an iterative process, but starting from the beginning and getting that process in motion was a really important step for our team.

Over time, keeping all these lessons in mind, I’m finding that more and more stakeholders are finding ways to push us into their processes rather than the other way around. I’ve never met a researcher who did everything right when seeking their initial quick wins to launch a user research practice. Nevertheless, I’m hoping my experiences can give other researchers some actionable insights for getting as close as possible to achieving that ideal initial splash.