Prioritization Happens In Layers
Hey Ant here 👋 I write a newsletter that won't go viral - and that's the point.
Because hot takes, clickbait and AI slop won't help you ship better products. But practical content grounded in real work will - the kind I do every day on my own products and the product leaders I coach.
Join 15,000+ product people who subscribe. Same applies to my YouTube channel!
Recent posts you might have missed:
- Escape OKR Theatre
- How product companies operate without BAs, Scrum Masters, Release Managers, etc
- You Don’t Need Another Prioritization Framework: Just These 4 Components
A first-principles look at why prioritisation frameworks often fail and what to practically do instead. Hopefully by the end of this post you won’t look at prioritization the same way.Most teams I work with don't have a prioritization problem.
They think they do.
Because prioritization feels hard; too many backlog items, competing opinions and goals.
So they revert to frameworks (WSJF, RICE, Cost of Delay, Scorecards, etc) but none of them work.
Because the fix was never a framework. It's fundamentally changing how you approach prioritization.
Prioritization Happens in Layers
Prioritization isn’t something that happens at the backlog level.
This is how the majority of PMs and teams operate.
They have this long backlog that holds every idea ever dreamed up, every bug, improvement, opportunity, etc and they try to prioritize it.
And when your backlog is 100s of items long it’s no wonder you’re reaching for a spreadsheet and formula to make sense of it.
But your backlog doesn’t operate in isolation.
You should have:
a roadmap that frames direction
goals that help you create focus
a product vision and strategy that helps you filter what goes into your backlog
Side bar: I sometimes wonder how much agile played a role here. Scrum until recently didn’t have product goals and most agile content often talks little about anything beyond your backlog. I experienced this first hand. My first introduction to product was in a scrum team and all we had was a long backlog and not much else.
These layers all require prioritization.
For example; you might need to prioritize one customer segment over another (think ICP; Ideal Customer Profile).
Or one outcome over another.
Or what problem to solve first.
Even in your product strategy you are constantly prioritizing. You’re trying to decide where to focus and what levers to pull.
So in reality prioritization happens in layers.
It’s something that starts at the top with your product vision and filters down.
When you do this effectively you won’t end up with a laundry list of backlog items because the layers above filter below.
This is where techniques like opportunity solutions trees from Teresa Torres are so great!
Because they structure your thinking into this mental model.
You need to start with an outcome ← therefore you have to prioritize one!
Map opportunities that align to that goal ← meaning you deprioritize opportunities that don’t align.
Ideate solutions that align to a chosen opportunity ← meaning that you need to prioritize opportunities before you prioritize solutions.
“A product team’s job is to create value for the customer in a way that creates value for the business. This is rarely done by fixating on a ranked idea list.”
Putting This Into Practice
When prioritization feels hard often it’s because you’re operating at the wrong level.
For example, you’ve probably been in this situation before: stuck between two competing priorities from different stakeholders. To make matters worse, they’re fundamentally different kinds of work.
A recent example I had with a client was one stakeholder was pushing for features to improve their broker portal, another pushing for a direct customer experience. Both are viable options for helping the business grow and win more customers but they’re fundamentally different segments, different goals and strategies.
In this case you will struggle to prioritize between them. Because they can both be rationalised through similar returns on investment, similar levels of complexity, impact, etc.
And more often than not they’re both priority #1 for their respective stakeholder.
So you get stuck in a stalemate.
But the fix isn’t trying to pick between these two - that’s what gets you stuck in the first place - it’s to move up a level.
You need to move to a level where we can have a constructive conversation between these priorities.
The question is really; what is more important to us right now? Growing through our direct to customer or broker channels?
It’s really a strategy and outcomes question.
Which means sometimes you’ll find you need to move up a few layers in the stack.
When you start to do this, the conversion changes.
It becomes (for the most part) far more constructive. Because you’re starting to prioritize at the right level.
It’s not this feature vs another, it’s which customer segment is our target right now? Which is higher leverage? Which is our strategy right now?
And when you can make decisions higher up in the chain, they flow down.
You can then look at your backlog through the lens of, ‘new user growth through direct to customer channels’.
Significantly cutting down your backlog to only items that fit in that lens.
This is why senior product managers start with strategy when it comes to prioritization.
Where RICE (and frameworks) fit in
So where do frameworks fit in then?
Does this mean RICE, WSJF, and frameworks like value-vs-effort scoring are useless?
Of course they’re not.
They just don't work when you point them at a 200-item backlog. That's not what they're designed for.
In fact, "Impact" in RICE is supposed to be the impact against your chosen outcome. So it’s meant to work within these layers, not without them.
Without a chosen outcome above it your Impact score is arbitrary, you're just making numbers up.
And this is where frameworks like RICE are supposed to be applied. They’re tools to help you prioritize within a layer - not across them.
For example, if you’re trying to pick which customer opportunity will have the greatest impact on your outcome, then RICE works very well!
What doesn’t work is trying to use RICE to compare customer opportunities to foundational platform work to technical debt and outcomes.
You’re just comparing apples to oranges at that stage. And prioritization frameworks are not a substitute for strategy.
The Right Tool For the Job
Another thing approaching prioritization this way does is it enables you to use the right tool for the job.
For example, RICE and opportunity scoring work well for opportunity prioritization because they’re built around customer impact.
However if you’re trying to prioritize foundational work, tech debt or platform type work, then cost of delay might be more appropriate.
Or perhaps you don’t think any fit perfectly to your context and you’re better off creating a custom scorecard.
Remember that frameworks are a tool.
They’re there to help you make a decision and that will need to adjust based on what decision you’re trying to make.
FYI I went deeper into how you should be adopting different prioritization frameworks in this live stream.
Putting It All Together
Prioritisation isn't one decision. It's a chain of several inter-linked decisions, each one narrowing the field for the next:
Vision: prioritizing where we’re going long-term?
Strategy: prioritizing the highest leverage problems to solve that will help us realize our vision?
Outcomes: prioritizing the measurable changes we need this see based on our strategy?
Opportunities: prioritizing which customer/market problems will drive the most impact to our outcomes?
Ideas: prioritizing which solution will best solve our chosen opportunity?
If you work your way through the stack, you’ll realize that 80% of the prioritization work is done by the time you get to your backlog.
Afterall, prioritization shouldn’t be hard. It’s only made hard because we skip these layers and try to prioritize at the backlog level.
So remember;
Approach prioritization as a layered activity
And anytime prioritization gets hard, move one or more levels up. Because more often than not, it’s hard because we haven’t resolved a layer above and we’re at the wrong altitude.
That’s it!
FYI if your team is stuck in this prioritisation trap and you want some help to get out of it, my upcoming Product Strategy in Practice cohort walks you through building the top three layers — vision, strategy, outcomes, if you can fix them you’ll make prioritization much easier.
Another option is we can work 1-on-1 together in the Product Mentorship.
If this was helpful, forward it to the PM who's been living in prioritization spreadsheets - they need to read this!
And as usual, thanks for the support.
/Ant
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…