- The Tech Impact Uplift
- Posts
- A Simple but Impactful Way to Prioritise
A Simple but Impactful Way to Prioritise
Rolling Prioritisation - A Better Alternative to OKRs

Hey there, product development enthusiast!
Welcome back!
In the previous issue of this newsletter, I talked about the shortcomings of OKRs and how to avoid them. But there is a simpler and - in my opinion - better alternative to prioritise and plan initiatives. So let’s look at how prioritisation could work easier and better.
Let’s dive right in!
Good Prioritisation
When I am claiming a “better” methodology - what does good look like in prioritisation?
A prioritisation method should have the following qualities:
Focus: It might seem obvious that a prioritisation method needs to bring clarity and focus on what to develop - and also what not to develop. However, as I explained in my post about OKRs, this is not always the case.
Agility: As disruptions come our way more often and faster, a prioritisation mechanism needs to be able to adapt to changes. You need to be able to react to Covid, or AI etc. - and not only in the next quarter.
Global: Disruptions typically mean you have to change your products substantially, maybe even your business model. That will involve many units of your organisation. But also in general, real innovation stems from overarching changes, not from small optimisations. Thus, your process needs to support initiatives across org units.
Lean process: Last but not least, the prioritisation process needs to be efficient and not locking up your organisation.

A Simpler Approach
To do prioritisation in a simpler way than OKRs, that fulfils all of the above criteria, you can combine two things:
A backlog approach
A product development methodology
Both are good things to have, but combined, they can form a mighty prioritisation methodology.
The backlog is where you manage all bigger product initiatives. Typically this is filled by the product management within your organisation. The product development methodology then is used to turn this backlog into a kind of funnel of initiatives.
This whole approach I like to call “Rolling Prioritisation”.

Rolling Prioritisation
The product development process is used to drive these initiatives in the backlog from early thoughts to a point where they are ready to be prioritised and implemented. Such product development methodologies could, for example, be the Working Backwards methodology invented at Amazon, Design Thinking, or the 4D methodology.
The whole process consists of 5 steps:
Collecting ideas: Start adding ideas to the backlog by identifying customer problems and the estimated rough benefits of solving these.
Refining: Then refine the initiatives by designing solution approaches (initially UX-focused, followed by technical designs), understanding necessary contributions and dependencies within your organisation, creating rough effort estimations, leading up to approximate milestone planning. This is a process during which you drive up clarity and “implementation-readiness” of your initiatives.
If during that process, some ideas turn out to be not that impactful or too costly or less attractive for any reasons, dismiss them as early as possible.Similarly, decide how quickly you drive each forward, based on the early impact estimations.
During the refinement of an initiative, clarity increases - from understanding the customer problem to creating a milestone plan for execution.
Prioritisation: While the initiatives matured, also their priority became clearer. That can and should include the by then created clarity around effort and benefits, but also necessary contributions and dependencies. For initiatives ready for execution, do a final prioritisation.
It is sufficient to do this prioritisation anytime you are about to do the next step.
Starting an initiative: Start the highest prioritised initiative whenever you have the necessary capacity to do that. Typically, this happens when implementations of previous initiatives finish. But it can also be when e. g. a pandemic hits and you stop running initiatives to free up capacity for urgent new ones.
Delivery: The delivery itself then starts based on all the discovery and design done before and with the ensured capacities to fully deliver. This means you make a well-informed decision before you invest your precious delivery capacity. Because you ensured the availability of all needed contributors, you reduce the cost of delay that normally happens, when an initiative is nearly done, but is delayed waiting for some dependency to complete their work to go live.
If you are lucky, delivery goes as planned in the roadmap. But life happens and one key insight that led to agile was, that you cannot plan everything in advance. You will always learn new information while executing. The benefit of this rolling prioritisation is that a delivery can take longer. Start the next highest prioritised initiative from the backlog only when the necessary capacity is available. But if some ongoing initiative takes much longer, you can also stop that initiative if the effort-benefit-ratio becomes too bad.

Ideas are collected in a backlog. They are refined through a product development process, increasing clarity and informing relative priorities. Less valuable initiatives should be dismissed. The refined one with the highest priority can be started once capacity allows.
Criticism
You might argue, that this approach resembles project management more than product management. This is a fair observation.
However, according to my experience, most organisations are missing specifically this part. Their ability to deliver meaningful big initiatives, that really make a difference, is limited by self-organising, small structures that do not perform well in coordinating overarching initiatives. Rolling Prioritisation fixes that.
But of course, you also need to bring longer-term product management into the picture. For example, if something was launched through such a big initiative, you afterwards need to spend time on iterating and improving it to e. g. optimise the product-market fit. In order to do so, only a part of all teams’ capacity should be consumed by delivering big initiatives. Other capacity needs to be reserved to work on local optimisations and ongoing product development. This is a tough balance to find, but it’s crucial.
Benefits
Using this Rolling Prioritisation fulfills the requirements towards a prioritisation method discussed above:
Focus is maintained by limiting parallel initiatives to available capacity.
Agility is given because you decide prioritisation and the actual start of the delivery at the latest possible moment in time, when you know the most.
The approach supports global initiatives as it coordinates dependencies and timelines of all contributions, minimising cost of delay.
It is lean, because it eliminates unviable ideas early, ensuring full effort is invested only in initiatives which really get delivered.
What to Watch Out For
The identification of ideas in step 1 and their refinement in step 2 are key parts of a product delivery methodology. They are actual work and thus require actual efforts. Step 1 requires user researchers and product managers, while step 2 involves designers and engineers.
I definitely recommend having people from these functions taking ownership for driving the ideas forward also before the start of delivery. E. g. a product manager to be responsible for the overall discovery and product solution design, a principal engineer for the technical solution design etc.
Wrap-Up
That’s it! This is an alternative to (and much more than) OKRs. I experienced the Rolling Prioritisation as super productive in Zalando. It makes sure that you invest your capacity into the right customer problems and that you can successfully execute and bring these initiatives to life. With basic concepts like the backlog approach, I find it simpler than OKRs, yet much more useful.
What are your thoughts on this? Have you experienced other methodologies you can share? I appreciate every single feedback I receive.
And now - I wish you a very good start into 2025 (I hope it is still legal to say that 😉)!
All the best!

Jan’s Knowledge Nuggets 💡
In this section I share knowledge nuggets that will further help you to increase the impact of your tech organisation.
Scott Belsky’s predictions for 2025: From DIY software replacing commercial software to companies centered around data and computation, requiring humans only as stewards.
Financial education for tech leaders: In this training, the amazing Simonetta Batteiger provides valuable commercial skills to understand value for a company, balance sheets, and P&L. Essential skills for talking to your CFO.
Free workshop on how to build a second brain: The fabulous Sebastian Kamilli will do a free workshop on Wednesday how to leverage AI to step up your learning and creative process. How to sign up is described at the bottom of this post.
