How to Properly Conduct Prioritization Workshops with Your Team

A Prioritization Workshop breaks this pattern. It's collaborative, method-driven, and focused on team alignment. Instead of an informal discussion, there are clear evaluation criteria, a facilitated structure, and an outcome that all participants support – because they developed it together.

In the UX process, this format typically follows Discovery and Empathy. User insights are available, problem spaces are understood, and now it's about building the right things first.

Read now: An overview of the most important UX Workshop formats

What exactly you can expect in this article: When a Prioritization Workshop makes sense and when it doesn't, which three methods form the core, how to prepare and facilitate the workshop, and what specifically constitutes a good outcome.

‍

Key takeaways at a glance

Prioritization Workshops help teams to jointly evaluate features based on defined criteria. The decision is based on data and user insights, not hierarchy or gut feeling.

Three methods form the core:

• MoSCoW: For quick scope alignment. Features are categorized into Must Have, Should Have, Could Have, and Won't Have. Ideal for MVP scoping and sprint planning.
• RICE: For data-driven evaluation. RICE evaluates features based on four factors: Reach, Impact, Confidence, and Effort. The calculated score makes priorities comparable and transparent.
• Kano Model - For user-centric feature differentiation. The Kano model prioritizes features based on the degree to which they are likely to satisfy customers. It distinguishes between basic needs, performance features, and delight features.

The actual goal of a Prioritization Workshop is less about the method itself. It's the shared understanding within the team about why certain features take precedence, combined with the ability to justify this decision to stakeholders.

A Prioritization Workshop is particularly effective after a discovery or empathy phase, before sprint planning, or for roadmap decisions involving multiple stakeholders.

‍

Why prioritization alone doesn't work

In most teams, prioritization is either a solitary decision or an informal discussion where arguments and opinions clash without structure. Neither approach creates true alignment.

The phenomenon even has a name: the HiPPO effect, or Highest Paid Person's Opinion. It describes the tendency for the highest-ranking or best-paid person in the room to disproportionately influence decisions. This becomes a problem when that person overrides data-driven insights or the expertise of product teams.

The consequence for the product is predictable: user research and market analyses provide clear indications of the right direction, but are often ignored in favor of HiPPOs' pet features. The more frequently decisions are made by HiPPOs, the less likely customer-facing teams are to contribute to planning, and the further the company moves away from its users' actual problems.

A prioritization workshop solves this problem because it makes decision criteria visible and negotiable for everyone. The method is transparent, the evaluation is comprehensible, and the outcome is developed collaboratively.

When a Prioritization Workshop is Useful

Not everything needs to be decided in a prioritization workshop. Here are the most common use cases:

• Before sprint planning with a full backlog: If the team has to select the next ten items from 40 or more entries, it needs more than just a discussion.
• After completing a discovery or empathy phase: The insights are available, user problems are understood. Now it's about deciding which solutions to build first.
• For roadmap decisions involving multiple stakeholders: When different departments have different priorities, a workshop creates a common basis for evaluation.
• For MVP scoping: What must the first version be able to do? And what can wait? A prioritization workshop prevents the MVP from being bloated into a full product.

Equally important is the distinction: If no user insights are available yet, a prioritization workshop is the wrong tool. Prioritization without user knowledge only sorts internal assumptions. In this case, a Discovery Workshop or an Empathy Workshop is useful. Afterwards, meaningful prioritization can take place.

To place the prioritization workshop within the overall landscape of UX workshop formats , the following overview helps:

‍

The sequence is not a rigid process, but a proven logic: First understand (Discovery, Empathy), then think solution-oriented (Design Studio), then prioritize, then evaluate. Each format builds on the previous one.

The three most important methods for Prioritization Workshops

No method is universally better. The choice depends on the context: available data, team size, time horizon, and stakeholder composition. The following overview shows which method best suits which scenario:

MoSCoW for quick scope alignment within the team

MoSCoW stands for four categories:

1. Must Have (without which it won't work)
2. Should Have (important, but not critical for launch)
3. Could Have (nice-to-have, if capacity allows)
4. Won't Have (intentionally omitted)

The method is easy to explain, quick to apply, and works particularly well with groups involving many non-technical stakeholders.

Typical use cases include MVP scoping and sprint planning, i.e., anywhere a common scope needs to be quickly defined.

The most common pitfall: If everything becomes a "Must Have", the method loses its value. The solution is simple, yet crucial: Before categorization, define a clear capacity limit. If the team knows that a maximum of 30% of items can be "Must Have", it forces genuine decisions.

A practical tip that has proven effective: Use dot-voting as a preliminary step. Before the team categorizes, each person votes with a limited number of points for the features they consider most important. This creates a general impression and makes subsequent discussions more productive.

RICE for data-driven prioritization

The RICE framework was developed by the product team at Intercom to improve internal decision-making processes. The formula consists of four factors:

• Reach: How many users will be affected by this feature? Reach is defined as the number of people a particular product initiative affects within a specific timeframe.
• Impact: How big is the effect on the individual user? Impact is difficult to measure precisely, so a scale is used: 3 for "massive impact", 2 for "high", 1 for "medium", 0.5 for "low", and 0.25 for "minimal".
• Confidence: How confident are we in our estimates? To temper enthusiasm for exciting but unclear ideas, confidence in one's own estimates is factored in. If a project could have enormous impact but lacks supporting data, the Confidence score allows this to be managed.
• Effort: How much effort is required? Effort is estimated as the total time a project requires from all team members: Product, Design, and Engineering. Effort is measured in "person-months".

The formula: Score = (Reach × Impact × Confidence) / Effort

RICE is particularly strong for large feature lists, when stakeholders need a comprehensible justification, and for technically savvy teams. Among product management frameworks, the RICE framework stands out for its simplicity, scalability, and effectiveness.

The typical pitfall: RICE scores without real data are opinions with numbers. Teams sometimes get stuck trying to be too precise. The RICE framework is intended as a relative scoring system, not an exact science.

A practical tip that works well in workshops: Different roles estimate different factors. Developers assess Effort most accurately, Product Managers assess Reach, UX Research assesses Impact. When each role contributes the factor in which they have the highest expertise, the score becomes more reliable.

Kano Model - User-Centric Feature Differentiation

The Kano Model has its roots in the work of Dr. Noriaki Kano, a Japanese professor of quality management at Tokyo University of Science. It was published in 1984. The core idea: The model is based on the principle that not all product features have the same impact on customer satisfaction.

The Kano Model distinguishes five categories:

• Must-Be (Basic Requirements): Must-be features are the basics. Customers expect these things without having to ask for them. If they are missing, dissatisfaction arises. Their presence is taken for granted.
• Performance (Linear): Features that provide a proportional increase in customer satisfaction the more is invested in them. More investment = more satisfaction.
• Attractive (Delighters): Excitement features that users don't expect. If they are missing, no dissatisfaction arises. If they are present, they generate genuine delight.
• Indifferent: Features users don't care about. Neither satisfaction nor dissatisfaction.
• Reverse: Features some customers actively dislike. Including them can decrease satisfaction or worsen the experience.

The particular strength of the Kano model: It brings the user perspective directly into the workshop and prevents teams from only building basic features and neglecting "delighters." What is a delighter today often becomes a performance expectation tomorrow and later a basic requirement. This awareness of the dynamic nature of user expectations is valuable for product decisions.

Kano is particularly effective after user research or an Empathy Workshop, when it comes to distinguishing between "what users expect" and "what delights them."

A practical combination tip: Kano for categorization in the discovery phase, RICE for scoring individual features, MoSCoW for final scope definition. This combination provides teams with the most complete decision-making basis and covers both the user and business perspectives.

‍

Preparing and facilitating a Prioritization Workshop

A good Prioritization Workshop requires preparation. Anyone who spontaneously opens the backlog and says, "Let's prioritize," will end up in precisely the kind of discussions the format is meant to prevent.

The typical process in four steps:

1. Check-in and define the goal: What should be the outcome of the workshop? A prioritized feature list? A scope for the MVP? A decision between three roadmap variants? The goal determines the method.
2. Clean up the backlog: Remove duplicates, clarify vague entries, delete outdated items. This step ideally happens before the workshop.
3. Apply the method: MoSCoW, RICE, Kano, or a combination. The method should be explained to the team beforehand so that workshop time is used for the actual work.
4. Document results and define next steps - Who does what by when? How will the outcome feed into sprint planning or the roadmap?

Remote vs. In-person

Prioritization workshops work in both settings. For remote sessions, tools like Miro or Mural help create a shared board. Key things to pay attention to: synchronous discussion instead of asynchronous comments, a clear timebox for each step, and facilitation that actively ensures everyone gets a chance to speak.

‍

The Outcome of a Successful Prioritization Workshop

What a successful workshop specifically produces: A prioritized feature list with clear justifications. A shared team understanding of the decision criteria. And a solid foundation for the next sprint planning or roadmap.

The difference from a classic prioritization round lies not in the output, but in the buy-in. When the entire team knows the evaluation criteria, understands the data basis, and has helped shape the process, they collectively own the outcome. The decision is not a top-down directive, but a collaboratively achieved result. This reduces resistance during implementation and prevents someone from asking three weeks later:

"Why are we building this, anyway?"

The next steps after the workshop are just as important as the workshop itself:

• Integrate results into sprint planning: The top items from the workshop are directly pulled into the next sprint. The justifications remain documented.
• Update roadmap: The workshop outcome forms the basis for the roadmap for the coming weeks or months. Stakeholders who did not participate in the workshop receive a brief summary.
• Schedule regularly: Prioritization is not a one-time event. Depending on the product phase, a prioritization workshop every four to eight weeks is beneficial.

Where a Critique Workshop can be useful as a next step: If, after the prioritization workshop, designs or prototypes for the top-prioritized features are created, a Critique Workshop helps to collectively evaluate and improve them before they go into development.

‍

Conclusion

A prioritization workshop transforms a round of opinions into a structured decision, protects the product from HiPPO dynamics, and the backlog from endless growth.

Three concrete next steps:

1. Prepare and refine your backlog: Remove duplicates, clarify vague entries, and delete outdated items. A clean backlog is essential for a productive workshop.
2. Choose the method based on context. No data available? MoSCoW. Quantitative data available? RICE. User feedback available? Kano. If you're unsure, combine them.
3. Schedule the first workshop session with a cross-functional team. Product Owner, UX, Development, one to two stakeholders. Half a day is sufficient to start.

Do you want to find out which workshop format would be most beneficial for your team right now?

Schedule a free initial consultation with Victoria.

Together, we will determine where you are in the process and which format offers the most impact. An overview of all five UX workshop formats can be found in the Hub article.

‍