Question
What are the best ways to prioritize a list of product features?
Answer
I'll add one note here: good people with a bad process will outperform bad people with a good process every time.
While the processes and heuristics people have offered are all good (and I've used most of them off and on), I try to focus on the "good people" part as much as I can. This is because every one of those process ideas can go horribly wrong if they are in the hands of "bad people."
What defines "good people" is:
1. High situation awareness
2. A tendency to match or pump up the group energy levels to the level needed given the difficulty of the decision at hand, and suggesting tabling if everybody is in a stupid state
3. Sensitivity to how much others are on the same page ("shared situation awareness", and knowing when to let a difference of opinion "go" versus when to wrestle the difference down
4. Knowing when to pounce on somebody who is making a lazy, formulaic decision by using what I call "weasel heuristics"
5. A quickness in spotting exceptions ("management by exception" is generally a C-level idea, but I try to get my entire team to do exception-oriented thinking, as in "hey, waitaminute, I agree we need to focus on retention as the theme this sprint, but....")
6. Knowing which rabbit holes are worth going down, and which ones are merely a case of somebody posturing.
7. Being able to debate all the way from UX philosophy and design principles down to where to put a button
8. Courage in proposing radically different ideas when necessary that would mean throwing away completed work.
9. Being firm but gentle in pushing back when people exceed their expertise, and putting their input at the level it belongs, and applying the same rule to themselves. For example, I often pull back when I find myself offering too much excited button-level input, to the annoyance of my UX people...I naturally self-police and say something like, "alright, lemme reframe that at the level of the business KPI we are after, and you guys decide how to achieve it."
It is those creative "buts" that I especially look for. Usually a "but" means you can break a well-intentioned rule in a way that speeds things up.
10. Capacity to reframe things (or "refactor the backlog" if you want to use a developer metaphor). Knowing when a breakdown of features etc. is just inefficient somehow and reframing things so that the right things are highlighted, and the trivial stuff banished to the periphery. Usually this involves using astute insights from data ("look we are worrying about X a lot, but last week's traffic stats show that the real bottleneck is Y, so maybe...")
The best way to get these behaviors is to hire against them behaviorally. But people who are just unaware that this is the road to high-chemistry teams can be encouraged through positive reinforcement.
Prioritization is about managing people more than it is about managing ideas, and it isn't just the product owner or scrum-master who needs to worry about people stuff. Everybody needs to actively drive group dynamics. Get the group's head in the right place, and they'll pull off miracles even with a waterfall model. Take a group that violates all the above "goodness" criteria and you'll ruin things even if you follow Scrum doctrine to the letter.
While the processes and heuristics people have offered are all good (and I've used most of them off and on), I try to focus on the "good people" part as much as I can. This is because every one of those process ideas can go horribly wrong if they are in the hands of "bad people."
What defines "good people" is:
1. High situation awareness
2. A tendency to match or pump up the group energy levels to the level needed given the difficulty of the decision at hand, and suggesting tabling if everybody is in a stupid state
3. Sensitivity to how much others are on the same page ("shared situation awareness", and knowing when to let a difference of opinion "go" versus when to wrestle the difference down
4. Knowing when to pounce on somebody who is making a lazy, formulaic decision by using what I call "weasel heuristics"
5. A quickness in spotting exceptions ("management by exception" is generally a C-level idea, but I try to get my entire team to do exception-oriented thinking, as in "hey, waitaminute, I agree we need to focus on retention as the theme this sprint, but....")
6. Knowing which rabbit holes are worth going down, and which ones are merely a case of somebody posturing.
7. Being able to debate all the way from UX philosophy and design principles down to where to put a button
8. Courage in proposing radically different ideas when necessary that would mean throwing away completed work.
9. Being firm but gentle in pushing back when people exceed their expertise, and putting their input at the level it belongs, and applying the same rule to themselves. For example, I often pull back when I find myself offering too much excited button-level input, to the annoyance of my UX people...I naturally self-police and say something like, "alright, lemme reframe that at the level of the business KPI we are after, and you guys decide how to achieve it."
It is those creative "buts" that I especially look for. Usually a "but" means you can break a well-intentioned rule in a way that speeds things up.
10. Capacity to reframe things (or "refactor the backlog" if you want to use a developer metaphor). Knowing when a breakdown of features etc. is just inefficient somehow and reframing things so that the right things are highlighted, and the trivial stuff banished to the periphery. Usually this involves using astute insights from data ("look we are worrying about X a lot, but last week's traffic stats show that the real bottleneck is Y, so maybe...")
The best way to get these behaviors is to hire against them behaviorally. But people who are just unaware that this is the road to high-chemistry teams can be encouraged through positive reinforcement.
Prioritization is about managing people more than it is about managing ideas, and it isn't just the product owner or scrum-master who needs to worry about people stuff. Everybody needs to actively drive group dynamics. Get the group's head in the right place, and they'll pull off miracles even with a waterfall model. Take a group that violates all the above "goodness" criteria and you'll ruin things even if you follow Scrum doctrine to the letter.