Product Prioritization Frameworks Explained

Product Management
September 16, 2022
26 mins read

Prioritisation is one of the most challenging components of Product Management. Being a product manager you might already think you know how to do it if you've moved from another discipline to a product or if you've spent years in an office-based career. 

The role of product manager here is to decide which activity to tackle first, which deadline is the most important, and how to respond to your communications.

Aren't priorities important? Wrong!

Prioritisation is taken to a whole new level in product development! Product managers have got a long list of unimportant features and duties in front of you. The developers assure product managers that Feature A will be fantastic and will propel them forward. 

However, a significant stakeholder has suggested that Feature B be added to W1. Finally, the Data Analyst in the team of product managers has concluded that Feature B is entirely unneeded and that users are clamouring for Feature C.

Who makes the decisions on what is worked on? You - PRODUCT MANAGER!

Prioritisation is critical for product development teams and product teams. It can be challenging to choose the proper high priority. It must, however, be completed for the launch to be successful.

There are multiple product Prioritisation frameworks available to use for a better outcome of any product.

So here are a few pointers with the most important ways that every Product Manager should know about these product Prioritisation matrices.

Product Prioritisation Frameworks - An Overview

While there are a variety of effective prioritisation and product management frameworks, product managers should now be able to utilise any of these to help plan their product roadmap.

Product Prioritisation frameworks are a collection of guidelines for determining what to work on next. They are a scientific method of efficiently prioritising labour. Prioritisation frameworks assist product managers in prioritising work, optimising the workflows of the cross-functional team, and determining whether a project is worthwhile for the entire firm.

Remember that there is an ideal method to prioritise the product, and there is an equally incorrect way to prioritise the product. 

So, all a product manager can do is examine how the team makes decisions today and be open about whether or not some things need to change. Making sure that everyone's voice is heard. To keep the track of the data involved.

Because of shifting priorities, reallocation of resources, and financing scarcity, product managers' most challenging task is prioritising a roadmap without market research. 

This is when frameworks for product Prioritisation come in handy! Prioritising the roadmap in various ways, then describe product managers’ reasoning to share with the rest of the team.

17 Prioritisation Frameworks for Product Managers

1. Kano Model

The Kano model allows product managers to evaluate features from the customer's perspective. According to the model, features are divided into four categories based on their level of enjoyment and functionality.

A 'must-have' feature is one that is required but does not excite customers, regardless of how much work is put into it.

On the other hand, a feature is called 'attractive' when it delights customers yet has no negative consequences when absent from a product.

When 'performance' qualities are present, customer satisfaction rises, but when they are absent, customer unhappiness increases.

Product managers will need to survey clients to determine where the features fall on the Kano chart. Based on the input, the product manager can decide which features to prioritise in the next update.

Kano prioritisation model
Kano Prioritisation Model


  • It indicates a product's possible strengths and disadvantages.
  • You can rank product features from the standpoint of the client.


  • It doesn't go into detail on the resources needed.
  • Kano takes a long time to complete.
  • Customers with no technical background may end up with a wishlist and expectations.

2. Story Mapping

A story map comprises a horizontal axis that represents the user journey and a vertical axis that represents priority. After the product manager has finished the story map, he/she will have a list of features sorted by importance and usage sequence.

Story mapping is a beautiful way to plan out an MVP and keep track of a growing list of features. Features that are higher on the priority list deserve more attention than those lower on the list.

Story mapping prioritisation framework
Story Mapping Prioritisation Framework


  • Story mapping aids in the rapid identification of the MVP.
  • The user's experiences are at the heart of it.
  • It's a joint effort.


  • This strategy does not consider external product priority considerations such as business value and complexity.

3. MoSCoW Analysis

"Must-Have, Should-Have, Could-Have, and Won't Have" is the acronym for "MoSCow." This strategy, in general, allows product managers to categorise their products features into four priority themes, which are:

  • Must-Have: Features that must be there from the start for the product to function properly.
  • Should-Have: Features that aren't necessary but are nevertheless essential to complete.
  • Could-Have: Features that aren't critical or urgent but would be an excellent addition to the overall product.
  • Won't-Have: Features that aren't required right now but could be added in the future.

The MoSCow approach is exceptionally dynamic, and it can assist the product managers' team in developing a solution in a short amount of time.

Moscow prioritiation framework
Moscow Prioritiation Framework


  • The needs of the customer are always first.
  • Team collaboration is made more accessible.
  • Because the notion is so simple, it's pretty intuitive.
  • In new product teams, it's simple to implement.


  • Starting with "must-have," the pecking order might lead to the spilling of "should-have" and "could-have" items.
  • The order does not account for urgency.

4. Opportunity Scoring

The opportunity scoring's approach is to evaluate customer happiness based on the results of distinct features. This is since customers prioritise outcomes rather than the technical execution of features.

To use this strategy, product managers need to make a list of the outcomes of the probable features that will be introduced soon. Customers should give ratings as per the importance of the features and if they are pleased with the current solutions on a scale of 1 to 10.

The characteristics are then displayed on the chart, allowing the product manager to see which ones have a high level of pleasure when first introduced but a low level of satisfaction when used. The void denotes a potential opportunity to be filled by working on the feature.

Opportunity scoring prioritisation framework
Opportunity Scoring Framework


  • It's a quick and easy way to develop creative solutions to common challenges.
  • On a graph, it's simple to see.


  • During the survey, customers may overestimate or underestimate the significance of a feature.

5. Affinity Grouping

Affinity grouping is an informal procedure in which team members brainstorm ideas and opportunities for the product's enhancement. Members can jot down their ideas on paper, sticky notes, or a whiteboard.

After a product manager has written down all of his/her thoughts, he/she can begin grouping them. After that, members vote on the organisations they believe are most significant. Finally, product manager will have a prioritised list of items that can be incorporated into future features.

Affinity grouping prioritisation framework
Affinity Grouping Prioritisation


  • This strategy enables collaboration between departments.
  • The big picture is visible.
  • Organising into groups and subgroups is simple with post-it notes.


  • To get the affinity diagram, you'll have to wait until the end of the conference.
  • A manual search is required to locate a specific note on the affinity diagram.

6. ICE Scoring

"Impact, Confidence, and Ease" is the acronym for ICE in the ICE Scoring Prioritisation model.

Overall, according to these three characteristics, if a product manager wants to assign a numerical score to its features based on how valuable they are.

Product managers can rank these qualities from one to ten in each category, then multiply the numbers to get the ICE score for each feature. In essence, "Influence" refers to how much impact the feature will have concerning the objectives. "Confidence" refers to the company's belief that the feature will have the anticipated impact.

Finally, "Ease" refers to how simple or difficult it will be to achieve the goal.

Ice Scoring Model
Ice Scoring Prioritisation


  • ICE scoring is that it is quick and straightforward. It also prevents product managers from wasting time deciding on your next experiment.
  • A slew of testing concepts will emerge during the research and hypothesis stages of the CRO loop.
  • It values momentum over precision.
  • It will assist a product manager in prioritising tests that are in the 'ballpark' of your goal while reducing expenditures and time spent agonising over your backlog.
  • It's easy to become bogged down in brainstorming, which can stifle progress.


  • Due to different experience levels or other random circumstances, two team members may assign different scores.
  • The same scorer could give various scores to the same or similar tests on different days.
  • Bias and score manipulation could be used to push a specific experiment through.

7. RICE Method

The RICE framework allows a product manager to assess their characteristics based on four criteria:

  • Reach: The number of people who may be affected by the feature over a given time.
  • Impact: How much will the feature affect individual users?
  • Confidence: The company's level of confidence in the feature's impact and reach scores.
  • Effort: The amount of time the company will have to devote to the feature.

Overall, a product manager will use a predetermined method to convert these individual rankings into a general score, which will assist the organisation in better prioritising things.

Rice Scoring Prioritisation Framework
RICE Prioritisation Model

RICE is a grading system created by the Intercom team to aid in the prioritisation of product roadmap concepts. RICE encourages teams to assess their goals regarding available resources, target audience, and return on investment.

Furthermore, RICE stands for Reach, Influence, Confidence, and Effort. Each factor is given a score to identify what would need the most effort, reach the most significant number of people, have the most impact, and how confident we are about all of this.

Multiply (Reach * Impact * Confidence) by the effort to get your RICE score.


  • Product managers must turn product measurements into SMART metrics before quantifying your initiatives. Because RICE relies on numerous metrics to be effectively evaluated, the product managers’ product metrics should be specific, measurable, realistic, relevant, and time-bound.
  • Because it involves estimation effort, effect analysis, and other factors to be determined before development begins, the RICE technique aids in bringing the entire team to an agreement.


  • It's pretty difficult to calculate without specialist spreadsheets or tools to simplify the Scoring.
  • Assumes that the product team working with the product manager already employs SMART metrics.
  • This strategy has a learning curve that may necessitate explaining and conducting trial runs with your team.
  • Because each developer has a varied level of confidence in their ability to complete a task, it can become rather taxing.
  • It's difficult to give a straightforward answer to the question, "What should we develop next?"

8. Weighted Shortest Job First

The WSJF (Weighted Shortest Job First) priority strategy is used to sequence activities (e.g., Features, Capabilities, and Epics) to maximise economic gain. 

Cost of delay calculation

In Scaled Agile Framework (SAFe), WSJF is calculated by dividing the Cost of Delay (CoD) by the work size or length is how a team calculates each initiative's score. The team then ranks the things with the highest scores in order of importance.

Weighted Shortest Job First
Weighted Shortest Job First Prioritisation

The Weighted Shortest Job First approach can be used by any team in an organisation to sequence any effort. 

Product teams can use it to determine which things on the product backlog should be prioritised. Marketing teams can use it to assess which projects or campaigns would provide the best return on investment for the organisation.

When calculating the WSJF, how do you determine value?

However, how should a product manager value hardware development projects? Profit? What is the worth of a customer? What is the brand's impact?

Profit is undoubtedly the most straightforward value statistic to assess objectively, but other metrics might also be helpful.

For hardware product development projects, Donald Reinertsen recommends dividing the cost of delay by the project duration. The essential notion remains the same regardless of how value is calculated.

Let's utilise Reinertsen's approach as a demonstration and example of why WSJF works.

How to calculate cost of delay?

Total COD = Cost of a Lost Month + Cost of a Peak Reduction

To determine the cost of delay, the entire team working with the product manager must first comprehend the product life behaviour, cycles, and the influence of launching late on total profit.

Product managers should look at which projects, or even features, make sense to execute in what order if he/she knows the cost (profit impact) of postponing a project launch and the projected project time.

Why consider WSJF?

Even though WSJF makes perfect sense, it's tough for businesses to ignore the prevalent practice of completing the first work in the queue first. But, if a product manager take the time to look at the facts, it's clear that performing projects in the 'optimal' order would net us a lot more money.

Assigning value (in this case, we used the cost of delay calculation) varies for every organisation. Still, it's worth the time to figure out what value means to the product managers’ company and then work out which activities should be prioritised.


  • This framework requires practices to be done in the sequence
  • Focuses more on the tasks, eventually giving an optimal result


  • It can take much time and keep the work on hold.
  • It can be simultaneously expensive to consider WSJF, but this framework can help product managers bring fruitful results with a proper study.

9. Impact Mapping

Impact mapping is all about impact, as the name implies. What kind of impact do a product manager think it will have? And more importantly, who will be affected? In what way, precisely? Will the product, after all, have any impact? And, perhaps most importantly, why would you as a product manager want to make such an impression in the first place?

Impact maps are hierarchical tree diagrams with many levels that help product managers see the big picture. User or customer personas who can affect the outcome; impacts to generate; deliverables to offer; user stories to transform deliverables into features for implementation

Impact Mapping Framework
Impact Mapping Prioritisation

When is it appropriate to build an impact map?

This approach can be used in a variety of ways. Use it, for example, to review the business strategy and get team on the same page. Just map it out if you as a product manager have doubts regarding impending transformations, new projects, or features.

Product mangers can also use it when they:

Plan the next sprint or release if they don't know what should be in the product or want to show that a specific feature isn't valuable enough to their customer or stakeholders.

What distinguishes impact mapping from other similar techniques?

In contrast to other options, impact maps are very illustrative since they allow product managers to illustrate how their assumptions relate to user demands and corporate goals. It's also simpler to create impact maps. 

Product manager can turn abstract concepts into complete user stories by following the seven stages below:

  • Establish and outline the company's overall objectives.
  • Identify personalities or actors who can assist product manager in achieving their objectives.
  • Define the actions or affects you wish these characters to have.
  • Make a list of deliverables or what you as a product manager can do to motivate people to take action.
  • User stories should be created from deliverables.
  • Estimate the length of these stories.
  • Import your map into your project management application to go live with it.


  • It helps in identifying personas by adding impacts 
  • It helps break deliverables into user stories
  • It gives importance to the users' stories efforts along with the values
  • The impact mapping framework is pretty comprehensive


  • As these frameworks are in the form of hierarchy, it can sometimes be confusing to understand the tree in a single go.
  • One of the most common categories in costs is implementation or development effort.

10. Buy A Feature

Buy a feature is a collaborative product prioritisation exercise that any product manager can do with prospective consumers. Firstly, product manager begin by creating a feature list and assigning a price based on the app development cost.

Each participant is given a specific amount of money and instructed to purchase the desired features. There are no restrictions on the number of features or the amount of money they can spend.

Make a list of the features purchased and the amount, then interview the participant about why they did so. Product manager will be able to determine which characteristics appeal to customers and obtain a deeper grasp of different participants' motivations.

Product manager can use the Buy A Feature strategy with his/her team members or stakeholders in addition to customers to gain a different perspective.


  • It aids in overcoming challenges such as a lengthy wish list and limited development resources.
  • It's a quick and easy process.


  • Only features previously defined in a product roadmap are eligible for this strategy.
  • It necessitates the participation of a group of people, which might be challenging to organise in some cases.

11. Impact/Effort Matrix

Product managers can categorise the features into four quadrants using the impact/effort matrix. As a result, the team can have a clearer picture of how a feature will offer value in the long run.

Consider the influence of the feature on retention, engagement, market demand, customer acquisition, revenue, and other measurable aspects when working with this approach. The entire team working with the product manager determines the values of this model.

Product manager then can conduct a meeting with the team and have members vote on features based on their importance and the work required. After completing the process, the product manger will want to concentrate on features that have a significant impact but involve little effort.

Impact / Effort Matrix Prioritisation
Impact/Effort Matrix Prioritisation


  • A versatile and straightforward technique that can be used right away.
  • It aids the team's concentration.
  • It can be customised to fit the team's needs.


  • It's based on speculation rather than data. Personal bias may be present.
  • This framework gets less efficient as product features develop, especially for large product teams.

12. Weighted Scoring

Weighted Scoring is a step up from the more subjective impact/effort matrix. Product managers can use this model to allocate a percentage of scores to the various costs and advantages.

Product managers will need to specify the criteria that are considered relevant in the forthcoming edition before applying this strategy. Discuss how the weights are assigned to each feature with your team.

After all of the criteria have been scored, the scores are added together, and the characteristics are ranked.

Weighted Scoring Prioritisation Framework Example 1
Weighted Scoring Prioritisation 1
Weighted Scoring Prioritisation Framework Example 2
Weighted Socring Prioritisation 2


  • It allows for prioritisation based on the requirements of various stakeholders.
  • The team can be more objective by using weighted and RICE scoring.
  • These techniques give the product approach legitimacy.


  • Some product strategies may not be linked with Scoring.
  • Weights and ratings can be skewed to favour the preferences of one party over another.
  • It can result in goods that are fragmented and not aligned with their distinct value proposition.

13. Urgent vs. Important Matrix or Eisenhower Matrix

It's one of the most widely used product prioritisation techniques for determining the true priority of each task.

All a product manager has to do now is write down its product objectives and the company's goals, and what he/she needs to do to achieve them. These goals can be updated monthly, quarterly, or annual.

Create a matrix with the Y-axis labelled Important and the X-axis labelled Urgent. It should now be divided into four quadrants, dividing your duties into two categories: urgency and importance.

Urgent vs. Important Matrix or Eisenhower Matrix Framework
Urgent vs. Important Matrix or Eisenhower Matrix

Quadrant 1 = Do

These urgent activities require the team's immediate attention and time. They're both vital and urgent. Product manager should include this in the sprint if specific tasks are grouped together in this quadrant.

Quadrant 2 = Schedule

These activities aren't urgent right now but are critical to do. For instance, writing an email to a customer to obtain product feedback. It's not urgent, and the product manager will inevitably postpone it, but it's critical to gain beneficial ideas.

Quadrant 3 = Delegate

These are the activities that are urgent but not essential for the entire team to complete. Although few activities will fall under this category, if they do, try to delegate as much as possible.

Quadrant 4 - Eliminate

Work that is busy but has no clear influence on the company's or product managers’ goals. Remove these activities from the backlog since they are neither significant nor urgent.

14. Value Vs. Effort matrix

Value versus effort is a prioritisation model in which a product manager can ask his/her team to provide a value and an effort metric for each feature. The measure of effort in this situation is the time it takes to achieve the feature, and the value is the income potential of the feature.

Using the value versus effort method, the team can determine which feature will significantly impact their audience and how much it will cost the organisation. Product manager can also lessen the danger of doing a hard job by combining this with the important/urgent matrix.

Value vs Effort Prioritisation Matrix
Value Vs. Effort Prioritisation

What is the best way to measure value?

When evaluating value, think about how well it aligns with the company's goals and objectives. What kind of added value can it bring to the targeted customers? Here's what a product manager should think about carefully:

Business value 

KPIs and OKRs are the lifeblood of the company, and all of the decisions made by the product manager should be predicated on how much value they add to those goals. For example, your company may have goals to lower turnover or increase click-through rates.

Customer value 

Customers are the most important stakeholders in any company. So, a product manger should think about their pain points and how far he/she can go to alleviate them. Or did they make a feature request on your feature voting board?

What is the most accurate way to measure effort?

Suppose, being a product manager you're attempting to calculate the amount of work required to complete this assignment. Most product teams try to employ a "story point" based system, in which the amount of hours needed is pre-determined by the team's collaboration at the start of the sprint. So, the product manger should factor in developer hours, external service expenses, and external stakeholder risks.


  • It is effortless to utilise and implement across the entire team.
  • It can be used by any product team and is exceptionally versatile without wasting much time.
  • Clear prioritising can make getting buy-in from stakeholders much easier.


  • Sometimes teams misjudge the amount of effort necessary, resulting in spillovers between sprints.
  • Adoption is more difficult in large firms with a large pipeline.
  • Team will need to conduct extensive study to discover the true worth of a feature.

15. H.E.A.R.T

Xin Fu, Hilary Hutchinson, and Kerry Rodden, the Google Research Team members, created the HEART product management framework. The HEART framework is a matrix with steps in the rows and parameters in the columns. The steps are as follows:

  • Happiness: This metric assesses the user's mood.
  • Engagement: How many users utilise your product or interact with your brand regularly?
  • Adoption: This metric tracks how many new users you're gaining.
  • Retention: How many of the users you've acquired are returning?
  • Task Success: How many of the tasks assigned to the user have been done thus far?
HEART prioritisation framework
H.E.A.R.T Prioritisation

The parameters are as follows:

  • Goals: These are the overarching objectives that have been considered in the development of the brand or product.
  • Indications: These are the user signals that show whether the product is on a favourable or unfavourable trajectory.
  • Metrics: These are the formal, quantitative indicators of success that a product manager tracks.

16. Cost vs. Benefit

Every possible project must address two primary factors: the commercial benefit and the cost of implementation. Benefits and costs determine a project's priority (clearly, items with high Benefits and low Costs get higher priority). When prioritising, product managers utilise this formula either intuitively or explicitly.

Customer value, strategic value, income potential, cost reduction, and any other strategic purpose your organisation may have are all examples of benefits.

One of the most common categories in costs is implementation or development effort. You might also wish to consider the influence on ongoing operating expenditures or the risk factor of a project.

Cost vs. Benefit prioritisation
Cost vs. Benefit Prioritisation


  • The clarity in the product roadmap
  • No wastage of funds in the process


  • It can be expensive at times. 
  • Higher risks are involved, but if implementations are taken under consideration well, risks can be minimised.

17. Value vs. Complexity

Value vs. complexity is a methodology for prioritising initiatives based on their intrinsic value and implementation complexity. It's a tool for assessing ideas in terms of their value to users and your business and how difficult they are to implement.

This is one of the models used by product managers to prioritise product roadmap initiatives. It provides a consistent method of decision-making. It will help you be more deliberate about which activities to focus on, especially if you only have limited time or resources.

Value vs. Complexity Prioritisation Framework
Value vs. Complexity Prioritisation

How to Prioritise Using the Value vs. Complexity Methodology

The value vs. complexity matrix has four quadrants that establish categories into which initiatives are placed. The goal is to find low-hanging fruits, to begin with. Let's have a look at how this structure might help the product manager prioritise.

1. Assign value scores 

Make a value score for each initiative after you've made a list of them.

When determining a score, many elements may be taken into account. So, here the product manager should think about value from multiple angles - at the very least, yours and your users'. For instance, how will a project assist your company? What pain issues does it address for your target audience? How many of the target consumers will be affected by the initiative?

Each of the criteria that influence value is given a score. After that, total everything up to receive a single overall score. You might choose to give some subcategories more weight than others.

2. Calculate complexity scores

Next, assign a score to each of your initiatives to determine how challenging it will be to implement. Complexity is simply captured as a cost by specific product teams. The paradigm is nearly identical to the Value vs. Cost framework in this situation.

Other considerations may be taken into account when calculating a difficulty score. Time or development hours, dangers, skill limits, and necessary customer support or training are only a few of them. These can be used to create subcategories that impact an initiative's total score.

3. Make a plan for your initiatives

Plot each initiative in a graph using the calculated value and complexity scores. There should be four boxes in the matrix. 

The following types of initiatives can be found by plotting "Value" on the Y-axis and "Complexity" on the X-axis:

  • High value, low complexity (top-left) – The efforts that should be given the utmost priority are listed here.
  • High value, high complexity (top-right) — If the high complexity isn't overpowering, these projects may be evaluated after those in the first group.
  • Low value, low complexity (bottom left) – These projects aren't precious, but they're worth considering because they're simple to implement and could increase consumer happiness.
  • Low value, high complexity (bottom-right) – It's possible that you'd be better off abandoning the projects at this point.


  • For quick prioritisation, it's easy to use. 
  • Can identify "Easy victories" with "high value" but "low complexity," as well as more important things with "high value," which may indicate that the item should be broken down into smaller value increments.


  • While the term "value" is easier to justify on a Likert scale (1 to 5) based on relative value, the term "complexity" can refer to a variety of things, so it's essential to make sure your team agrees on a definition before scoring.

Choose the Right Product Prioritisation Framework

It's all about asking why when it comes to product management. Why does a user claim that they require a specific feature? Why are users unable to execute a workflow with ease? Why are users apprehensive about pressing the "launch" button?

Product manager won't be able to fulfil all of its users' requests. So, the product manager must comprehend the fundamental requirements.

Prioritisation is the same way. Product manager can't just pick a product prioritisation strategy without understanding why some strategies are better than others in different scenarios.

Let's take a different approach. 

To choose which priority framework is ideal for the product manager and its product, A product manager should ask himself/herself the following questions. Then we'll look into how each approach works.

1. Are you attempting to prioritise problems to solve (rather than features to create)?

Value vs. Effort Matrix

You as a product manager may not clearly know what features you want to build in the early phases of prioritising your roadmap. At this point, concentrate on the high-level issues that need to be addressed rather than the specific solutions. 

2. Are you hunting for a simple (but effective) strategy to first decide which features to work on?

RICE Scoring

You as a product manager can start drilling down on whatever features you want to emphasise once you've gotten through the problem stage. Now that we have a better idea of what you're going to develop, we can break down the variables in the equation a little further.

RICE Scoring is best for a quick and dirty way to prioritise features.

3. Is your entire user base made up of a single user persona, and you're seeking a simple approach?

ICE Scoring

If you as a product manager is still not convinced after reading about the relevance of Reach in the RICE section, Reach likely has little impact on your computations. 

If most of your users are essentially the same, this may be accurate. Maybe your product isn't very big. Thus you don't have much room for multiple user personas. 

Or perhaps you've effectively targeted your product at a specific user persona and achieved product-market fit with that user group, so you don't think about the rest. You claim that Reach does not apply to you for whatever reason. 

4. Is it difficult to predict how helpful a feature will be, necessitating the addition of extra input signals?

Weighted Scoring 

It's not always straightforward to figure out a feature's magic Impact number. Is Feature A truly superior to Feature B in terms of utility? 

It's difficult to discern, especially when the features are so dissimilar and cover so many different aspects of the product. In cases like these, breaking down the question into all of the aspects that are crucial to your product or business will help you determine how vital each feature is. 

And, because each factor isn't always more significant than the next, you'll want to balance them out. Weighted Scoring is a suitable moniker for this method.

Weighted Scoring effectively allows you to widen out the "I" in RICE to assist you in determining the value of a certain feature. 

5. Are you far enough ahead in your product's development that you can fully concentrate on satisfying your users?

Kano's Model

You as a product manager should have probably been hammered with the concept of delighting your users at this point. But be careful: if you haven't addressed their basic needs, you won't be able to skip to the "pleasure" step.

It's impossible to talk about product prioritising without mentioning the Kano Model. The difficulty is that most articles simply outline what everything means (which is difficult), but they rarely explain how to apply it for Prioritisation (you know, the whole point). Having said that, if you can achieve those basic requirements, you're ready for the Kano Model.

In a nutshell, you should strive to delight your customers. They should not be duped into becoming your users. 

6. Are you attempting to determine whether portions of a feature belong in the MVP or MLP?

MoSCoW Method 

Here the product manager still needs to figure out all the details of what problems it will tackle at a more advanced level once you've decided which feature to work on. Even though the product manager might have grandiose plans for all the features he/she can achieve, but only if you have so much money and time. As the PM, you must decide where the line should be drawn.

Use the MoSCoW Method to answer those questions.

Summing Up!

There's so much information out there that it's difficult to find what's suitable for each individual scenario. There are no right or wrong answers. Therefore, product managers must take chances. Product managers should have the necessary data to make each decision, but the best way is to communicate effectively with your team and users, resulting in significant synergy.

Each tool is built with a specific goal in mind: to solve a particular problem. However, not everything has been found yet. Product teams must continue to look, research, read, and experiment with new frameworks, possibly combining the best of each to create their own feature and product Prioritisation framework. 

After all, each product, team, and even consumer is a mini-universe in and of itself. Embracing the prioritisation process is the best method to bring order to a product's natural chaos.

Like the article? Share it with your friends!

Join 5000+ product managers

Subscribe to get our weekly product newsletter and helpful resources right into your inbox.