How to prioritize too many feature requests

Published on December 18, 2019
This is a foundational series article. Read more here

There’s always more work to do than time available to do it. Effective prioritisation is very important to provide the focus to be successful at work.

In general prioritisation is some product of effort x cost x time or value x complexity applied to possible tasks. The tasks should be aligned to your strategy.

There are some well known frameworks for prioritisation that I find useful. I’ll describe them here and talk about how to choose one with your team.

You might find that one prioritisation framework suits the team but you prefer to use a different one for your own tasks.

Applying a prioritisation framework

I suggest gathering your team together and applying your specific list of work to each framework and see what works best for you. The agenda would look something like this.

  1. Quickly create a list of your current tasks. All team members do this individually. Use post it notes so they can be moved around easily. (5 minutes)
  2. Are there any frameworks in use by the team at the moment? Any suggestions for frameworks? (5 minutes)
  3. Describe the three frameworks below to the team (15 minutes)
  4. Apply the the framework to the items from step 1 above (15 minutes)
  5. Choose the framework that makes the most sense for the work the team is doing (5 minutes)


This is a popular form of prioritisation. It looks at the value and complexity of the piece of work. Create a quadrant break down of value and complexity. Place the various work items in the appropriate quadrant. Only work on the items in 1 and 2 (in that order). You might be able to work on the items in 3 but only after the items in 1 and 2 are completed.

Value vs Complexity

              X    |   2
  Value ________________________ High
              3    |   1

High value / Low complexity are your quick wins High value / high complexity are the strategic features Low value / low complexity things can be worked on usually if there are other factors pushing it but be cautious Low value / High complexity work should be avoided

The Intercom RICE framework

            Reach x Impact x Confidence

This is a numerical framework from intercom. Numbers are nice because it’s not easy to argue with a number. Of course there is still some subjectivity in this method. The way this works can make it difficult to apply for teams that have customer facing and internal work. The reach number will vary significantly in that case.

The reach is the number of customers expected to be affected by the work. So a change to our authentication system could expect to reach 100 customers. A change to a feature used only by large enterprise customers would only reach 10 customers.

The impact is very subjective and should be decided as a group with some external input. Use 3 for “massive”, 2 for “high”, 1 for “medium”, 0.5 for low and 0.25 for minimal. These factors will scale the number appropriately.

The confidence is also subjective but don’t overthink it. I use 100% for “high”, 70% for “medium” and 50% for “low”.

For effort use the timeframe that gives you the closest to whole numbers that matches your work. For my team and I that is person-weeks. For teams constantly working on larger pieces of work that might be person-months. It doesn’t matter as long as you use whole numbers and are consistent for the set of items you’re prioritising.

See the post from intercom for more on this one:

Strategy matrix mapping

Here we have a list of columns that represent the various things that are important to you right now. This is probably related to your strategy or your mission. They should be written in a binary format. Then for each of your items to prioritise you fill in the columns. The matrix provides a visual representation of what should be prioritised.


Speed up database team Speed up support team Speed up product team Improves brand
Project A Y N N Y
Project B Y N Y Y
Project C N N N Y

In this example I would do B, A, C in that order. Often the matrix has many more columns.

Binary discussions

This method forces a group decision between just two items and you just keep repeating until all items have been sorted next to each other. It’s slower but can be useful in groups with different contexts and aims. It encourages discussion (and hopefully empathy) between the various groups.

  1. You randomly take two items to be prioritised and discuss them in a timebox.
  2. Have the group vote on which one is higher priority.
  3. Line up the items in order where A is highest priority

-- A -- B --

Now take another random item from the pool and run the same process with B. Say item C is higher priority than B. Now you have.

-- A -- C -- B --

So now you have to run the same process between A and C. If it turns out that the group feels C is higher priority you should put that to the left of A.

-- C -- A -- B --

And now you have a sorted list of prioritised items. This takes a long time but the discussions that arise are usually very valuable. You should take notes of the discussions! It’s a great method for cross-team prioritisation.


There are many ways to prioritise work and different methods will work for different teams. However always think about why you NEED to prioritise right now.

The most important thing by far is that the entire organisation has the SAME vision and is following the same overall strategy to get there. Ensure this is in place along with introducing any prioritisation tools.

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨

Read more articles like this one...

List of article summaries


Flexible work is here to stay but you should choose an emphasis

Note: This was written in August 2022 and I assume things will change quickly. It will be interesting to look back in a couple of years to see how much of this article is still relevant!

Most tech organisations were forced to change to remote during lockdown but haven’t explicitly changed their office attendance policy.


Hiring engineers in a candidate-driven marketplace

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!


How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.


Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.