Prioritizing your monster product: a framework for prioritization

Why this matters

Prioritization is hard. It becomes even harder when a product has been around for a while and has numerous sometimes questionable features — I’m calling these Monster products. If you have one of those, you know it. If you don’t have one, you’re lucky, but you will inevitably inherit one through your career. Additionally, if you know how to make prioritization decisions for a monster product, then you can make them for anything and everything else.

The making of the monster

Before learning how to deal with monsters, we need to understand how monsters are made. They are made in a variety of ways. Still, one consistent theme I’ve observed is monsters being created by teams and product managers saying yes to every request and every need, and not considering the impact that those can have on the product.

Strategy pixie dust

Strategy is about saying no. It is about what you choose not to do, but saying no, in general, is extremely hard. Saying “no” as a product manager is even harder given a core part of your job is to:

• Lead without authority
• Influence decisions
• Build relationships
• Collaborate
• Work with other teams

Vision is not a strategy. Vision is sexy, exciting; it makes people get up in the morning and go to work. Vision is really important since it gives teams a north star of where to go, but vision is not a strategy since it does not map out what you should and should not do to get there.

To execute on your vision and develop strategy, here are a few pre-prioritization steps to ensure that your team is well equipped to make prioritization decisions:

Clear business goals: unfortunately, a lot of teams do not have these. As a product manager, you’re responsible for extracting those from your leadership and ensuring that they are communicated and executed upon. Otherwise, your job becomes very difficult since you won’t know how to align your OKRs with the one thing that matters to the company the most.

Objectives and Key Results (AKA OKRs): team-level objectives and key results — if you want to learn more, my favorite resource for this is Radical Focus.

Jobs to be done: a clear description of the motivation, situation, and need that your users have — my favorite resource on this is: Intercom JTBD book.

Prioritization framework

This framework is not about getting to the right answer. It is a placeholder for a conversation with your multi-disciplinary team (at least engineering, product, and design) as a guideline and a way to facilitate collaboration and ensure that there is consistency in the decision-making process. It ensures that you consider different aspects of the strategy in your prioritization decisions because we want to be able to, in an unbiased way, eliminate the things that are the least valuable.

The framework considers the reach, customer impact, business impact, opportunity cost, confidence, and effort to prioritize the different jobs to be done that your team is considering executing on.

Breaking down each one:

Reach: number or percentage of customers that would be positively impacted/would be able to leverage this feature

Customer impact: buckets of how this would impact customers. Customer impact is hard to measure and different for each industry, so I recommend breaking it up in smaller buckets and spending time with your team and leadership, figuring out what customer impact means to you. For my current team, speed to value and security are extremely important ones, so we evaluate the impact in these areas, amongst others.

Business impact: how the outcomes tie to the OKRs that your team developed based on the company’s business goals. This will signal to you if this outcome is something the business is currently prioritizing or if it’s not a current area of focus. This will drive conversations if your team should act on it or not and if it is time to reassess the business goals. To achieve this break out your OKRs into buckets and assess if the need fits within them or not

Opportunity cost: estimates the cost of not solving this need. Strategy, as mentioned before, is about what we choose not to do, so it is crucial to understand what would happen if your team decided not to solve this need. I also recommend to break down buckets for opportunity cost. Common ones that I’ve seen work are: rise in support cost, risk of losing customer, external perception cost, risk of losing a deal, escalation costs. Pick the ones that make sense for you

Confidence: this means how confident you are that this will solve a real problem the right way. You can only have confidence by validating this with real users, and you can never be 100% sure since features tend to perform differently in the wild than in usability sessions/user interviews. My max of confidence is always 90%, and confidence grows together with validating the need is with real users.

Effort: an estimate of how much effort it will take to solve for this feature from an engineering, design, and product perspective. We are used to estimating complexity on the engineering side, but to assess the total effort of solving for the need, it’s important to think across the disciplines on the team.

The Formula

The least important, yet always most anticipated part of the process. Reiterating one more time that the number is not what you’re striving for here and that you’re following this process to assess different ideas in a consistent way. That being said, this is the high-level formula that I use and would recommend:

When using this framework teams that I have PMed and teams that I have worked with, teams reported: higher confidence in what they were building, the ability to articulate why they made decisions, and feeling an integral part of the prioritization process. To prioritize and address feature requests effectively, check out Feature Requests that Don’t Suck. How do you prioritize? What works for you? I’m always looking to improve my process, so please share what has worked for you in the past and how you make decisions in a systematic way!

Want to learn with me how to do it? I’m launching a Cohort Based Class where we’ll work together live with a group of peers learning prioritization and solving your prioritization problems! I’m super excited to be doing this so join the waitlist here!