How I Think About Prioritization

Perhaps you’ll agree with me that prioritization can often seem like an intimidating and sophisticated concept. It’s a widely used term and everyone assumes they’re doing it correctly. However, in reality, I’ve witnessed the prioritization process differ from company to company, depending on the team’s dynamics, preferences, and speed. In this post, I’ll share the prioritization framework that I follow, highlight what has been successful in practice, and suggest a few additional methods for those who want to explore further.

As Brandon Chu put it in Ruthless Prioritization, Product Managers are often prioritizing between:

Projects — What will we invest in next? What will have the greatest impact on customer value and business results? How long will it take the team to build?

Within Projects — Is this necessary to do? Can we still solve the problem without this? Whats required to cut the timeline in half? What needs to be done to double the impact?

We’ll start with prioritizing projects. To determine which project your team should work on you have to have a clear understanding of your North Star and Input Metrics. A North Star is a single metric that is used to guide decision-making. It should represent customer value and business results. North Star inputs are influential, complementary factors that you believe most directly affect the North Star Metric, and that you believe you can influence through your product offering.

For example, Ubers North Star is frequency of transactions (rides booked, meals ordered). Some North Star inputs might be:

• Search To Fill: Percentage of searches or requests that lead to a transaction.

• Time to Fill: Average time to pickup.

Once you have a grasp of your North Star inputs, including their current status and level of priority, you can start addressing the challenges that hinder searches from translating into transactions or rides taking too long. The following approach has yielded positive results for teams I've worked with. Something to keep in mind is that the meeting’s participants can impact its effectiveness, as having a representative from each team can promote collaboration and a deeper understanding, but it can also lead to too many voices. Do what feels right for your team. Drop all of the opportunities in a spreadsheet with four additional columns for Business Value, User Impact, Effort, and Total Score. As the host, you can then assess each opportunity and assign tags, such as “Dependent on X,” “Metric Mover,” “Customer Request,” and “Customer Delight.” The ultimate goal is to develop features that drive metrics, meet customer demand, provide delight, and generate revenue. Using tags can make it easier to identify standout opportunities.

To minimize bias, it’s best to have everyone in the meeting rate the opportunities beforehand and keep their ratings hidden. Before the session, ask all participants to send you their sheets and compile the results. You can also use the RICE framework, which includes Reach and Confidence as additional factors in the decision-making process.

Pro-tip: double the effort and halve the impact of any estimates, and you’ll be much closer to reality. — Brandon Chu

Having conducted this exercise on several occasions, we’ve generally achieved a consensus or arrived at a mutual understanding of the outcome. Perhaps it speaks to the shared understanding of our objectives going into the meeting. When stakeholders are well-informed about the rationale behind the North Star Metric and I understand how their performance is measured, there should be a general alignment of viewpoints. In cases where there are divergent opinions, it’s worth discussing and debating them to reach a consensus. This time invested in debate is valuable as it prevents issues from surfacing later on.

After completing the exercise, it’s essential to summarize the meeting and share the updated priority list with stakeholders. Make it clear that they have a specific period, until X date, to review and provide any additional feedback. Following that, you can proceed with building the Now, Next, Later roadmap and introducing it to the rest of the team. To ensure that everyone’s ideas and thoughts are heard, I recommend conducting a survey before the exercise to gather feedback from the engineering and design teams. This way, you can ensure that any valuable input is incorporated. Now, how do we prioritize within projects? And incorporate those nasty bugs that sneak up and try to slow us down?

When writing user stories in a PRD, start by tagging all of your stories with must-have, should-have, could-have, or will-not-have.

The “must-have” category requires the team to complete a mandatory task. If you’re unsure about whether something belongs in this category, ask yourself the following.

• What will happen if this is not included in the release?

• Is there a simpler way to accomplish this?

• Will we solve the problem without it? Will we solve the problem for 80% of users without it?

“Should-have” initiatives are different from “must-have” initiatives in that they can get scheduled for a future release without impacting the current one. For example, performance improvements, minor bug fixes, or new functionality may be “should-have” initiatives. Without them, the product still works.

Another way of describing “could-have” initiatives is nice-to-haves. “Could-have” initiatives are not necessary to the core function of the product. However, compared with “should-have” initiatives, they have a much smaller impact on the outcome if left out.

Lastly, will not have. This category exists to manage expectations about what the team will not include in a specific release. It lets the team know you’ve thought about it or you hear their feedback, but it’s not happening in this release.

After this exercise, take a break and do it again 2–3 more times and then share the PRD with stakeholders or anyone on the product team who will review for feedback. The questions to keep asking throughout the scoping phase are:

• What problem are we solving again?

• Whats required to cut the timeline in half?

• What needs to be done to double the impact?

Dealing with Bugs

Establishing a shared process and framework for prioritizing bugs is crucial to avoiding chaos. Without it, you're likely to end up in a tangled mess. To achieve this, I suggest scheduling a meeting with anyone who submits bugs and introducing them to a priority matrix like this:

To help your team better understand the priority chart, I suggest providing them with real examples from your product and communicating where they fall on the matrix. You can also give them scenarios and ask them to guess where they would land. Additionally, consider creating a slack channel called #product-support and setting up a form for team members to submit bug reports. The form should include a brief description, the product area, the affected user type, and the number of affected users. Depending on the rate of bug submissions, you can create a zap that automatically generates a ticket directly from slack. From there, a product operations member can review the bugs and move them to the appropriate section of your sprint board. To help manage this process, I recommend splitting the board into different sections such as Backlog, Scoping, Ready for Development, In Development, Prod QA, Ready to Go Live, and Live. An effective approach to project planning and maintaining velocity is to consider the level of confidence in both the problem and solution. If the problem is still an assumption, then it's best to move quickly to gain clarity. If the problem is known but the solution is still uncertain, it's important to focus on exploring all possible solutions and not become too attached to any one option too early. However, if there are no assumptions, then it's crucial to prioritize quality and take the time to do it right, even if it means taking the hard road.

Finally, Brandon emphasizes the importance of "The Time Value of Shipping." Meaning, software only generates value for customers once it's been shipped.

This concept is framed in the context of deciding whether to ship features that work for the majority of users, while holding off on updates that cater to the remaining minority. While there are advantages and disadvantages to both approaches, Brandon said "when faced with this choice I usually encourage teams to be ruthless and ship it." Here's why:

1. If customers knew the full context and could make the decision for us, the majority of them would want us to ship it.
   

2. In the long run, if a team consistently follows this strategy, the number of times a customer will fall on the good side of that 80%|20% will even out, and as a result, relative to a company that always waits for 100%, customers will get exponentially more value over time as the effect of constantly getting features earlier compounds.
   

Ultimately, I hope you find these frameworks valuable and applicable to your work. However, keep in mind that every situation is unique and may require some adaptation to fit your specific needs. Remember that priority can shift, and it's okay to re-evaluate and adjust as necessary. Don't be too hard on yourself and be open to the idea of rearranging your priorities when needed. Most importantly, communicate your decisions and progress transparently with your team and stakeholders. Building in public can foster accountability, collaboration, and ultimately lead to a more successful outcome.