The Ultimate Guide to Product Management Prioritization FrameworksDeciding what to build (or what to build next) is one of the most critical parts of a product manager’s job. You only get so many chances to make an impact. So it’s vital to choose wisely and make the most of your window of opportunity.
There are many factors to consider when setting priorities for your product. But first and foremost, you must prioritize solving real customer problems. All too often, organizations don’t stick to this central tenet of product development—possibly because you’re prioritizing innovation above value. We all want others to see us as cutting-edge trailblazers, but that’s not always what the market is clamoring for.
Sometimes they just want moderate improvements on things that are already functional. Instead of chasing after the ultimate gamechanger, it’s better to prioritize spending resources on removing friction points and making things a little easier.
What’s prioritized for version 1.0 of the product?
Narrowing down what’s required for the initial version of a product can be tricky. Since there’s no track record to look back at or current users to talk to, there’s plenty of room for opinions to dominate whatever data you have.
Do you try to wow people with something snazzy? Do you pack it with features so it can appeal to a broader audience? Or do you make sure it does one thing well?
Minimum Viable Products (MVPs) must solve a real problem for the user. Without that, there’s no point in even bothering. Therefore, you must find the subset of possible features that will accomplish that goal. This process requires research and understanding of the potential users as much as possible to be sure it’s solving that problem. It’s a huge bonus if it also delights the customer, but without solving any problems, it’s pretty hard to delight them for long.
If you find yourself with too many priorities, you need to pare things back. Only try to solve the essential problem with the minimum amount of effort. If you try to do too much all at once, you’re doing a disservice to your customers, your team, and your stakeholders.
So apply a laser-like focus on doing one thing well, then use your roadmap to show how you’ll build on it in the future. It appeases those who think you’re “missing” things if they’re not in the MVP while showing a nascent product vision that can be fleshed out based on the initial product’s reception.
How to balance feedback with real product needs
Input from customers, partners, stakeholders, and advisors is a gift. It offers product managers insight into what people value, what they dislike, and what they want. But all of it needs to be taken with a grain of salt.
Imagine asking a toddler what they want. Is that the same thing as what they need? Of course not. Similarly, customers don’t always know how to express exactly what they want.
Customers have problems, and they’re quick to tell you the solution to their problem. But they’re only seeing things from a limited perspective and bring their baggage, preferences, and small sample size of experiences to the table. Since products ideally have lots of customers, products need to create solutions that serve the needs of lots of people. That’s why a reactive approach to prioritization is the wrong way to pick things.
It’s not that feedback offers no value, but it should be informative rather than prescriptive. Prioritization should be rooted in taking proactive action to execute the product strategy. If you’re always reacting to everything that comes across your desk, it leads to a scattershot approach of putting out fires. It prevents you from advancing the product toward the agreed-upon vision. Tune into our webinar below to learn more about supercharging your product roadmap with customer feedback.
Luckily there are a variety of prioritization frameworks and approaches that allow strategic thinking to guide the ship. By adhering to agreed-upon rules and objectives, product teams can rise above arguing about the merits of an individual feature and instead place things in the broader strategic context.
Deciding what to build (or what to build next) is one of the most critical parts of a product manager’s job. You only get so many chances to make an impact. So it’s vital to choose wisely and make the most of your window of opportunity.
There are many factors to consider when setting priorities for your product. But first and foremost, you must prioritize solving real customer problems. All too often, organizations don’t stick to this central tenet of product development—possibly because you’re prioritizing innovation above value. We all want others to see us as cutting-edge trailblazers, but that’s not always what the market is clamoring for.
Sometimes they just want moderate improvements on things that are already functional. Instead of chasing after the ultimate gamechanger, it’s better to prioritize spending resources on removing friction points and making things a little easier.
What’s prioritized for version 1.0 of the product?
Narrowing down what’s required for the initial version of a product can be tricky. Since there’s no track record to look back at or current users to talk to, there’s plenty of room for opinions to dominate whatever data you have.
Do you try to wow people with something snazzy? Do you pack it with features so it can appeal to a broader audience? Or do you make sure it does one thing well?
Minimum Viable Products (MVPs) must solve a real problem for the user. Without that, there’s no point in even bothering. Therefore, you must find the subset of possible features that will accomplish that goal. This process requires research and understanding of the potential users as much as possible to be sure it’s solving that problem. It’s a huge bonus if it also delights the customer, but without solving any problems, it’s pretty hard to delight them for long.
If you find yourself with too many priorities, you need to pare things back. Only try to solve the essential problem with the minimum amount of effort. If you try to do too much all at once, you’re doing a disservice to your customers, your team, and your stakeholders.
So apply a laser-like focus on doing one thing well, then use your roadmap to show how you’ll build on it in the future. It appeases those who think you’re “missing” things if they’re not in the MVP while showing a nascent product vision that can be fleshed out based on the initial product’s reception.
How to balance feedback with real product needs
Input from customers, partners, stakeholders, and advisors is a gift. It offers product managers insight into what people value, what they dislike, and what they want. But all of it needs to be taken with a grain of salt.
Imagine asking a toddler what they want. Is that the same thing as what they need? Of course not. Similarly, customers don’t always know how to express exactly what they want.
Customers have problems, and they’re quick to tell you the solution to their problem. But they’re only seeing things from a limited perspective and bring their baggage, preferences, and small sample size of experiences to the table. Since products ideally have lots of customers, products need to create solutions that serve the needs of lots of people. That’s why a reactive approach to prioritization is the wrong way to pick things.
It’s not that feedback offers no value, but it should be informative rather than prescriptive. Prioritization should be rooted in taking proactive action to execute the product strategy. If you’re always reacting to everything that comes across your desk, it leads to a scattershot approach of putting out fires. It prevents you from advancing the product toward the agreed-upon vision. Tune into our webinar below to learn more about supercharging your product roadmap with customer feedback.
Luckily there are a variety of prioritization frameworks and approaches that allow strategic thinking to guide the ship. By adhering to agreed-upon rules and objectives, product teams can rise above arguing about the merits of an individual feature and instead place things in the broader strategic context.
37 Frameworks to Help You Become a Better Product ManagerAs a product manager (PM), how do you decide what to work on next? How do you determine if an initiative is worth pursuing in the first place? In most cases, nobody is going to hand you a written plan guiding you step-by-step to complete your initiative. That’s why you have to learn to prioritize your work, optimize your cross-functional team’s workflows, and know-how to quickly assess whether or not an initiative is worth your company’s time and budget.
We’ve compiled dozens of proven product management frameworks to help you do just that.
Prioritization Frameworks
1. Value vs. Complexity
The value vs. complexity framework gives product teams an objective way to determine which initiatives (features, bug fixes, etc.) to prioritize on the roadmap. The team then scores each action according to how much value it will bring to the product and its level of difficulty to implement.
The value vs. complexity framework is built on a prioritization matrix, like the one shown here.
2. Benefit vs. Cost (Weighted Scoring)
Product managers use the weighted scoring prioritization framework to rank initiatives according to common cost-vs.-benefit criteria. The team creates scores for each criterion: “increase revenue” under benefits, for example, and “implementation effort” under costs. The team can generate higher overall scores for those criteria it deems more significant than others.
The screenshot here shows an example of a team using six scoring criteria—three benefits, three costs—on which to rank the relative strategic value of seven competing product initiatives.
3. Kano
The Kano model helps product teams prioritize their work according to which features are most likely to delight customers. The team will rank each initiative according to its likelihood to please customers as well as its implementation cost. After, prioritize the features rated high delight and low cost.
4. Buy-a-Feature
The buy-a-feature prioritization framework gives organizations a fun way to prioritize work on products or other initiatives. The model works by creating prices for each competing action on your list, giving a group of participants a hypothetical sum of money to spend, and asking them to buy those features they’d most like to see built.
5. Opportunity Scoring
Opportunity scoring helps product teams determine which features their customers deem essential to the product but also find disappointing. Teams ask customers to rank the importance of several product features and then rate how happy they are with each feature. Features scoring high in importance but low in satisfaction represent the opportunity to realize a strong return on investment for the development work needed to improve them.
6. Affinity Grouping
The affinity grouping is designed as an informal and collaborative framework for prioritization. Each participant comes up with ideas to improve the product and places them on note cards or a whiteboard. Participants will then organize these opportunities into significant themes—the affinity groups—and vote on how to prioritize each of the possibilities under each group.
7. Story Mapping
The story mapping framework gives product managers a visual and holistic sense of how each user story contributes to the overall product experience. The team uses a large board, or a wall, to create a visual walkthrough of the user’s interaction with the product, first identifying the significant steps involved and then adding individual stories beneath them. When the map is complete, the team has a logical view of the user experience and can then determine which stories are a high priority and which are low.
8. Eisenhower Matrix
The Eisenhower Matrix can help teams improve their prioritization, productivity, and decision making. Named after a method used by President Dwight Eisenhower, this framework involves drawing four squares, two on top of the other. You’ll label the x-axis Urgent and Not Urgent, and for the y-axis, you’ll use Important and Not Important. This framework gives you four possibilities: from Important and Urgent, to Unimportant and Not Urgent. Once you’ve placed the initiatives on your list into one of these four boxes, you’ll know which to work on first—those in the upper-left quadrant, Important and Urgent.
9. ICE Scoring
Using the ICE scoring model, product managers can quickly weigh competing initiatives by assigning each a score based on three criteria: impact, confidence, and ease. ICE scoring is designed to help product teams promptly decide which projects to take on so they can start work as soon as possible. But it is not as rigorous as other frameworks, such as weighted scoring.
10. Impact Mapping
Using the impact mapping prioritization framework, product managers focus first on their high-level strategic goals. The PM then works outward from there, determining the relevant actors who will be involved (including the users themselves), how each actor can contribute to the goal, and what the final output will be when you’ve succeeded.
11. MoSCoW Analysis
The MoSCoW prioritization framework helps teams manage requirements and is commonly used to help stakeholders understand the importance of initiatives in a specific release. Group initiatives into four categories, which make up the acronym: M represents the “must-have” items; S is the “should-haves;” C is the “could-haves” (or nice-to-have initiatives), and W represents the “will not have” items deemed low priority.
12. RICE Scoring
The RICE scoring framework helps product teams prioritize items on a product roadmap by scoring them according to four criteria: reach, impact, confidence, and effort. When the team combines its total scores for all initiatives across all four criteria, each initiative will have a single score to weigh its relative value to the product and the organization.
Agile Product Management Frameworks
13. Crystal Agile Framework
A direct outgrowth of the Agile Manifesto for software development, the Crystal Agile Framework method is a human-centered agile framework. That is, it is designed to give teams the freedom to develop and improve their workflows. Although this framework allows each team to find the right methodology to fit its needs and circumstances, it can also lead to confusion and even scope creep.
14. Disciplined Agile
Disciplined Agile (DA) is similar to the Crystal method in that it allows individuals and teams to find their preferred workflow methods. But it does offer some lightweight guidance for how these teams should work, pulling best practices from other methodologies such as Scrum and Kanban.
15. Dual-Track Agile
With the dual-track agile approach, a cross-functional team breaks its work into two categories: discovery and delivery. The discovery track focuses on quickly generating validated product ideas. Delivery focuses on turning those ideas into market-ready products.
16. Dynamic Systems Development Method (DSDM)
The dynamic systems development method (DSDM) evaluates how a project’s lifecycle—from conception to completion—will impact the business. The framework evaluates each project according to four criteria: feasibility and business study, functional model and prototype iteration, design and build iteration, and implementation. The DSDM model states that “any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.”
17. eXtreme Programming
One of the most popular agile frameworks, eXtreme programming, is designed to help software companies deal effectively with dynamically changing requirements. It can also help companies deliver successful products to users with regularly changing needs or who cannot effectively articulate what they want. This framework uses a small development team and leverages automated unit and functional tests. When using eXtreme programming, it is crucial to keep in mind that the framework requires developers to work closely with managers and customers.
18. Feature-Driven Development (FDD)
Feature-driven development is an agile framework used primarily by large companies because it is a top-down decision-making framework that requires a hierarchy of personnel. The FDD model organizes the team’s work around making progress on features, which in the context of this framework could also include user stories.
19. Lean Software Development
Originally called the Toyota Production System (for the company that originated the framework), Lean Software Development model focuses on eliminating from development everything but what the product needs. It is also sometimes called the Minimum Viable Product (MVP) strategy, because the team’s goal is to deliver a bare-bones product to its users, then use their feedback to improve the offering.
20. Rapid Application Development
The Rapid Application Development (RAD) agile framework is used to rapidly generate prototype versions of software products and release them to the market for feedback. The team then uses this feedback to improve the product, release the new version, and continue the cycle. The RAD framework consists of the following stages: requirements planning, user design, rapid construction, and cutover.
21. Scaled Agile Framework (SAFe)
A widely used methodology in large enterprises, the scaled agile framework (SAFe) is designed to protect against the common challenges large companies face as their agile teams scale up. This top-down decision-making framework focuses on three aspects of development: team, program, and portfolio.
UX/Design Frameworks
It’s also helpful to know how your UX and design teams use frameworks to prioritize.
22. Design Thinking
Design thinking is a framework to help inspire innovation by viewing everything from the user’s point of view. IDEO, the company often credited with creating this framework, says design thinking is a human-centered approach to building products.
23. CIRCLES
The CIRCLES Method is a product design framework based on following a specific path and answering the right questions to fully understand what you need to design and why. The stages of the process form the acronym. Comprehend the situation. Identify the customer. Report the customer’s needs. Cut through prioritization. List solutions. Evaluate trade-offs. Summarize your recommendation.
24. The User Is Drunk
In UX and web design, this framework asks a simple question. Is your site or app easy and intuitive enough that even a drunk person could use it?
25. KEY Design Process
As UXPlanet explains, the KEY design process is a two-part strategy to help designers manage their work. The two parts are the opportunity segment and the solution segment. The object of this adaptable guideline is to give designers an ongoing reminder to consider the context, understand users, and validate their theories before moving on to development.
26. Kennedy Principle
This design principle takes its name from the most famous line in President John F. Kennedy’s 1961 inaugural address: “Ask not what your country can do for you—ask what you can do for your country.” The Kennedy design principle is to ask not what your user can do for you but what you can do for your user. The idea is, your user has a finite amount of time and patience, so do not waste any of either by making them perform tasks your app could automate for them. One example would be designing a form that asks first for the user’s US ZIP code, and then in a separate field asks them to input their state of residence. Your code should perform that second task for the user.
More Product Management Frameworks
27. DACI
DACI is a decision-making framework named for the four roles it covers. There is the driver (who drives the decision), the approver (who makes the decision), contributors (who help with the project), and the informed (the people whose work could be impacted by the project).
28. GIST Planning
A product-planning framework, GIST is designed to help reduce management overhead, speed development, and deliver successful products. The name stands for the key pillars of the approach: goals, ideas, step-projects, and tasks.
29. Jobs to Be Done (JTBD)
Like design thinking, the jobs to be done framework is designed to change the team’s focus from the product to the customer. This approach helps a product team learn what its customers want to do when they buy a product or service, so the company can focus its development on satisfying those needs.
30. Quality Function Deployment
Quality Function Deployment (QFD) is a popularized 50-year-old methodology for product development and production. Build the approach around listening to customers and incorporating their voice into the team’s plans. The QFD framework translates customers’ desires, needs, and expectations into technical requirements for the product’s development. The idea is to take the customer’s voice into every stage of production throughout the product’s lifecycle.
31. SWOT Analysis
SWOT analysis is a planning and decision-making framework that a company can use to determine whether or not to begin any strategic initiative—building a new product, for example, or entering a new market. The method works by breaking down any initiative into its strengths, weaknesses, opportunities, and threats. The team then evaluates the project’s value and risk-based on each of these criteria before deciding whether or not to move forward.
The SWOT matrix is a simple, two-by-two grid like the one shown here. It should include boxes labeled strengths, weaknesses, opportunities, and threats.
32. Classical Economics
Classical economics is the school made famous by thinkers such as Adam Smith, who argued for free markets and believed rational actors working in their interests would create increased levels of prosperity for everyone. When you take a classical-economics approach to product management, you apply these broad, macroeconomic principles to your market. You assume your customers will behave rationally and make reasoned decisions when it comes to choosing which products to buy.
33. Behavioral Economics
The behavioral-economics framework in product management takes a different view of your user base. This view is the approach that argues for appealing to people’s emotions—using pricing strategies such as anchoring to enable you to charge more for your offering. Contrary to the classical-economics framework, this approach views people not as rational actors but as emotion-driven actors.
34. HEART Framework
Google created the HEART framework to bring quantitative metrics to the “touchy-feely” world of UX. This flexible methodology allows designers to quantify either specific features or the entire user experience according to five metrics. Those are happiness, engagement, adoption, retention, and task success.
The genesis of this framework was the typical UX team’s inability to turn all the available data into actionable intelligence. Using HEART, they could define measurable user experience goals and bring the data-driven decision making to an area of product development that typically doesn’t rely on measurables to drive their designs.
But there’s no reason to limit HEART to UX—product managers can apply the same principles to every aspect of their product. It’s a nice deep-dive into customer delight and satisfaction that many of the other frameworks only cover cursorily.
35. AARRR
Explicitly designed for startups, AARRR is a five-step framework to help young businesses grow. Developed by venture capitalist Dave McClure, the acronym forms those five key metrics McClure believes every startup should focus on. They are acquisition, activation (referring to the user’s first product experience), retention, referral, and revenue.
36. The 4 Ds (Do’s, Defer, Delegate, Dump)
The 4 Ds is a time-management framework. It describes the four options you have when confronted with any task or obligation. Those options are to do the thing right away, defer it until later, delegate it to someone else, or dump the task altogether.
37. Working Backward (the Amazon Method)
Developed by Amazon, this is a product development framework in which a product manager starts by writing a press release announcing the market release of the new product. The hypothetical reader is the end-user, and the release describes the user’s current need or problem, the ways that other options have fallen short of solving that problem, and how this new product will succeed where others failed. The strategy is to focus the product team’s thinking and force them to honestly assess whether or not the product is worth building.
How to choose which prioritization framework to use
With dozens of options available, selecting a product prioritization framework may seem overwhelming. There is certainly a lot to consider.
But the reason so many frameworks exist is that so many organizations have different needs; needs based on the company’s size, the product’s maturity, or the culture of the product development organization. Check out our most recent report to learn what prioritization framework was voted most popular by product managers.
We’ve made it a little easier to find your match. By combining personal preferences with the style and needs of your organization, it’s simple to narrow things down.
Best of all, with so much to choose from, you can sample a few candidates before making one part of your regular playbook.
As a product manager (PM), how do you decide what to work on next? How do you determine if an initiative is worth pursuing in the first place? In most cases, nobody is going to hand you a written plan guiding you step-by-step to complete your initiative. That’s why you have to learn to prioritize your work, optimize your cross-functional team’s workflows, and know-how to quickly assess whether or not an initiative is worth your company’s time and budget.
We’ve compiled dozens of proven product management frameworks to help you do just that.
Prioritization Frameworks
1. Value vs. Complexity
The value vs. complexity framework gives product teams an objective way to determine which initiatives (features, bug fixes, etc.) to prioritize on the roadmap. The team then scores each action according to how much value it will bring to the product and its level of difficulty to implement.
The value vs. complexity framework is built on a prioritization matrix, like the one shown here.
2. Benefit vs. Cost (Weighted Scoring)
Product managers use the weighted scoring prioritization framework to rank initiatives according to common cost-vs.-benefit criteria. The team creates scores for each criterion: “increase revenue” under benefits, for example, and “implementation effort” under costs. The team can generate higher overall scores for those criteria it deems more significant than others.
The screenshot here shows an example of a team using six scoring criteria—three benefits, three costs—on which to rank the relative strategic value of seven competing product initiatives.
3. Kano
The Kano model helps product teams prioritize their work according to which features are most likely to delight customers. The team will rank each initiative according to its likelihood to please customers as well as its implementation cost. After, prioritize the features rated high delight and low cost.
4. Buy-a-Feature
The buy-a-feature prioritization framework gives organizations a fun way to prioritize work on products or other initiatives. The model works by creating prices for each competing action on your list, giving a group of participants a hypothetical sum of money to spend, and asking them to buy those features they’d most like to see built.
5. Opportunity Scoring
Opportunity scoring helps product teams determine which features their customers deem essential to the product but also find disappointing. Teams ask customers to rank the importance of several product features and then rate how happy they are with each feature. Features scoring high in importance but low in satisfaction represent the opportunity to realize a strong return on investment for the development work needed to improve them.
6. Affinity Grouping
The affinity grouping is designed as an informal and collaborative framework for prioritization. Each participant comes up with ideas to improve the product and places them on note cards or a whiteboard. Participants will then organize these opportunities into significant themes—the affinity groups—and vote on how to prioritize each of the possibilities under each group.
7. Story Mapping
The story mapping framework gives product managers a visual and holistic sense of how each user story contributes to the overall product experience. The team uses a large board, or a wall, to create a visual walkthrough of the user’s interaction with the product, first identifying the significant steps involved and then adding individual stories beneath them. When the map is complete, the team has a logical view of the user experience and can then determine which stories are a high priority and which are low.
8. Eisenhower Matrix
The Eisenhower Matrix can help teams improve their prioritization, productivity, and decision making. Named after a method used by President Dwight Eisenhower, this framework involves drawing four squares, two on top of the other. You’ll label the x-axis Urgent and Not Urgent, and for the y-axis, you’ll use Important and Not Important. This framework gives you four possibilities: from Important and Urgent, to Unimportant and Not Urgent. Once you’ve placed the initiatives on your list into one of these four boxes, you’ll know which to work on first—those in the upper-left quadrant, Important and Urgent.
9. ICE Scoring
Using the ICE scoring model, product managers can quickly weigh competing initiatives by assigning each a score based on three criteria: impact, confidence, and ease. ICE scoring is designed to help product teams promptly decide which projects to take on so they can start work as soon as possible. But it is not as rigorous as other frameworks, such as weighted scoring.
10. Impact Mapping
Using the impact mapping prioritization framework, product managers focus first on their high-level strategic goals. The PM then works outward from there, determining the relevant actors who will be involved (including the users themselves), how each actor can contribute to the goal, and what the final output will be when you’ve succeeded.
11. MoSCoW Analysis
The MoSCoW prioritization framework helps teams manage requirements and is commonly used to help stakeholders understand the importance of initiatives in a specific release. Group initiatives into four categories, which make up the acronym: M represents the “must-have” items; S is the “should-haves;” C is the “could-haves” (or nice-to-have initiatives), and W represents the “will not have” items deemed low priority.
12. RICE Scoring
The RICE scoring framework helps product teams prioritize items on a product roadmap by scoring them according to four criteria: reach, impact, confidence, and effort. When the team combines its total scores for all initiatives across all four criteria, each initiative will have a single score to weigh its relative value to the product and the organization.
Agile Product Management Frameworks
13. Crystal Agile Framework
A direct outgrowth of the Agile Manifesto for software development, the Crystal Agile Framework method is a human-centered agile framework. That is, it is designed to give teams the freedom to develop and improve their workflows. Although this framework allows each team to find the right methodology to fit its needs and circumstances, it can also lead to confusion and even scope creep.
14. Disciplined Agile
Disciplined Agile (DA) is similar to the Crystal method in that it allows individuals and teams to find their preferred workflow methods. But it does offer some lightweight guidance for how these teams should work, pulling best practices from other methodologies such as Scrum and Kanban.
15. Dual-Track Agile
With the dual-track agile approach, a cross-functional team breaks its work into two categories: discovery and delivery. The discovery track focuses on quickly generating validated product ideas. Delivery focuses on turning those ideas into market-ready products.
16. Dynamic Systems Development Method (DSDM)
The dynamic systems development method (DSDM) evaluates how a project’s lifecycle—from conception to completion—will impact the business. The framework evaluates each project according to four criteria: feasibility and business study, functional model and prototype iteration, design and build iteration, and implementation. The DSDM model states that “any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.”
17. eXtreme Programming
One of the most popular agile frameworks, eXtreme programming, is designed to help software companies deal effectively with dynamically changing requirements. It can also help companies deliver successful products to users with regularly changing needs or who cannot effectively articulate what they want. This framework uses a small development team and leverages automated unit and functional tests. When using eXtreme programming, it is crucial to keep in mind that the framework requires developers to work closely with managers and customers.
18. Feature-Driven Development (FDD)
Feature-driven development is an agile framework used primarily by large companies because it is a top-down decision-making framework that requires a hierarchy of personnel. The FDD model organizes the team’s work around making progress on features, which in the context of this framework could also include user stories.
19. Lean Software Development
Originally called the Toyota Production System (for the company that originated the framework), Lean Software Development model focuses on eliminating from development everything but what the product needs. It is also sometimes called the Minimum Viable Product (MVP) strategy, because the team’s goal is to deliver a bare-bones product to its users, then use their feedback to improve the offering.
20. Rapid Application Development
The Rapid Application Development (RAD) agile framework is used to rapidly generate prototype versions of software products and release them to the market for feedback. The team then uses this feedback to improve the product, release the new version, and continue the cycle. The RAD framework consists of the following stages: requirements planning, user design, rapid construction, and cutover.
21. Scaled Agile Framework (SAFe)
A widely used methodology in large enterprises, the scaled agile framework (SAFe) is designed to protect against the common challenges large companies face as their agile teams scale up. This top-down decision-making framework focuses on three aspects of development: team, program, and portfolio.
UX/Design Frameworks
It’s also helpful to know how your UX and design teams use frameworks to prioritize.
22. Design Thinking
Design thinking is a framework to help inspire innovation by viewing everything from the user’s point of view. IDEO, the company often credited with creating this framework, says design thinking is a human-centered approach to building products.
23. CIRCLES
The CIRCLES Method is a product design framework based on following a specific path and answering the right questions to fully understand what you need to design and why. The stages of the process form the acronym. Comprehend the situation. Identify the customer. Report the customer’s needs. Cut through prioritization. List solutions. Evaluate trade-offs. Summarize your recommendation.
24. The User Is Drunk
In UX and web design, this framework asks a simple question. Is your site or app easy and intuitive enough that even a drunk person could use it?
25. KEY Design Process
As UXPlanet explains, the KEY design process is a two-part strategy to help designers manage their work. The two parts are the opportunity segment and the solution segment. The object of this adaptable guideline is to give designers an ongoing reminder to consider the context, understand users, and validate their theories before moving on to development.
26. Kennedy Principle
This design principle takes its name from the most famous line in President John F. Kennedy’s 1961 inaugural address: “Ask not what your country can do for you—ask what you can do for your country.” The Kennedy design principle is to ask not what your user can do for you but what you can do for your user. The idea is, your user has a finite amount of time and patience, so do not waste any of either by making them perform tasks your app could automate for them. One example would be designing a form that asks first for the user’s US ZIP code, and then in a separate field asks them to input their state of residence. Your code should perform that second task for the user.
More Product Management Frameworks
27. DACI
DACI is a decision-making framework named for the four roles it covers. There is the driver (who drives the decision), the approver (who makes the decision), contributors (who help with the project), and the informed (the people whose work could be impacted by the project).
28. GIST Planning
A product-planning framework, GIST is designed to help reduce management overhead, speed development, and deliver successful products. The name stands for the key pillars of the approach: goals, ideas, step-projects, and tasks.
29. Jobs to Be Done (JTBD)
Like design thinking, the jobs to be done framework is designed to change the team’s focus from the product to the customer. This approach helps a product team learn what its customers want to do when they buy a product or service, so the company can focus its development on satisfying those needs.
30. Quality Function Deployment
Quality Function Deployment (QFD) is a popularized 50-year-old methodology for product development and production. Build the approach around listening to customers and incorporating their voice into the team’s plans. The QFD framework translates customers’ desires, needs, and expectations into technical requirements for the product’s development. The idea is to take the customer’s voice into every stage of production throughout the product’s lifecycle.
31. SWOT Analysis
SWOT analysis is a planning and decision-making framework that a company can use to determine whether or not to begin any strategic initiative—building a new product, for example, or entering a new market. The method works by breaking down any initiative into its strengths, weaknesses, opportunities, and threats. The team then evaluates the project’s value and risk-based on each of these criteria before deciding whether or not to move forward.
The SWOT matrix is a simple, two-by-two grid like the one shown here. It should include boxes labeled strengths, weaknesses, opportunities, and threats.
32. Classical Economics
Classical economics is the school made famous by thinkers such as Adam Smith, who argued for free markets and believed rational actors working in their interests would create increased levels of prosperity for everyone. When you take a classical-economics approach to product management, you apply these broad, macroeconomic principles to your market. You assume your customers will behave rationally and make reasoned decisions when it comes to choosing which products to buy.
33. Behavioral Economics
The behavioral-economics framework in product management takes a different view of your user base. This view is the approach that argues for appealing to people’s emotions—using pricing strategies such as anchoring to enable you to charge more for your offering. Contrary to the classical-economics framework, this approach views people not as rational actors but as emotion-driven actors.
34. HEART Framework
Google created the HEART framework to bring quantitative metrics to the “touchy-feely” world of UX. This flexible methodology allows designers to quantify either specific features or the entire user experience according to five metrics. Those are happiness, engagement, adoption, retention, and task success.
The genesis of this framework was the typical UX team’s inability to turn all the available data into actionable intelligence. Using HEART, they could define measurable user experience goals and bring the data-driven decision making to an area of product development that typically doesn’t rely on measurables to drive their designs.
But there’s no reason to limit HEART to UX—product managers can apply the same principles to every aspect of their product. It’s a nice deep-dive into customer delight and satisfaction that many of the other frameworks only cover cursorily.
35. AARRR
Explicitly designed for startups, AARRR is a five-step framework to help young businesses grow. Developed by venture capitalist Dave McClure, the acronym forms those five key metrics McClure believes every startup should focus on. They are acquisition, activation (referring to the user’s first product experience), retention, referral, and revenue.
36. The 4 Ds (Do’s, Defer, Delegate, Dump)
The 4 Ds is a time-management framework. It describes the four options you have when confronted with any task or obligation. Those options are to do the thing right away, defer it until later, delegate it to someone else, or dump the task altogether.
37. Working Backward (the Amazon Method)
Developed by Amazon, this is a product development framework in which a product manager starts by writing a press release announcing the market release of the new product. The hypothetical reader is the end-user, and the release describes the user’s current need or problem, the ways that other options have fallen short of solving that problem, and how this new product will succeed where others failed. The strategy is to focus the product team’s thinking and force them to honestly assess whether or not the product is worth building.
How to choose which prioritization framework to use
With dozens of options available, selecting a product prioritization framework may seem overwhelming. There is certainly a lot to consider.
But the reason so many frameworks exist is that so many organizations have different needs; needs based on the company’s size, the product’s maturity, or the culture of the product development organization. Check out our most recent report to learn what prioritization framework was voted most popular by product managers.
We’ve made it a little easier to find your match. By combining personal preferences with the style and needs of your organization, it’s simple to narrow things down.
Best of all, with so much to choose from, you can sample a few candidates before making one part of your regular playbook.
How to deal with backlogs during prioritizationOver time the product backlog can become an unmanageable mess, transformed from a useful, well-organized repository of ideas into a chaotic storage bin. Ensuring your backlog retains actual value requires prioritization.
Backlogs are not supposed to be the dark closet where we toss ideas we don’t feel like dealing with at the moment. It’s not supposed to be the junkyard of annoying sales requests, way too specific customer asks, and ignored technical debt.
When managed well, the backlog should be an orderly queue of inspiration. By prioritizing the items kept there, it can serve that purpose. But doing so requires some discipline and some hard choices.
If something will never be built, it doesn’t belong in the backlog… it belongs in the trash. If it’s important enough, evaluate it in the future and treat it accordingly.
All backlog items also shouldn’t be thought of equally. Items that are up for consideration for imminent releases should be categorized separately from the nice-to-haves that won’t see the light of day for months or years. Moreover, by keeping your backlog mean and lean, regular reviews of its contents won’t become so burdensome.
How does keeping score simplify roadmapping?
Many of the prioritization frameworks previously discussed emphasize scoring. These numbers are not only helpful when deciding what to prioritize, but they can also speed up the creation of product roadmaps.
When scoring individual items, you now have a quantifiable value for each item on multiple vectors. Illustrate these in a matrix format instead of merely force-ranking everything based on overall priority. With this information, you can not only be sure that your roadmap contains high-priority items but that there’s also some balance.
For example, if the top three prioritized items are all driving revenue but not doing much to improve customer delight, then it might not make sense to do all three of them first. Instead, you want to balance out a high-priority feature that brings in cash by also adding a feature that will make customers happy.
For instance, items ranked No. 1 and No. 4 get done before No. 2 and No. 3. But it also means customers will get a steady diet of things they’re excited about instead of having to wait months and months while you work on items they’re less interested in.
Over time the product backlog can become an unmanageable mess, transformed from a useful, well-organized repository of ideas into a chaotic storage bin. Ensuring your backlog retains actual value requires prioritization.
Backlogs are not supposed to be the dark closet where we toss ideas we don’t feel like dealing with at the moment. It’s not supposed to be the junkyard of annoying sales requests, way too specific customer asks, and ignored technical debt.
When managed well, the backlog should be an orderly queue of inspiration. By prioritizing the items kept there, it can serve that purpose. But doing so requires some discipline and some hard choices.
If something will never be built, it doesn’t belong in the backlog… it belongs in the trash. If it’s important enough, evaluate it in the future and treat it accordingly.
All backlog items also shouldn’t be thought of equally. Items that are up for consideration for imminent releases should be categorized separately from the nice-to-haves that won’t see the light of day for months or years. Moreover, by keeping your backlog mean and lean, regular reviews of its contents won’t become so burdensome.
How does keeping score simplify roadmapping?
Many of the prioritization frameworks previously discussed emphasize scoring. These numbers are not only helpful when deciding what to prioritize, but they can also speed up the creation of product roadmaps.
When scoring individual items, you now have a quantifiable value for each item on multiple vectors. Illustrate these in a matrix format instead of merely force-ranking everything based on overall priority. With this information, you can not only be sure that your roadmap contains high-priority items but that there’s also some balance.
For example, if the top three prioritized items are all driving revenue but not doing much to improve customer delight, then it might not make sense to do all three of them first. Instead, you want to balance out a high-priority feature that brings in cash by also adding a feature that will make customers happy.
For instance, items ranked No. 1 and No. 4 get done before No. 2 and No. 3. But it also means customers will get a steady diet of things they’re excited about instead of having to wait months and months while you work on items they’re less interested in.
How to develop goal-oriented prioritization processesIf your organization has defined objectives and key results (OKRs) for itself or your product, they can also be leveraged during the prioritization process. This popular framework has spread from Google to organizations in many industries, who love the focus on the bottom line.
Each objective is already essentially an epic or a roadmap theme. It’s a concise statement about what the product should achieve. Put it in a roadmap context, and then directly tie each user story or development item to a measurable key result that the organization has prioritized.
With OKRs as a starting point, the structure of the roadmap becomes a no-brainer. You can then use one of the previously discussed frameworks to prioritize features that will help the product meet the target key results.
If your organization has defined objectives and key results (OKRs) for itself or your product, they can also be leveraged during the prioritization process. This popular framework has spread from Google to organizations in many industries, who love the focus on the bottom line.
Each objective is already essentially an epic or a roadmap theme. It’s a concise statement about what the product should achieve. Put it in a roadmap context, and then directly tie each user story or development item to a measurable key result that the organization has prioritized.
With OKRs as a starting point, the structure of the roadmap becomes a no-brainer. You can then use one of the previously discussed frameworks to prioritize features that will help the product meet the target key results.