Sean Horgan

Updates

Explore

Practice of Product

On Prioritization

Sean Horgan

Last edited 24 days ago by Sean Horgan

“The main thing is to keep the main thing the main thing” — Stephen Covey

I’ve found it extremely important to align as a team on a rubric for prioritization that is used across all planning artifacts. One of a PM’s most important responsibilities is to set clear priorities and stack rank the problems and solutions the organization is working on.

References

⁠

Ruthless Prioritization⁠

⁠

ICE Scoring Model⁠

⁠

https://www.productplan.com/glossary/rice-scoring-model/⁠

⁠

Key Concepts

Return on Investment (ROI)

I subscribe to many of the principles laid out in

Ruthless Prioritization⁠

as it accepts the chaotic nature of building product by grounding decisions in ROI. The simplest way to understand ROI is to list out the costs & benefits and as you start doing that you’ll see opportunities to create more structure that will make it easier for quantitative analysis.

Scoring Models & Frameworks

I like the simplicity of the

ICE Scoring Model⁠

, which is the little sibling of the more common

RICE framework⁠

. There are many more complex models out there but it’s best to start small. In the ICE model you assess Impact, Confidence, and Ease on a scale of 1 to 10 and multiple them for a max possible score of 1000. Higher score = higher priority. Impact looks at how much the project will move the needle on the key metric being targeted. Confidence is the certainty that the project will actually have the predicted Impact. Ease looks at the level of effort to complete the project, with higher scores meaning easier to implement. Here’s a simple example:

⁠

Another approach is to agree on 2 axes that can be used to segment your work into Here’s a simple framework for triaging bugs laid out in

Ruthless Prioritization⁠

⁠

Other frameworks

⁠

https://www.productboard.com/glossary/product-prioritization-frameworks/?⁠

⁠

RICE: Simple prioritization for product managers⁠

⁠

MoSCoW Prioritization⁠

- avoid this at all costs. It should have stayed in the 1990s where it was born. Teams will only work on the “Musts” and it’s difficult to map these to business objectives across projects.

Principles

Timing is important. Often work starts out with one priority but they can quickly increase in priority as key milestones approach.

Teams need time to reduce all flavors of debt, e.g. product/tech/UX.

You need to demonstrate to your stakeholders that you can make progress on non critical work, otherwise everything will turn into a P0 as that’s the only way things get done. That doesn’t mean you force P1s or P2s into your work — just be mindful of the precedents you set across your organization.

Sample Rubrics

New feature development

Here’s a rubric that I’ve developed with teams over time:

P0 - mission critical

anything that compromises security of data or user information

blocks customer from a key value proposition in our product with no acceptable workaround

blocks a major revenue-generating deal from progressing in pipeline (e.g. >=$1M TCV)

critical market differentiator or critical feature gap with incumbent solution

work assigned this priority will get done, even if resources in or across teams need to be reshuffled to make it happen

Notes

P0 is not a 100% guarantee — we aim to complete >=90% of our P0 commitments.

If >= 20% of the work we’ve identified is P0, we’re probably not being honest with ourselves on the relative ROI and costs of the work.

P1 - high impact

clear demand signal from more than 1 customer from a priortized market segment

user can get job done but with some friction, e.g. takes extra steps, more time, or requires help from someone

feature doesn’t exist in incumbent solution

helps us validate a key value proposition

work assigned this priority will get done, even if resources within the team need to be reshuffled to make it happen,

Notes:

If we can't connect a requirement to a paying customer or a prospect on a 12 month horizon, it's max value is P1.

In our plans, we aim to complete <=60% of our P1 commitments

P2 - nice to have

A few customers have asked for this but we get mixed signals on importance

user can live without it but would be happier / more satisfied with it

Note: With our plans, we aim to complete <= 30% of our P2 commitments

Key Concepts

Return on Investment (ROI)

Scoring Models & Frameworks

Principles

Sample Rubrics

New feature development

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.