Prioritization Frameworks

Prioritization frameworks help your team determine the order in which to work on features and backlog items. When faced with the mess caused by the uncertainty of instinct prioritization, my-young-self would immediately jump to use the prioritization framework in fashion at the time. Prioritization frameworks are usually about putting ideas into buckets or about some made-up math formula to rank them.

Product prioritization frameworks are a set of principles; a strategy to help us decide what to work on next.

The right prioritization framework will help you answer questions such as:

• Are we working on the highest business value item?
• Are we delivering the necessary value to customers?
• Does our work contribute to the broader business objectives?Can we get this product to the market?

These frameworks are good when we never had to think strategically about how to prioritize. Introducing structure forces us to clarify, articulate and line our thoughts. It’ll naturally lead to decisions that better persist the test of time. And it’ll help us communicate those decisions to create consensus.

Nevertheless, while it looks simple and clean, it’s still about guessing. We wag our fingers in the air and say: “This looks like a must!”; or “This feels like a 3+2+5”. It can be misleading as it provides a false sense of confidence in math. Even worse, it might distract us from the focus of delivering the product’s unique value proposition. Or make up for the lack of a shared understanding of the product strategy.

Have a hard time choosing between product prioritization frameworks?

As a product manager, deciding how to spend your time and resources can be difficult, especially as you are bombarded with meetings, feature requests, new customer data, shifting objectives, and more.

You need a way to sift through these details and choose the ideas that will lead to the best customer and business outcomes.

Luckily, product prioritization frameworks exist for just that.

Why use a product prioritization framework?

Before diving into the frameworks, let’s explain why many of these frameworks exist in the first place.

Product teams need to prioritize their features based on what will have the greatest business impact. They need to justify those decisions and tradeoffs in a way that transcends subjective and gut decisions and speaks to stakeholders and execs in a meaningful way.

ROI used to be the de-facto solution, but it’s rife with challenges. The problem is that ROI relates to the financial impact of a particular initiative and can’t accurately measure the impact of a specific feature.

ROI struggles to attribute product features to business impact. If it does, it happens too slowly for the fast-paced agile environment that product teams operate in, meaning that the results gained can’t help you to prioritize the next iteration.

Plus, this approach has other drawbacks, forcing teams to shy away from risk-taking and innovation.

Investing in an existing product or channel will provide a more predictable ROI than new and unproven products, stifling experimentation and testing within product teams

Here are the most popular strategies and prioritization frameworks for prioritizing features:

1. Value versus Complexity Quadrant

   A value vs. Complexity Quadrant is a prioritization instrument in the form of a matrix. It is a simple 2 x 2 grid with “Value” plotted against “Complexity.” This 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.

   In the Value versus Complexity model, you evaluate every opportunity based on its business value and its relative complexity to implement. Based on our conversations with product managers this is a common approach, and many product managers go through this assessment instinctively every day. The prioritization framework of the matrix is simple: The initiatives that have the highest value and the lowest effort will be the low-hanging fruit for your roadmap.

   With this method, it’s important to keep in mind that the final scores are just an estimation. A lot of guesswork and opinions (backed with as much applicable data as possible) are involved in the process of quantifying the big question prioritization aims to answer: “Will this feature/update push our goals and metrics forward if we build it? Can we feasibly build it with the resources we have?”

   To make this framework work, the team has to quantify the value and complexity of each feature, update, fix, or another product initiative.

   • Value is the benefit your customers and your business get out of the feature. Is the feature going to alleviate any customers’ pains, improve their day-to-day workflow, and help them achieve the desired outcome? Also, is the feature going to have a positive impact on the bottom line of your business?
   • Complexity (or Effort) is what it takes for your organization to deliver this feature. It’s not enough that we create a feature that our customers love. The feature or product must also work for our business. Can you afford the cost of building and provisioning the feature? Operational costs, development time, skills, training, technology, and infrastructure costs are just some of the categories that you have to think about when estimating complexity.

   If you can get more value with fewer efforts, that’s a feature you should prioritize.

   Value/Complexity = Priority

   When aligned together, the criteria make up several groups (or quadrants) that objectively show which set of features to build first, which to do next, and which to not do at all.

   The Value vs Complexity framework views each product initiative or feature under 2 distinct lenses: the potential value it could deliver for the client as well as the company and the effort (time and finite development resources at your disposal) it would take to accomplish/execute the initiative successfully. Once plotted inside a quadrant structure, your Value vs Complexity matrix will have the following 4 quadrants.

   • Quick Wins (upper-left): High Value and Low Complexity. There is a very high chance that these initiatives have already been completed or taken care of in some form. Due to their high value and low complexity, these features are the low-hanging fruit opportunities in our business that we must execute with top priority.
   • Major Projects, Big Bets, or Potential Features (upper-right): High Value and High Complexity. Most of your company and product initiatives fall under this category. The initiatives that fall into this block are the big project releases that we know are valuable but are too risky to take on because of the resources and costs involved with them.
   • Fill-Ins or Maybes (lower-left): Low Value and Low Complexity. Doesn’t require immediate attention and can be pursued later when there are adequate resources available. In this quadrant are usually positioned the “nice to have” features. Things like small improvements to the interface and one day, maybe ideas.
   • Thankless Tasks or Time Sink Features (lower-right): Low Value and High Complexity. Simply Scrap it. Time sinks are the initiatives that we never want our team to be working on.

The Value vs. Complexity Quadrant is an excellent framework to use for teams working on new products. Due to its simplicity, this framework is helpful if you need to make objective decisions fast. Also, if your team lacks resources, the Value vs. Complexity Quadrant is an easy way to identify low-hanging fruit opportunities.

The drawback of the Value vs. Complexity diagram is that it can get quite busy if you’re working on a super mature product with a long list of features.

This method of prioritization makes room for healthy discussions among stakeholders on what they believe value and effort mean, which in turn helps product managers find the strategic alignment holes and fix them.

Pros of using value vs. effort

• What constitutes value or effort is flexible. For some organizations, the effort could just mean development effort, in others, it could be the implementation cost. A flexible prioritization framework can be used by any type of company, industry, or type of product.
• It’s a good tool for alignment. By encouraging teams to quantify and numerically score features, product teams can agree on which initiatives have more weight than others. It leaves vague guesswork and assumptions out of the prioritization discussions.
• In companies where resources are extremely limited, something as simple as a value vs. effort analysis allows teams to focus only on the things that will have the biggest impact on their business and product goals.
• It’s easy to use because it doesn’t involve any complex formulas or models. All it requires is an agreed-upon numerical value that gets added to one overall total number.

Cons of using value vs. effort

• Like all prioritization exercises, it’s a game of estimation and guessing. This leaves a lot of room for cognitive bias at the hands of the people doing the estimating. The final score for each feature might be too inflated, or not accurate enough.
• When it’s time for product and development to vote on how high or low the value/effort scores should be, the disagreements can take a while to resolve.
• It can be hard to use with large teams with multiple product lines, components, and product teams that oversee each of those.

1. MosCoW

   MoSCoW is an acronym for — Must have (features of high importance. Example, absence of which might break user flow on a product, features to complete legal requirements, etc.), Should have (high priority features over the long run. These are important but even if they are absent won’t harm the business much), Could have (nice to have features), Won’t have (the features that are not needed now and can be delayed for the next sprint).

   Developed by Dai Clegg when he was at Oracle, it enables teams to prioritize time-based projects.

   Known as the MoSCoW Prioritization Technique or MoSCoW Analysis, MoSCoW is a method commonly used in Agile PM to understand what’s important and what’s not. It’s a particularly useful tool for communicating to stakeholders what you’re working on and why. The MoSCoW method allows you to figure out what matters the most to your stakeholders and customers by classifying features into four priority buckets. MoSCoW (no relation to the city—the Os were added to make the acronym more memorable) stands for Must-Have, Should-Have, Could-Have, and Won’t-Have features.

   The MoSCoW method helps you prioritize product features into four unambiguous buckets typically in conjunction with fixed timeframes. This quirky acronym stands for:

   • Must have (Mo)
   • Should have (S)
   • Could have (Co)
   • Won’t have (W)

   This model allows one to decide which product features are important and which are not. The MoSCoW model can also be used to plan MVP (Minimum Viable Products) and in cases where the next important set of features needs to be evaluated for a product-market fit.

   In order to implement this framework, the product team and stakeholders must first be clear on objectives and prioritization factors. There should also be a way to handle disagreements that occur when categorizing features or initiatives.

   • Must-Have. Mandatory initiatives that must be worked on.

     Must-have features are non-negotiable requirements to launch the product. These are the features that have to be present for the product to be functional. If one of these requirements or features isn’t present, the product cannot be launched, thus making it the most time-sensitive of all the buckets.

     An easy way to identify a “Must Have” feature is to ask the question, “What happens if this requirement is not met?” If the answer is “cancel the project,” then this needs to be labeled as a “Must Have” feature. Otherwise, move the feature to the “Should Have” or “Could Have” boxes. Think of these features as minimum-to-ship features.

     ‘Must have’ represents the features that you absolutely should not launch without. This could be for legal reasons, safety concerns, or business reasons. If it’s something that has been promised to your users and is a huge driver for the buzz around your upcoming release, it would be a terrible idea to launch without it.

     To work out if something qualifies as a ‘Must have’ think about the worst and best-case scenarios for not including it. If you can’t picture success without it, it’s a Must have!

   • Should-Have. Important initiatives that aren’t critical but that would be valuable if implemented.

     “Should Have” features are not vital to launch but are essential for the overall success of the product. “Should Have” initiatives might be as crucial as “Must Haves” but are often not as time-critical. ‘Should have’ is for things that would be better to include, but you’re not destined for disaster without them.

   • Could-Have. Ideal initiatives that would be nice to have but aren’t necessary.

     ‘Could have’ things would be nice to include if you have the resources, but aren’t necessary for success. The line between ‘Could have’ and ‘Should have’ can seem very thin.

     “Could Have” features are desirable, but not as critical as “Should Have” features. They should only be implemented if spare time and budget allow for it. You can separate them from the “Could Have” features by the degree of discomfort that leaving them out would cause to the customer.

     To work out what belongs where, think of how each requirement (or lack thereof) will affect customer experience. The lesser the impact, the further down the priority list the requirement goes!

   • Won’t-Have. Non-priorities that sometimes get included in projects but need to be left for potential future projects as they could lead to scope creep.

     “Won’t Have” features are items considered “out of scope” and not planned for release into the schedule of the next product delivery. In this box, we classify the least-critical features or tasks with the smallest return on investment and value for the customer.

     Many seasoned Product Managers have said, “we’ll include it in V2!” When we say ‘Won’t have’ we don’t mean “this requirement is trash and it will NEVER be included’, we just mean ‘not this time.”

     Features are prioritized to deliver the most immediate business value early. Product teams are focused on implementing the “Must Have” initiatives before the rest of them. “Should Have” and “Could Have” features are important, but they’re the first to be dropped if resources or deadline pressures occur.

     It could be for a variety of reasons, like a lack of resources or time. In any case, it helps you and your stakeholders agree on what won’t make it in your next release, which greatly helps to manage their expectations.

     When you start prioritizing features using the MoSCoW method, classify them as “Won’t Haves” and then justify why they need a higher rank.

   Pros of using this prioritization framework:

   • It’s good for involving stakeholders without a technical background in the product prioritization process.
   • A quick, easy and intuitive way of communicating priorities to the team and the customers.
   • It allows you to think about resource allocation when you classify your features and requirements into each bucket.

   Cons of using this prioritization framework:

   • It’s tempting for teams and stakeholders to overestimate the number of Must-Have features.
   • It’s an exercise in formulating release criteria more than a prioritization method.

   People often find pleasure in working on pet ideas that they find fun instead of initiatives with higher impact. The MoSCoW method is a great way to establish strict release criteria and prevent teams from falling into that trap.

2. Weighted Scoring Prioritization