Why Prioritize?
When this question popped up during a workshop I held, I needed a bit of time to actually understand it, because at first glance, it's so obvious why we should prioritize. After all, it's the number one task of any good Product Owner, right? So it should be obvious, shouldn't it?
Turns out that this question is an extremely clever one, as it really captures the day-to-day struggles of many Product Owners. The background is simply the following: If everything is important and everything needs to be done, as it is promised, already twice delayed, escalations ongoing and so on - why should we bother prioritizing?
I have seen Product Owners throwing their hands in the air in despair, telling me that it's utterly useless to waste time prioritizing, they would rather focus on something else which brings more value.
So: Why should we prioritize?
If everything is important, nothing is
Prioritization is the number one tool for any Product Owner to keep the team focussed on what should be done and what can wait a bit longer. If we don't do it, we are not giving the team any direction whatsoever. Think about it: If everything is important, nothing is. A collection of 1 to 3 important items leaves you with little other choice than just focussing on these 1 to 3 items and get them done. But a collection of 10-20 important items gives you the freedom and curse of picking anything out there that you like and start doing something. And since whatever you have picked is not less or more important than anything else, you have no motivation to get it done before one of the other items - in fact, you could do them all in parallel!
There is more to prioritization than just value
When put like this, people usually quite quickly start to understand that if two things are equal in value, we should do the quicker one first and the bigger one second - the first one can then already be delivered and generate value - be it in a tense customer situation, or as a direly needed feature addition.
There are also other factors in backlog prioritization besides value. Here are some examples:
- Risk Reduction
- Cost of Delay
- Learning
- Uncertainty Reduction
- Synergy Effects for other tasks
No one needs two thirds of your stuff, anyway
There is a number from the early 2000s floating around which claims that back then, roughly 75% of the features in Word and Power Point where unused. I have no idea if this figure is correct, but with my experience as a Product Owner, I have no hard time believing that this is true. I would guess that roughly one third of the backlog actually generates value to an end user - and the other 66% percent are there because of countless other reasons.
Your job as a Product Owner is to separate the useful stuff from the white noise and prioritize it up. You should relentlessly remove items from the backlog if they are not clearly generating value, or replace them with smaller increments from which you can actually learn whether or not the underlying value proposition actually holds up. This is the core piece of Product Owner work: To make sure the top item in the backlog is an item which will actually provide value to the customer, quickly.