You are doing product prioritization all wrong
Spotify pioneered, or at least evangelized, the product and development team structure used by most tech companies today. Each team is a self-contained unit with a product manager, product designer, and developers. They control their own roadmap with few dependencies on other teams. It allows them to go deep on their area of ownership and move fast. It also creates a deep sense of ownership by the team, especially for the product manager (PM). This structure is part of what has led to PMs being referred to as the CEO of their feature set. They can direct the priorities and resources as long as they drive the required outcomes.
I love this model and the ownership and the autonomy it gives, but there is a flaw…a giant flaw.
The Flaw
It’s several weeks before the next quarter starts and each team is thoughtfully refining their roadmap for the upcoming quarter. They are following all the best practices and have streams of data coming in from customers, sales, customer success, and support. They have been actively talking to customers and gathering quantitative and qualitative data. They are doing everything right. The problem is that they are doing it in isolation with blinders on. They are looking at the scope their team owns like it’s the only thing that matters in the world. As the “CEO” of their feature set, they are hyper focused on moving the metrics they own. The massive risk is that with each team creating their siloed priorities, the overall priorities might not be aligned with the most critical things customers actually need.
Per the visual below, each team plans their top few priorities and determines how much capacity they have to take on projects during the quarter.
But when you bring those priorities together and stack rank them by what is the most important to creating overall customer value and driving the company goals the picture can look more like this.
In this example, the top priority from Team 5 isn’t even in the top 10 overall. If you are ruthlessly prioritizing, you shouldn’t even start Team 5’s project until the other 10 are done or underway.
The other problem with the feature team prioritization approach is that in aggregate the combined roadmap tries to tackle too many things. Because he team is trying to be aggressive and stretch, the combined stretch is often unrealistic.
“Complexity breeds chaos and disaster. Plans must be simplified so the team can execute.” Extreme Ownership by Jocko Willink and Leif Babin
The solution to this is a method I call “holistic prioritization”.
Holistic Prioritization
The research and analysis done by PMs to prepare for holistic prioritization looks very similar to what they would do for team-based prioritization. PMs work through their backlog and consider new ideas, gather data, and get customer feedback. But then the two methods diverge.
In holistic prioritization, PMs, product design (team lead or the entire team), and engineering (head of engineering or other dev leaders) meet together to stack rank the most important problems to solve for the company. This can be done through design thinking tactics like putting ideas on a board using stickiness and then voting with stickers. Or you can plot ideas on a 2x2 matrix such as business value vs customer value. Or you can use the RICE score method for prioritization (Reach, Impact, Confidence, Effort). Basically, use whatever prioritization method works for you — the most important point is that you are prioritizing the most critical items across all the teams and not siloed within each team.
But now you potentially have a new problem. What if the priorities don’t directly align with your resources per team?
Resourcing the Priorities
If you are truly committed to solving the most impactful customer problems then you also have to be committed to allocating resources to solve those problems. We call this approach “swarming”. The feature teams still maintain their feature ownership, especially for addressing bugs in the product, but then you will shift the roadmap focus of the teams to the highest priorities. For example, Team 4 might swarm with Team 1 to accelerate the efforts towards the highest priorities. This takes some coordination among PMs, designers, and dev managers, but if they are all committed to solving customers’ problems then they’ll be able to figure it out. It tends to work best if you give each PM and dev team separate and discrete problems to solve. Too many hands in the pot solving the same problem can get messy.
The Spotify model is powerful, but it’s not perfect. If your teams are cranking out features, but your most important metrics like growth, expansion, and retention aren’t increasing at the rate you expect, then you might have a siloed prioritization problem and holistic prioritization could be the answer for you.
