The Trouble with Prioritisation and how to fix it

Prioritisation is important but often done badly as teams struggle with lots of "top priorities" and flip-flop between a cycle of urgent…

Chris Grannell

~16 min read · July 24, 2024 (Updated: November 20, 2024) · Free: Yes

The Trouble with Prioritisation

Prioritisation is important but often done badly as teams struggle with lots of "top priorities" and flip-flop between a cycle of urgent initiatives. Responsibility for solving this issue is frequently laid at the door of product management. While teams can benefit from deliberate and considered prioritisation methodologies, rarely will this solve the 'trouble' with prioritisation, because underlying prioritisation challenges are often symptoms of deeper problems. As such they cannot be adequately addressed without an organisation-wide strategy, and the commitment and structure to make it happen.

It's impossible to talk for long about product management without grappling with the indomitable word "prioritisation". This is sad because although prioritisation is a characteristic of anything involving trade-offs, product management often gets singled out and lumped with it. A focus on prioritisation frequently reveals a reductive approach to product management: where the primary role of a product manager is juggling tickets or tasks that have been submitted from around an organisation.

Organisations which fail to prioritise will experience a range of productivity issues. People are spread too thin, suffer from switching costs, and will be confused about where to focus. These companies miss out on the 'alignment dividend' which occurs when everyone within a team moves in sync.

Some organisations will benefit from implementing a more structured prioritisation approach, but rarely is this the whole story. When businesses are struggling to prioritise between intiatives, features and tasks this is often a symptom of bigger issues at the top.

Level 1 priorities are capabilities, while Level 2 are generally features or tasks

There are potentially two types of prioritisation within any organisation — and the difficulties compound when they get mixed up. These two types, which I refer to as Level 1 and Level 2, have different types of impact, different organisational breadth, and impact different timeframes. In short: Level 1 deals in capabilities; while Level 2 operates at the level of fine detail or features. Both have their own goals and objectives.

Prioritisation and its antecedents

Most organisations have more ideas than time to execute them. This applies up and down the organisation, from the CEO signing off on direction A or B, to the COO weighing up two different partnership proposals, to the person within a software team who is refining (I hate the word 'grooming') the backlog of tickets in a Kanban board. Wherever in the organisation it occurs, prioritisation is a process by which the organisation (or organisational unit) decides what to work on next.

Clients make requests, suppliers make suggestions, technology needs to be updated, competitors do things that inspire new ideas. It costs relatively little to have an idea, compared to the cost of executing it; and hence this tyranny of choice — in product management terms, the backlog — occurs.

Pedants will say "you can only have one top priority". You can fudge the issue by having several teams or individuals working in parallel (a point we'll return to later), but it is clear that you can't do it all, and therefore there must be trade-offs at wherever a decision is made. You can have a new interface this quarter, but the AI pilot is going to have to wait.

The methodology for prioritisation will differ depending upon where it occurs, so it will be helpful to identify two broad levels which work differently.

Level 1: capabilities (broad areas of activity, experiments, challenges to solve). Decisions here are typically multidisciplinary, more expensive, and have longer timeframes. It's only through strategy — a clear understanding of where we're at, where we're going to play, and how we're going to win — combined with vision — a crisp articulation of where were headed — that these decisions can be made.

Level 2: feature prioritisation (user story #1, user story #2 etc). The consequences here will be generally less impactful, and less lasting. Decisions here aren't unimportant, but they don't generally bind us to a path that it's difficult to reverse out of.

Prioritising methodologies, Level 2 style

To better understand the difference, let's look at what happens at each level.

I'll start at the detail — in the weeds so to speak — at Level 2. Here, we are making choices once the broad direction is already set. Even at this level we may have several things to choose from. Let's imagine that our team is working on a mobile app for our B2B customers. The backlog will typically contain a range of tickets — from refreshing the colours to match the new palette from marcoms, to updating the terms and conditions to allow for machine learning, to a new button that captures customer interest in the latest service offering. Sometimes it's difficult to choose.

If you look at much product management industry chatter, you'll find it's focussed here. Some of the frameworks that may be used include:

1. Voting or some form of planning poker. Critics will say that it's a popularity contest, but if the people making the decision are wise and well-informed, then the 'wisdom of crowds' effect means that isn't necessarily a weakness. And if the people agree to respect the democratic will, then they have to lump it. But if the voters just bring their own pet projects to the table and vote for them, it's more like a democratic tyranny; and it will always be limited in some way by the individual objectives of the people involved. Voting can also set an expectation that everyone gets to play, creating a false sense of equivalence between a group of advocates regardless of the quality or number of candidate ideas or tasks from each. A particular challenge in voting is when options aren't of the same type: for example known vs unknown or important vs urgent. In our fictional app example above, we might say that changing the colour palette to match the new branding is 'important', while the T&C update is 'urgent' (because not doing it will put into litigious territory). A common practical solution is to set an allowance for each, as in 'you can have 1 'urgent' in every sprint' or simply saying that when the team votes something as urgent, then it can trump everything else.

2. Assessment against several criteria, often with some criteria given more weight than others. Things like 'commercial return', 'customer satisfaction', 'reducing tech debt' frequently appear in charts like this. (In fact tools like Product Board have a handy readymade feature precisely to enable product teams to do this). It's useful, but generally opens up discussion on the weighting of the criteria, so, for example, scoring 1/5 in 'commercial return' might be worth 2, while the same score in 'reducing tech debt' might be only worth 1. Sometimes this can develop into a squabble, especially as the inputs are largely subjective, and are usually done before the data is in.

3. Another variant of (2) is to deploy an 'expected utility' calculation. This takes the value of the feature (however you've defined it) and applies a likelihood coefficient. So a big chance at small return looks very much like a small chance at a very big return. It seems logical, yet, of course we can see that these two options aren't similar at all.

4. Considering time-to-value, or effort vs reward. This fits with the intuition that works in everyday life: namely that if we spend time on things that help us get results quickly we can create momentum. Then this forward motion — the visible output in the product world — makes everyone feel positive about keeping going. Unfortunately, in business (and perhaps in our personal lives too) this pattern steers us away from anything that looks like delayed gratification, so the really big projects never get started. A tip to the would-be prioritiser is to ensure that, if possible, projects under consideration are cut down to a similar size. We've got an international army of agilists to thank for reminding everyone that smaller, bite-sized bits of work are less risky and carry less assumptions, making them easier to pivot from.

It's not a solve-all solution to use any of these tools. Once the broad intent is known they can help. But the complexities of real businesses with multiple challenges, opportunities, and timeframes, mean that rarely can you rely on the tool alone to decide for you.

If you're making Level 2 decisions in isolation while feeling that something is missing, you're probably right. That's where Level 1 comes in.

Level 1: Prioritising from the top

Level 1 — deciding what capability we need next — is very difficult. Any choices at this level will not be solved by one of the prioritisation techniques listed above. In fact I'm yet to find any silver bullet here at all. It's hard because you generally aren't choosing between similar goals. How do you compare an apple and a duck? They will cost different amounts, offer different types of return, and have varying levels of risk. Here are a couple of scenarios:

1. Path A is almost certain to deliver a 5% uplift in revenue on your core product next year

2. Path B has a small chance of establishing a new product line, worth as much again as your core product in five years' time

On a simple spreadsheet showing risk-weighted ROI, the "rational" approach will be to pursue A. But discontinuous — step change — innovation is generally found in path B. This is the so-called Innovator's Dilemma outlined by Clayton Christensen in the book of the same name.

Christensen observes that "it is simply impossible to predict with any useful degree of precision how disruptive products will be used or how large their markets will be". And worse still, even if there is some confidence about the experimental new product line, small markets don't solve the needs of large corporations to maintain large growth rates; in other words: the larger the company, the bigger the opportunity cost of diverting resources to a small new venture.

Another challenge — very common amongst enterprise SaaS companies with market-dominant customers — looks like this:

1. Path A will deliver something that you know will delight a long-term large customer

2. Path B will allow you to service some new customers

Again, a risk-adjusted economic assessment is likely to choose A. And the advocate is likely to remind everyone of the adage that it's better to keep a customer than acquire a new one; especially if you have a good relationship with them and they are worth a lot, which they almost certainly are if the organisation is considering them at the level of your corporate goals.

Conversely, a different type of company might legitimately pursue Path B. This time the advocate might say that it's the right approach because "we're a product-oriented company".

Both can be right. So how do you decide between these two apparently reasonable options?

This will not be solved using one of the 'prioritisation' techniques that we visited for Level 2. A scoring system or a forced ranking will just show what you've asked it to. If you upweight customer satisfaction, then — surprise, surprise — activity that supports that will win through. On the other hand, if you upweight publicity, you might find that the AI or ML project tops out. This is fine. You've got what you asked for. But it begs the underlying question: what's most important?

And here's the big difference:

In the case of Level 1 prioritisation, executives must take responsibility for making decisions. If they step away from this critical task, they abdicate their duty. Handing this task to a product manager is setting them up to fail. Strategy and vision must be top-down for it to be prosecuted across the organisation. Without this endorsement and commitment, disputes will break out, and the product manager is ill-equipped to play referee and team captain at the same time. The idea that big picture Level 1 (capability) priorities can emerge by a kind of capillary action from Level 2 (feature) priorities is a dangerous fantasy. Saeed Khan has described using these types of frameworks as "a bottom up mindset", when to solve strategic questions what you need is the opposite. He continues "In reality, prioritisation starts with objectives and strategy" — in other words, what I'm calling Level 1. Skip this step and it's going to end badly, especially for the product manager.

What does a Level 1 priority look like? It's a decision to build a capability, to invest in a team or function, to pursue a general course of action. It may be informed quantitively or qualitiatively. For example, in the event of data-rich environments, financial analyses like net present value (NPV) can be used to inform choices. But frequently at this level, imperfect data is available because we are dealing in counterfactuals or at best, well-informed assumptions. I'm not sure if Apple did an NPV calculation on the iPhone before committing to it but I am certain that it wasn't the deciding factor. The story goes that the iPhone became a priority at Apple (yes, not the only one) as soon as it became apparent that portable music players would eventually converge with phones, thus killing one of Apple's major product lines. Armed with the insight that the iPod was only ever an interim technology — combined Apple's evident skill in designing discontinuous category-defining innovations — the decision to pursue the mobile phone became clear. The choice was a matter of strategy and vision, whether quantified or not.

Unless your firm is tiny, then senior management should step away from Level 2 prioritisation. Chances are that head office executives are spending more time with investors, people management, and working on the business; than they are on products and typical customers, and they are therefore precisely the wrong people to make these decisions.

Connecting Level 1 and Level 2: prioritisation with guardrails

The articulation of strategy and vision — potentially made explicit through KPIs, goals, or the more fashionable OKRs — is how we connect Level 1 and Level 2. Ensuring that everyone in the organisation understands the Level 1 goals and priorities is essential if they are to act in concert.

By choosing capabilities to focus on, you make choosing features easier

I hope that everyone reading this has the opportunity to experience the joy of organisational alignment at least once in their career. When the gears of sales, marketing, product development, and operations are meshing smoothly, output has an outsized impact. Things get done, problems are manageable, and people have fun. This happens not because everyone is working independently; nor (conversely) because everyone is being told what to do; but because everyone is doing their bit within the guardrails set by the strategy. (I've written more about the benefits of alignment — here).

When this works, it does so because organisations understand the goals and then celebrate contributing to them. Without this, only delivery will be lauded — and when you're heading down the path towards a factory churning out widgets (or features) the prioritisation feels pointless, and it often is.

Product isolation is the wrong response

A dangerous alternative narrative has emerged recently which holds that product management should be isolated from the rest of the organisation, unencumbered from sales or finance, and "free" to make their own prioritisation decisions. Advocates of this approach have co-opted the term "empowered teams" from Marty Cagan's book Empowered, which it turns out, isn't saying anything of the sort. Cagan's thesis is about having the people working on the product engaged as early as possible in its design. They are responsible because they are involved and they are accountable. The act of empowerment gives them access to information, to customers, to the data that helps them make decisions. This is important, because, although it may sound like common sense, we all know that it's frequently not how product teams work. Sadly, we often see so-called product teams (and I'm using the term broadly here to cover technologists, BAs and so forth) who are order-takers or 'Jira munchers' tasked with ticketing up and executing explicit requests from dominant customers and/or senior stakeholders. But the uninitiated take Cagan's perfectly sensible observation, and take it to an extreme and ridiculous conclusion. An empowered team is not an independent team. It exists to serve the business goals. And where have they come from? Yes, you've guessed it, Level 1 goals and objectives.

Dealing with conflicting priorities

What about when Level 1 and Level 2 seem to clash? Because Level 1 is essentially top down and Level 2 is basically bottom up, it stands to reason that sometimes these won't meet in the middle. Prioritisation of all types can be viewed as an exercise in trade-offs. The concept of vision-survival tradeoff from Radhika Dutt is a useful way to think about what happens in real life, where something is done to keep hold of a client, or to keep us compliant; instead of something else that will build towards overarching goals and objectives.

Tradeoffs can be OK, but understand the consequences

It's not necessarily wrong, but it does have consequences. If sustained, these types of trade-off should be brought to the attention of those setting the Level 1 objectives. Ward Cunningham suggested that we use the word 'debt' to capture the idea that there are some tasks which, if unattended, will need to be addressed one day, and that the longer they are left, the bigger they would become.

While Dutt's conception leads to 'vision debt' a more common term these days in software businesses is 'tech debt'. As a description it's accurate, but it may trick people into dismissing the debt as the responsibility of a "technical department". In fact it is appropriate for sustained tech debt to appear on the Level 1 radar, since addressing it may require the type of whole-of-company commitment that can only be achieved at this level. As Dave Mangot has observed, "If we know that tech debt is causing the problems listed, but choose to do nothing about it, that is a business decision".

Have your cake and eat it, in parallel.

The have-cake-and-eat-it scenario, which I alluded to above, is to set up parallel teams. At Level 1 this is different business units (iPhone, iPad, Airpods and so on); whilst at Level 2 it's focused squads or teams, or even individual specialists. Going right back to Adam Smith's 'division of labour', we have known the importance of specialism and focus for 250 years: letting a UI problem slow down a devops issue makes about as much sense as switching the painters with the metalworkers in Smith's pin factory.

In modern software, a common patten at both Levels 1 and 2 is to split out business-as-usual from new product development or innovation and let each do prioritisation on its own. There are other good reasons to do this: the innovation team may need to operate with different levels of risk and robustness than the team servicing your core offering. This is the definition of the skunkworks concept. In a modern software business, depending upon circumstance, some teams may operate in a lean or agile manner, while others are more waterfall and cautious. For instance, a team running a critical patient system within a hospital has limited scope to 'test and refine' while another team developing a new procurement system may be less worried about breaking things if it helps them test quickly.

But beware, parallel teams means that you have, at some level, split the total resource pool between multiple projects. (Remember, the pedant who says 'you can't have more than one top priority' is always right at some level). While parallelising can be beneficial if you can create progressive wins from each stream, if everyone just waits longer to get everything done, then it will fail the stakeholders of every initiative.

Avoiding hard decisions is a terrible reason to parallelise. If you feel that it's just an exercise in people-pleasing, then stop.

On the other hand, parallelising to establish and maintain market position is the perfect reason to do so. To think about this, it's helpful to refer to the concept of the three time horizons which was popularised by Baghai, Coley and White in their book The Alchemy of Growth.

You'll need to consider all three horizons

The gist is as follows:

Horizon one is about what the organisation is currently known for — its focus within the present mature state
Horizon two is for new ventures
Horizon three are very early-stage ideas and concepts — which may or may not go on to become future revenue generators

A key conclusion from this model is that the well-performing business must simultaneously have an eye on each horizon. Putting aside the three-eyed metaphor, this has a clear implication for prioritisation that I think fits with our intuition.

Specifically the authors tell us that focussing on the now at the expense of the next wave means that we run the risk of "running out of steam"; while focusing on the future and neglecting the now (sometimes called 'bright shiny object' syndrome) means that unlikely to survive that long and "losing the right to grow".

While again the pedants are undoubtedly right that a single neuron or transistor can only work on one thing at that precise moment in time, when it comes to the company — the collective — this is patently untrue. The company must prepare for multiple horizons; and strategy and leadership must direct the company to do so. To focus on a particular timeframe (either short- or long-term) is to do so at the expense of others.

An often-cited adage is that a good leader can have several apparently competing ideas in mind at the same time. That is to say, while it is sometimes a source of power to be single-minded, to be single-point obsessed is naïve and dangerous. A good leader must articulate, sell and direct the implementation of the strategy across all its horizons.

Any decision is a good decision (almost)

A final observation. When I look back at all the times that prioritisation has been a big topic in a business or team where I'm involved, it has been at least partly neutralised by a decision being made. That is to say that it was frequently the indecision that was killing us, and being able to move on decisively was more important than the precise direction of the decision. There's nothing worse, nothing more demotivating, nothing more confidence-sapping than flip-flopping without good reason, and just delaying everything.

So to sum up: