"We want it all!" - Prioritizing the Product Backlog

One of the great mysteries of Product Management is how the work that we plan is prioritized. I say that not from the perspective of a Product Manager because hey, I'm a Product Manager too and I know how it's done. But this is quite often a perception that is held from the rest of the organization and customers. In many organizations, submitting an idea to the Product team is like a black hole. The idea goes in, and nothing comes out. To my fellow Product Managers, do not crucify me for saying that because I believe if you dig in a little, you'll discover that is is commonplace.

It's quite a balancing act. The CEO has a grandiose plan that she wants to execute on. The sales team will lose a deal if we don't rush through feature X. The competition is eating our lunch in some area of product functionality. Customers are clamoring for a feature. Support is seeing churn due to a bug that needs to be fixed. Finance insists we increase margins by reducing our COGS. The Engineering team has technical backlog that needs to be addressed. ARGH! But no worries, we can do it all. We have unlimited capacity, right? Wrong. In a perfect, Barbie dream world (as our CPO would say), we'd have all the resources we needed to immediately address all of the requests that come our way. But the harsh reality is that we have a finite amount of capacity and we need to spend it in ways that provide the biggest, positive impact to the organization and to our customers.

So how do you deliver on all of your requests and create an organizational utopia? Another harsh dose of reality coming...you don't. The first step in prioritizing is accepting the fact that you are not going to be able to do everything, do it all at once, and make everyone happy. At some point, you will need to say "no". That's an "n" and an "o". Say it with me "no". Nobody wants to be the villain, but you must be prepared to say "no" when a request doesn't make the cut. But when you do say no, you must also explain, in detail, why the request didn't make it. You'd be surprised how accepting (usually) people are when you provide a detailed reason for not including their recommendation. They (usually) understand why making $500k by implementing feature X vs making $5k by implementing feature Y is a smart use of resources. (all things being equal). Also keep in mind that saying "no" today doesn't necessarily mean that you'll say "no" tomorrow. While you can't do everything all at once, you may be able to accomplish it down the road, and that's where prioritization comes in.

To help determine priorities and to assist you in articulating to peers and customers why items are, or are not selected, you can use a prioritization model. There are many models available, but I am going to briefly cover 7 that we use on our Product team. If you'd like more detail on these or other prioritization frameworks, ProductPlan, ProductSchool, and Craft.io all have some good articles.

Prioritization Models

MoSCoW

The MoSCoW prioritization technique is a process that is used in Agile Product Management. It provides a way to quickly triage ideas that are important and those that are not. The name is an acronym for 4 prioritization categories: Must have, Should have, Could have, Won't have.

** Must have** requirements are absolutely critical for success and they must be present, or you do not launch. These could be for legal or security reasons. Or they could be highly anticipated features that your user community is clamoring for and expecting, and not releasing them would cause an extremely negative customer experience. A good way to make this determination is to consider the best and worst case scenarios if you do not include the feature. If you don't see a path to success without it, then it is a must have.

Should have requirements are very important to success. (think, high-priority). They are important, but failure to include them will not sink the product. But do think long and hard about them and how you can include them in the release.

Could have are optional features. They'd be nice to have, but you won't be doomed if they're not present. If capacity were unlimited, these are the features that you would include. The difference between "should have" and "could have" comes down to user experience. The lower the impact to UX that not including it has, the further down on the prioritization list the feature should go.

Won't have are pretty self-explanatory. These will not be included, at least in this release.

Once you've triaged your backlog using the MoSCoW technique, it's always a good idea to sanity check your prioritization will your Product team colleagues as well as individuals from across the organization. Your peers may be able to see things from a different angle and point out factors that you may have overlooked.

RICE

RICE is a prioritization model that scores ideas based on 4 categories.

** R**each

Hopefully when you're thinking about your product(s) and what to build, you're fixating on the customer. Reach helps a Product Manager to think about how many customers will be impacted when the feature is released. The measurement should be done over a period of time. As an example, how many customers will this impact on a monthly basis? Whatever value you assign here, it should be supported by data.

** I**mpact

What will the impact be on the users that you are going to reach? You should always keep your goals in mind. Are you trying to improve your CSAT? Are you attempting to reduce abandonment? Are you looking to increase logins, pageviews, or session time? This measurement is a little more fuzzy as it's subjective. But the following scale is one that we use internally and one that I've seen recommended by many other Product Management orgs.

  3 - Massive Impact

  2 - High Impact

  1 - Medium Impact

  0.5 - Low Impact

  0.25 - Minimal Impact

** C**onfidence

While I strongly urge leveraging data to direct decisions, it's not always available and possible to do so. This is where the confidence factor comes into the model. The question to ask yourself is, how confident are you in the data you do have available, and the assumptions that you've had to make when thinking about Reach, Impact, and Effort? This should be entered as a percentage. In general, anything over 80% is high confidence and anything under 50% should be disqualified until a higher confidence level can be obtained.

** E**ffort

Effort can be tricky to obtain. You are going to need to include colleagues from several other teams (Engineering, Designers, Architects, etc.) to come up with these estimates, and these teams are often busy and in some cases, hesitant to provide effort estimates. In this case, you're not looking for a specific number of hours. You need to consider the work
in person months. As an example. if Product needs a week of planning, Design will take 3- 4 weeks, and Engineering will need 5-6 weeks, this would be 11 weeks or 3 person months. I always round up to the next whole month to keep things simple. (For projects significantly less than 1 month, you could round to .5. This is the only time I do not use a whole number.)

Once you have all 4 numbers, it's time to plug them into the model and calculate the score.

Affinity Grouping

During our quarterly product workshop, each Product Manager presents the research that helped to inform his/her product roadmap. This includes customer feedback, market research, competitive intelligence, internal metrics such as product usage/support tickets/win-loss data/sales objections, etc. Based on this information, the Product Manager also explains the value of each of their proposed roadmap items. That is, value to the customer and value to the organization. After all of the Product team has had the opportunity to present their roadmap, we perform an exercise called Affinity Grouping.

Each of the Product Managers is given 5 blank sticky notes. (You can use more or less depending on the breadth of your product portfolio). Each Product Manager then writes down the product ideas that he/she thinks will have the most impact or are the most important. (1 idea per sticky note). These ideas can be across any of the product lines and do not need to be within the product area managed by the Product Manager. Value is the most important consideration in this exercise. Once all of the Product Managers have completed their 5 sticky notes, they are all placed on a board for everyone to see. One of the Product Managers plays moderator and the team begins to group the sticky notes together into themes. Examples of themes might include increase revenue, improve UX, reduce COGS, increase TAM, etc. What quickly becomes obvious are the items that team members believe hold the most value. The team then debates the prioritization of the ideas and this becomes the prioritization of the roadmap.

The image below illustrates the Affinity Grouping exercise our Product Team went through in TelAviv, Israel pre-COVID. As you can see, we collected many items and what may not be obvious in the picture is that these have been grouped into common goals or value.

Note: Pre-COVID, our workshops were in-person and the exercise was performed using sticky notes (see above). Since COVID, all of our workshops have been remote, but there are several on-line tools that provide the same capabilities. My favorite is Miro. Google Jamboard is another option that we've used successfully.

To spice things up a bit, you can also include members from other teams such as Marketing, Sales, Support, etc. to participate in the exercise. This helps sanity check the data that the Product team gathered (was something important missed?), provides a voice to other teams, and builds awareness of the prioritization decision making process across the organization.

Story Mapping

Story mapping is a great technique because it focuses heavily on the user experience, and doesn't put as much weight on opinions. In a nut shell, you will map out the workflow of your product from start to finish, prioritize the steps, and then slice the work into releases.

Begin by creating a product workflow using sticky notes (I should be getting commission from 3M for all of the sticky notes I am recommending you use!) or a Kanban board. Arrange the notes/cards from the start of the user experience to the end.

Next, order the items that are the most important to develop from top to bottom.

Finally, create releases based on slices of the workflow. I've included an image below to better illustrate the final output of this exercise.

Image Source: ProductPlan

A couple of drawbacks to this framework is that it does not take business value and complexity into consideration.

Admittedly, I don't use this one frequently, but it does help when I am launching a new piece of functionality to help me think through the steps and what a minimum lovable product might include.

Weighted Scoring

In weighted scoring, the prioritization score is the weighted aggregation of drivers that are used to quantify the importance of a feature. Examples of drivers could be revenue generation, user experience, engagement, COGS reduction, regulatory compliance. etc. To calculate this score, use a weighted average of each features score across all drivers. What are the drivers? Well that is dependent upon your organization and perhaps even on the release. You should spend some time ensuring the strategy for the coming release is clearly defined, then you can determine the drivers that will help you execute on that strategy. Once you have identified the drivers, you'll need to assign a weighting from 0% (smallest contribution to the overall score) to 100% (largest contributor). Enter each of these as a separate column in a spreadsheet.

Now you should list your features on each row of the spreadsheet. Then, go through each feature and assign a value from 0-100 for each driver. The higher the number, the higher the impact that the feature has on that driver.

I've included a sample scorecard below to reinforce the process above. (Image source: How to Use a Scorecard to Prioritize Features.) You can see the calculated number in the priority column that helps you to prioritize your work.

Value vs. Complexity Quadrant

A value vs. complexity quadrant is simply a 2 x 2 grid with value plotted against complexity.

Value is the benefit customers will get out of using the feature. What customer problem does the feature solve? How does it change the way a customer accomplishes their task? Also, is the feature going to have a positive impact on the revenue of our organization.

Complexity is the amount of effort your organization will require to build and deliver the feature. Cost of development, deployment, support, infrastructure, provisioning, training, etc. should all be considered when determining how complex (effort/cost) a feature will be.

When plotted together, value & complexity align into quadrants that allow you to easily identify what features you should focus on immediately, which you should do later, and which you should probably not do at all. Below is an example of a Value vs. Complexity Quadrant.

The four quadrants in this matrix are:

Quick Wins (upper-left) - These are high business value with low effort features. These are the proverbial low hanging fruit and you should go after these first.

Major Features (upper-right) - Features in this quadrant deliver big value, but they also come with a big price. (effort). There is more cost and more risk in these initiatives and therefore you should be sure that they are thoughtfully considered before proceeding.

Extra Features **(bottom-left) **- These are fill in features or "maybes". These features
don't require a lot of effort, but they also don't deliver a lot of value. These might be considered "nice to haves" or "maybe in the future" ideas. We sometimes tackle these if we're already working in the same area of the product I call these "while we have that part of the car taken apart, we might as well do this".

Time Wasters (bottom-right) - These are black hole features that will suck your time and if a feature does manage to escape the gravitational pull, will yield little to no value.You should not be working on these features. Avoid them like you avoid someone coughing in a supermarket.

Kano

The idea behind this model is that customer satisfaction depends on the level of functionality that a feature provides. There are 2 dimensions (X & Y axis) to this model. Satisfaction/delight/excitement which is represented on the Y-axis, and functionality which is represented on the x-axis. The increments on each of these axis represent the users perception of how well the product or feature met their expectation. Below are two images that show the values in each of these categories.

_Image source: _The Complete Guide to the Kano Model

Kano classifies features into 4 categories of customers expectation or need. These are;

Expected/Basic (Must have, table stakes) - These are features that are expected to be present in your product. Without them, you haven't met the basics.

Normal/Performance - These are features that satisfy the customer. The more of these features that your product has, the more satisfied the customer will be.

Exciting/Attractive - These are features that will delight your customer, and the customer may not have even been aware that they needed them. But once they have the feature, they will wonder how they lived without them. You should always try to pick a few of these features to include in a release.

Indifferent - The presence or absence of these features do not affect customer value in any way.

Customer perception is the key to this model, and you had better ensure that you understand your customer well in order for it to be effective.

When looking at your planned features and where they fall into the 4 categories, you want to focus on Expected/Basic, Normal/Performance, and Exciting/Attractive. Features that fall into Indifferent or Dissatisfaction should be avoided for obvious reasons.

If you'd like more detail on the Kano model check out The Complete Guide to the Kano Model. There is a lot more to this technique.

The Reality Is...

I described several prioritization techniques in the sections above. The reality is that an organization may use some or all of these methods to prioritize the product backlog. In our case, we use Affinity Grouping and Story Mapping during our product workshops as they're great frameworks for collaboration and terrific team building exercises. To triage submissions to our ideas portal, we typically use the MoSCoW method to separate the wheat from the chaff so to speak, before we accept ideas into our backlog. On an ongoing basis, we've created a hybrid framework that is a cross between RICE and Weighted Scoring. This model groups prioritization variables into RICE categories, but adds weighting across the categories and variables to calculate a prioritization score. We've even incorporated this into our Product Management tool, Aha!, so that a Product Manager just selects a few values and the score will be calculated automatically. Below is an example of this hybrid model shown both in Excel as well as within Aha!.

Communicating Priorities

I'm going to spend a couple of moments discussing communication. As I mentioned at the beginning of this blog, there's a perception that Product is a mystery, voodoo magic, a black box. You could have the worlds greatest prioritization process, but if the only people that understand that process are on the Product team, it's not going to help with this perception. You need to be sure that the company understands the process and that other teams feel that they have a voice, and are being heard.

One point regarding communication that I cannot emphasize enough, do not show an algorithm to your peers and customers and expect them to go "oh yeah, I get it". Instead, you need to break it down into value. I.e., it will generate $x in revenue. It was requested by y customers and will increase CSAT by z. COGS will be reduced by $x. It will increase our TAM by y which in turn is expected to generate $x in additional revenue. etc. The point is that you quantify the decision by including one or more value points that everyone can relate to. If there's pushback, then let them have it with your algorithm wizardry. (j/k) Always consider your audience and look for the best way to effectively communicate to them.

Another method that our Product team has adopted is a Product Council. I've mentioned this in previous blog posts, but for those who haven't yet had their life altered by reading those posts, here's a quick recap.

_A Product Council is a group of representatives from internal departments that meet regularly to provide departmental feedback to the Product team, and to receive information from the Product team to carry back to their respective departments. _

This bi-directional feedback loop is a great opportunity to not only receive input from across the organization without it being a free for all, but it's also an awesome way to share the reasoning behind product decisions. Especially if the request originated from the Council. Since implementing the Product Council, there's been a much greater understanding of the role that the Product team plays in the organization, as well as the reasoning behind the decisions that are being made. Goodbye black hole, hello utopia! (OK, Maybe it's not that good, but it is huge leap forward.)

Wrapping Things Up

In addition to the prioritization frameworks I've described above, there are many other fun and effective frameworks available. Check out other frameworks such as the ICE scoring model, buy a feature, product tree, cost of delay, and opportunity scoring to see if these may be useful to your organization as well.

Balancing the product backlog is no easy task. As a Product Manager, you should be regularly grooming your product backlog and making priority adjustments as conditions change. It is a never-ending process.

Become comfortable in saying "no", but always be sure to explain the why and the when (if there will be a "when").

Claim victory when you deliver a requested feature. This means communicating both internally externally, especially to the requestor(s). Your customers may not read your release notes or notice that a new feature has been released. This is a great opportunity to build goodwill. You've delivered on a request and you've taken the time to reach out and let the customer know. That is the kind of interaction that builds your relationship with the customer.

Remember that a prioritization framework is not the be all and end all for prioritizing. There are other factors that should be taken into consideration when setting priorities. Customer commitments, dependencies, similar work (while we've got the car apart, let's do this), capacity and many other factors may also sway your priorities.

At the end of the day, Product is responsible for setting priorities and allocating capacity. So be sure that you are focusing on the activities that are going to bring the greatest value to your customers and to your organization. That is the bottom line.

Wishing you all the best

Mike