How to not be a prioritization machine
Co-written by Alexis* and Adrienne
In my first months as a PM, I* was more of a “prioritization machine” than a PM. Not in a good way. Engineers would ask me to help prioritize their projects, assuming that I had more context on what they should be working on. Sometimes I would spend the entire day answering questions about prioritization. I felt important -- after all, isn’t this what PMs are supposed to do? Take full accountability of a team’s decisions and outcomes? I soon realized that while I felt effective, I really was just stroking my own ego -- and if a teammate had to wait on my decision, I was the biggest bottleneck. Instead, I needed to design a way for teammates to feel that they had agency to make their own decisions.
Prioritization is one of those elusive tasks. There are many articles on prioritization: popular articles often tell you to calculate each feature’s Cost vs. Impact score or consider the Reach, Impact, Cost, and Effort (RICE). Despite all the literature online, people still frequently ask about how to prioritize well, which is a sign of a challenging problem. The issue with these common frameworks is that while they’re good for prioritizing at the task-level, they’re not always applicable for prioritizing at the roadmap level across projects. In fact, using these cost/impact frameworks will often lead a team to prioritize low-hanging fruits rather than drive real impact.
To address my problem, I created a team-wide prioritization guideline. The guideline would be anchored on two things: team goal and stage of the team. I would create a 3 bullet point prioritization guideline and get my team’s alignment on it. The guidelines roll up to the team goal (or set of goals), where tasks that contribute most to the team goal usually get higher priority. The guideline also takes team stage into consideration: you might have one team that is focused on a high-profile product launch, while another team might be more focused on sustaining consistent growth. The guideline should prioritize projects most critical for the team's success for that stage.
Here are some examples of prioritization guideline considerations based on the stage a product team is in:
These guidelines can get out of date throughout the year. I set a new prioritization guideline every 3-6 months during the company’s quarterly roadmap planning. I will also regularly update the team with important new learnings or developments at the company, so that the teammates have appropriate context. Using this guideline, teammates can confidently make their own prioritization decisions to unblock their work even without a PM around; and because all the decisions come from a single guideline and source of truth, they’d generally arrive at the same conclusion a PM would have arrived at anyway. Teammates also know when to bring a decision up for a discussion, which is when the guideline doesn’t provide a clear cut answer. I found that once I set this prioritization guideline in place, development velocity increased, I had more time to focus on longer-term strategy, and the team even identified things that should be factored into planning that I wasn’t even aware of.
The risk of not prioritizing well is that you don’t go as far with your limited resources, or end up building an inconsistent Frankenstein product that confuses users. When you empower your team to prioritize themselves rather than being blocked on you, not only is your team able to move faster, but you also have time for more critical responsibilities like making a difficult prioritization decision that involves multiple stakeholders or thinking about how to reach longer-term product goals.