A three-step framework for research prioritization 

As the first researcher at Lightricks, I went from sniffing around for potential projects to being overwhelmed by backlog relatively fast. This was indeed a good sign we were getting buy-in from stakeholders. But it presented a new challenge: how do I prioritize these projects properly? 

Prioritization often gets associated with time management, but the reality is more complex. When your research backlog is large and resources are limited, you won’t get to everything. So prioritization goes deeper than what should I work on first? I realized I needed a system to prioritize what we worked on and when. Here is what I came up with and why:

Step one: Hold a stakeholder meeting before prioritizing

Often, a research project proposal is a vague idea first presented to me informally—sometimes via Slack or the last five minutes of a Zoom meeting. Initially, I’d try to get the gist informally, add it to our backlog, and prioritize based on what I’d heard. Once prioritized, I figured I would get into the details.

After doing that a few times, I realized I was essentially choosing what to work on with partial information. My usual flow for pre-project stakeholder meetings is designed to get to the bottom of goals, feasibility, and potential impact. If I don’t go through the full conversation, I’m not getting enough detail to choose if and when to work on a project or research topic.

Sometimes the missing information is inconsequential, but I’ve had a few instances where the nature of a project completely changed. For example, once I decided that a project would be next up based on a Slack conversation. It was aligned with current business objectives, and the questions asked were important to decision-making and potentially impactful on the product roadmap. I adjusted the timelines of other projects accordingly, but when I went through the nuts and bolts with the stakeholder, I found that: 

1. The data needed to create relevant user clusters for us to sample from wasn’t in order, and I was going to need to work with our analysts for a substantial period before we even started interviewing

2. There was a considerable disagreement between the stakeholder I spoke to and his manager, who would ultimately be making the relevant decisions about what population the research should focus on. This impacted the research plan and needed to be worked out and resolved before we began

In a fast-paced startup environment, there is always pressure to get moving. Still, I’ve found that agreeing to start on a project over other requests before the full pre-research conversation is almost always a waste of time. My rule of thumb is that every potential research project or request has an official first stakeholder meeting, and I never prioritize a project without it.

Step 2: Make it numerical

I’ve defined the core elements of prioritizing research projects at Lightricks as:  

• alignment with company priorities, 

• potential impact on key decision-making, 

• feasibility of UXR to answer questions, and 

• urgency versus a reasonable research timeline. 

Your list may be the same or different depending on your organization, but it’s important to have that list.  

In the beginning, I looked for red flags around these elements and made a judgment call, but I caught myself making calls for the wrong reason. For example, since I wasn’t rating a given project with each of those core elements, I was heavily influenced by things like how easy it was to work with a particular stakeholder or even political considerations. Just like it’s important to remove bias in research, there was a certain amount of bias that could be mitigated when choosing my team’s priorities.  

Ultimately, where I landed was rating each of the core elements on a scale from one to five (and sometimes, I’ll give one aspect more weight than the others by increasing the scale to one to ten, for example). Then I add up the numbers and take the highest scoring projects as my top contenders for next up. 

Doing it this way helps me remove my personal preferences from the process as much as possible. Sometimes something unexpected comes up, like a directive from my manager that influences what we choose to work on and in what order. Regardless, I find that using a numerical method puts me on the right track before other factors come into play.

Tip: Don’t let shorter projects (say a straightforward usability test, for example) hold up more in-depth research. Often, you can work on them in parallel. 

Step 3: Don’t be afraid to pivot prioritization

No one loves to talk about this, but here’s the truth: we all choose incorrectly from time to time. 

This can happen for many reasons, some within our control and others less. For example, we’ve all had projects where saturation was difficult, and we had to reconfigure our methods or add more research subjects. In that case, it’s often worth pausing a project for a short period to kick off another in parallel or get a straightforward usability test done while you wait. Other times a stakeholder’s timeline changes due to management decisions, and they can’t wait for our insights and recommendations to make decisions. In that case, it’s important to regroup and understand whether it makes sense to continue at all.

How you handle a change in organizational circumstances or necessary pivots in the research process will be situational. The important takeaway is that your initial prioritization can and will change. 

You shouldn’t be afraid to pivot as you go and always assume project prioritization will be iterative in a fast-paced organization. 

Choosing the right projects to work on and when is more than a time management issue. When you deliver insights and recommendations can affect your overall impact, and if you want to have a seat at the table when it comes to key decision-making, timing is everything. In my experience, investing time in going over details with a stakeholder and taking a numerical approach to initial prioritization helps you create a research roadmap with sufficient detail and without your own biases. Your roadmap will always be iterative but starting strong based on your priorities positions you for success.

Written by Cori Widen. Cori Widen leads the UX Research team at Lightricks. She had worked in the tech industry for 10 years in various product marketing roles before honing in on her passion for understanding the user and transitioning to research. Outside work, Cori is busy reading books of all kinds, hanging out with her husband and two kids, and traveling.