How to Run a Prioritization Workshop for Your Product Team
Here’s a scenario most product managers know well: you’ve got a backlog with 40 items, five stakeholders with strong opinions, a roadmap review coming up, and no clear consensus on what matters most. The features aren’t the problem. The alignment is. A prioritization workshop is the tool that gets everyone in the same room — or the same Miro board — and turns a noisy set of opinions into a ranked, defensible list your team can actually commit to.
This guide walks you through running a prioritization workshop from start to finish, including a complete agenda template and facilitation tips that work even when stakeholders disagree.
What Is a Prioritization Workshop?
A prioritization workshop is a structured, time-boxed session where product managers, engineers, designers, and key stakeholders work together to evaluate and rank a set of features, initiatives, or backlog items. The goal isn’t to get everyone to like the outcome — it’s to get everyone to understand it and commit to it.
Done well, a prioritization workshop achieves three things at once. It surfaces information that’s currently siloed in different people’s heads. It creates shared context so that disagreements are about data and tradeoffs rather than assumptions. And it produces a ranked output that the team can use to build a roadmap with confidence.
When to Run a Prioritization Workshop
Not every prioritization decision needs a workshop. For routine backlog grooming or tactical sprint decisions, a smaller, lighter process is more appropriate. A prioritization workshop is worth running when:
- You’re doing quarterly planning and need to align on the next 90 days of work
- The backlog has grown significantly and needs to be restructured
- There are competing opinions across multiple stakeholders that haven’t been resolved
- Your team just completed a major discovery phase and has a set of validated opportunities to prioritize
- You’re working on a new product area and haven’t established shared prioritization criteria yet
If any of those situations describe your current state, a prioritization workshop is likely the right tool.
How to Prepare for a Prioritization Workshop
Good facilitation starts before the session begins. Preparation is what separates a productive workshop from a two-hour meeting that ends without a clear output.
Define the scope. What exactly are you prioritizing? A list of features? Epics? Strategic initiatives? Be specific before you invite anyone. The more clearly you define the scope, the easier it is to facilitate the session and the cleaner the output.
Curate the input list. Compile the items to be prioritized and share them with participants ahead of time. Ask people to come with initial impressions. You want people to have done some thinking before they walk in — not to see the list for the first time during the workshop.
Choose your prioritization framework. Decide in advance which framework you’ll use to score or rank items. The most common options for a prioritization workshop are: RICE scoring, MoSCoW, effort/impact mapping, or dot voting. Using the RICE scoring model is particularly effective when you want a quantified output that’s easy to defend. Different frameworks work for different team sizes and decision contexts — pick one and stick with it for the session. If you’re weighing options beyond the workshop itself, our full comparison of backlog prioritization frameworks covers five of them side by side, including where each one tends to break down.
Invite the right people. A prioritization workshop with 15 people is hard to facilitate. Aim for 4–8 participants who represent the key perspectives: product, engineering, design, and the relevant business stakeholder. If you need broader input, gather it before the session through async surveys or individual conversations.
Set up your tools. Whether you’re using Miro, FigJam, a Google Sheet, or a physical whiteboard, have everything ready before the session starts. Losing 15 minutes to tool setup at the start of a 90-minute workshop is a bad trade.
The “curate the input list” lesson tends to get learned the hard way. At a 40-person B2B SaaS company, a quarterly planning workshop for a team of eight — two engineers, a designer, and three business stakeholders alongside the PM and one other — sent the backlog of 35 items out the morning of the session instead of two days ahead. Half the room spent the first twenty minutes silently reading instead of thinking, and the individual scoring round that followed produced almost nothing but shrugs and low-confidence guesses. The team ended up rescheduling the actual scoring for the following day, once everyone had time to sit with the list. One scheduling mistake cost most of a week.
Prioritization Workshop Agenda Template
Here’s a 90-minute agenda that works for most quarterly planning prioritization workshops.
0:00–0:10 — Alignment on goals and criteria (10 minutes) Open with a shared understanding of what you’re prioritizing toward. What’s the product goal for the next quarter? What are the success metrics? What constraints exist (team capacity, dependencies, strategic requirements)? This step is often skipped, which leads to people prioritizing different outcomes throughout the rest of the session.
0:10–0:30 — Individual scoring (20 minutes) Each participant scores the items independently — before any group discussion. This prevents anchoring and groupthink. If you’re using RICE, have everyone fill in their estimates for each dimension. If you’re using dot voting or effort/impact mapping, have each person complete their assessment silently.
0:30–0:55 — Discussion of gaps and outliers (25 minutes) Surface the items where scores diverge most significantly. These are the conversations worth having. Don’t try to discuss every item — focus on the disagreements. Ask people to explain their reasoning. Often the divergence reveals a genuine difference in assumptions (one person thinks Feature X is low effort; the engineer knows it’s not) or values (one stakeholder is optimizing for revenue, another for retention).
0:55–1:10 — Build the consensus ranking (15 minutes) Using the discussion to inform the scores, build an updated ranked list together. If you’re using a scoring framework, average or aggregate the scores. If you’re using dot voting, count the votes. You don’t need unanimous agreement — you need enough shared understanding that the team can commit to the ranking.
1:10–1:20 — Identify dependencies and blockers (10 minutes) Before you close, surface any items on the list that are blocked by something outside the team’s control. Technical dependencies, third-party timelines, resource constraints. These affect how the ranking translates into a roadmap.
1:20–1:30 — Next steps and decisions (10 minutes) Document the output. Who owns it? When will it be incorporated into the roadmap? What decisions were made in the session that need to be communicated to people who weren’t there? Close with clear owners and clear timelines.
Best Prioritization Frameworks to Use in a Workshop
Different situations call for different frameworks. Here’s a quick guide.
RICE Scoring — Best for teams that want a quantified output and have enough data to estimate reach, impact, confidence, and effort. Takes more prep but produces a defensible, ranked list.
Effort/Impact Matrix — Plot items on a 2×2 matrix: low effort/high impact (do first), high effort/high impact (plan carefully), low effort/low impact (do if there’s time), high effort/low impact (avoid). Fast to run, easy to visualize, but less precise.
MoSCoW — Categorize items as Must Have, Should Have, Could Have, or Won’t Have. Good for scoping a release or sprint. Less useful for ranking within a category.
Dot Voting — Give each participant 5–10 dots to allocate across items. Fast, inclusive, and generates immediate buy-in. Can be gamed if participants are strategic, and doesn’t weight items by effort.
Buy a Feature — Give each participant a fictional budget and price each feature. Participants “buy” the features they want most. This is excellent for surfacing real stakeholder preferences and is particularly effective with non-product stakeholders.
In a survey of 55 product managers, Mind the Product found that Weighted Scoring was rated the single most effective framework by 36% of respondents — described as the easiest to communicate to stakeholders and leadership — even though it takes more setup than dot voting or a simple matrix.
Contrary to the popular advice to always start a new team on RICE, the effort/impact matrix tends to work better for a team’s first workshop — it takes ten minutes to explain, produces a visual everyone can argue about immediately, and doesn’t require anyone to defend a made-up confidence percentage they don’t actually believe yet. Graduating to RICE once the team has enough historical data to make the extra precision worth the setup time tends to work better than starting there.
How to Facilitate a Prioritization Workshop
Facilitation is where prioritization workshops succeed or fail. The PM is usually both a participant and the facilitator — which is hard. Here’s how to do it well.
Separate the problem from the solution. When discussion gets stuck on how a feature should work, bring it back: “Let’s focus on whether to include this, not how to build it. We can solve the how in sprint planning.”
Name the pattern when it appears. When you notice groupthink, status deference (junior team members adjusting their scores to match the senior leader’s), or scope creep, name it out loud and reset. “I notice we keep adding items to the list. Let’s agree that for today, we’re only ranking what’s already here.”
Use timeboxing aggressively. Every section of the agenda has a timer. When the timer ends, move forward. The discipline of timeboxing forces decisions and prevents over-discussion of individual items.
Document decisions in real time. Have someone (or a shared doc visible to everyone) capture decisions as they’re made. This reduces end-of-meeting ambiguity and makes the output immediately usable.
Status deference sinks more workshops than any framework choice. At one session, a junior PM’s initial score for a feature was a 3 out of 10; after the VP of Engineering casually said he loved the idea, her second-round score quietly became an 8. Nobody said anything about it, and without someone tracking individual scores across both rounds, it would have gone unnoticed. Naming the pattern the moment it appeared — “let’s make sure we’re scoring against the criteria, not who spoke last” — got her back to something closer to her honest read.
The stakeholder management skills you develop as a PM are directly applicable to facilitation — both require you to understand what people want, surface hidden assumptions, and move toward a decision that people can commit to even when they don’t fully agree. Lenny Rachitsky’s writing on prioritizing a roadmap makes a related point: the hardest part usually isn’t picking a framework, it’s getting people to agree on what “impact” even means before you start scoring against it.
How to Turn Workshop Output Into Roadmap Decisions
A prioritization workshop produces a ranked list. That list is not a roadmap. Converting it requires one more step: mapping the ranked items against capacity, sequencing dependencies, and aligning with strategic timing.
Take your ranked list and work through it in order. For each item: what’s the estimated effort? What team is needed? Are there any dependencies? What quarter or sprint does it realistically land in? This exercise often reveals that your top five items can’t all fit in the next quarter — which means you need to push some to the following quarter and communicate that clearly. If your team tends to blur the line between what’s committed and what’s aspirational, it’s worth revisiting how a roadmap differs from a backlog before you finalize what goes where.
The output is a roadmap draft. Share it with participants within 24 hours of the workshop while the conversation is still fresh. Give stakeholders a short window to flag any significant issues before you treat the output as final.
When you’re doing your next round of sprint planning, the prioritization workshop output is your primary input. The best teams run their prioritization workshops 2–3 weeks before sprint planning so that by the time you’re in planning, the “what” is already decided and the team can focus entirely on “how.” If you’re constantly fielding urgent mid-quarter requests between workshops, that’s usually a sign the underlying habit of prioritizing under pressure needs work, not just the quarterly ritual.
Common Mistakes in Prioritization Workshops
Inviting too many people. Every additional participant increases the facilitation complexity non-linearly. If you need broader stakeholder input, collect it before the session — not during it.
Skipping the independent scoring step. The most valuable moment in a prioritization workshop is the one where individual scores diverge. If you go straight to group discussion, you’ll never surface those divergences — the loudest voice will set the anchor, and everyone else will converge around it.
Prioritizing without criteria. If you haven’t defined what you’re optimizing for at the start of the session, people will prioritize different things the whole way through. Define your strategic goals in the first ten minutes. Everything after depends on it.
Treating the output as final. The ranked list from your workshop is an input to your roadmap, not the roadmap itself. New information, changed constraints, and emerging opportunities will require you to revisit it. A prioritization workshop is a decision-making event, not a contract.
Running a prioritization workshop well is one of the most valuable things a PM can do for their team. It replaces informal, political prioritization with a transparent, evidence-based process that everyone can trust — even when they disagree with the outcome. If your last planning cycle ended in a ranked list nobody quite believed in, don’t wait for the next quarterly deadline to fix it — book a 90-minute session in the next two weeks, run the individual scoring step honestly, and see what actually surfaces.
References:
- Mind the Product — “Prioritisation for Product Managers: Are We Doing It Right?” — mindtheproduct.com
- Lenny Rachitsky — “Prioritizing” — lennysnewsletter.com
- Atlassian — “Prioritization Techniques for Product Teams” — atlassian.com
