The queue is full. You’ve got five requests, time for two, and three stakeholders who each think theirs is urgent. That’s not a scheduling problem. It’s a judgment call, and judgment needs a framework.

Here’s how I think about it.

Start with risk, not urgency

Urgency is usually someone else’s anxiety. Risk is the actual cost of getting it wrong.

Start by asking: which request introduces the most risk if we get it wrong? That one goes first. Strategic decisions carry more risk than tactical ones. If a team is debating button placement versus navigation architecture, those aren’t equivalent questions. You can ship the wrong button color and fix it in the next sprint. You can’t unbuild the wrong architecture six months in.

Ask yourself: if the team moves forward without this answer, what breaks? If the honest answer is “not much,” it’s not a priority. If the answer is “a lot,” that’s your starting point.

Pressure-test it with the PM

Once you’ve ranked by risk, map it to the roadmap with the PM. This isn’t about getting permission. It’s about surfacing mismatches before they become problems.

Sometimes what looks like a low-risk question is actually load-bearing for something you don’t have visibility into. Sometimes the “urgent” request is tied to a feature that’s three quarters out with no real deadline. You need that context to make a defensible call.

This conversation also gives you cover. When you deprioritize something, the PM knows why. That’s a lot better than the team discovering later that research sat in a queue while a key decision went sideways without it.

Look for overlap before you sequence anything

Two requests often share a core question, even when they look different on the surface.

Two teams each asking about user confusion, one around onboarding and one around a specific feature, aren’t running the same study. But they might both be circling the same underlying question: where do users lose confidence? One well-designed study can sometimes feed both teams. If that’s true, consolidating saves time and both teams get something useful.

Check for overlap before you build the sequence. It changes the math.

Let dependencies set the order

Some questions can’t be answered until another one is. If you need to understand the mental model before you can design a concept test, that sets your order. Research has its own internal logic, and that logic sometimes overrides everything else on your list.

When there’s a dependency, name it explicitly. “I can’t start B until we’ve run A” is a sentence worth saying out loud, in writing, to the team. It makes the sequencing legible and prevents the assumption that everything can happen in parallel.

Prioritization is a conversation, not a solo decision

The biggest mistake I see is researchers managing the queue alone. You make better calls when you’ve talked to the people whose decisions those studies are meant to support. They know what’s being decided and when. You know what it would take to answer the question well. Put those two things together, and the priority usually becomes obvious.

If it doesn’t, that’s worth paying attention to. Sometimes a request isn’t tied to a real decision at all. Sometimes the “urgent” ask is urgent because no one wants to own the answer. That’s useful to surface before you spend time on it.

If you’re working through a research roadmap and not sure where to start, I can help you think through it. Let’s talk.