*“The main thing is to keep the main thing the main thing” — Stephen Covey* One interesting aspect of the PM role is the connection between the PM’s ability to manage **their own time** and their ability to manage **their team’s time**. I’ve rarely seen a PM who struggles with prioritizing their own tasks and calendars be very successful in their career. They may get to some local maximum, leading small products or teams, but they will not scale to their potential if they don’t learn to prioritize themselves. As he often does, Shreyas has a system for this that’s worth exploring: [LNO Framework](https://coda.io/@shreyas/lno-framework). I’ve found it extremely important to align your 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](https://blackboxofpm.com/ruthless-prioritization-e4256e3520a9) - [ICE Scoring Model](https://www.productplan.com/glossary/ice-scoring-model/) - [https://www.productplan.com/glossary/rice-scoring-model/](https://www.productplan.com/glossary/rice-scoring-model/) - [https://cutlefish.substack.com/p/tbm-245-the-magic-prioritization](https://cutlefish.substack.com/p/tbm-245-the-magic-prioritization) & [Qualitative Cost of Delay | Black Swan Farming](https://blackswanfarming.com/qualitative-cost-delay/) # Key Concepts ## Return on Investment (ROI) I subscribe to many of the principles laid out in [Ruthless Prioritization](https://blackboxofpm.com/ruthless-prioritization-e4256e3520a9) 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](https://www.productplan.com/glossary/ice-scoring-model/), which is the little sibling of the more common [RICE framework](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/). 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: ![[Pasted image 20250831221803.png]] 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](https://blackboxofpm.com/ruthless-prioritization-e4256e3520a9): ![[Pasted image 20250831221816.png]] Other frameworks - [https://www.productboard.com/glossary/product-prioritization-frameworks/?](https://www.productboard.com/glossary/product-prioritization-frameworks/?) - [RICE: Simple prioritization for product managers](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) - [MoSCoW Prioritization](https://www.productplan.com/glossary/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*