We’re all familiar with the popularly adopted RICE framework which teams, product managers use to prioritize quarterly and annual roadmaps. While a handy and easy to understand tool the application of the tool often misses key contextual aspects and the required depth to make high quality prioritization decisions.

I’ll call out a few gaps that might arise from RICE:

#1 Time horizons

Impact should be framed in terms of time horizons. Initiatives can take time to mature, show sustained and long lasting benefits. Imagine an initiative that requires improvements to retention, loyalty or a new business line. Keeping an artificially short time frame can over emphasize the value from incremental improvements because those could potentially materialize impact sooner.

Solution: Consider using multiple time horizons for impact or based on your organization’s or team’s operating culture pick a time horizon appropriately. Possibly generate multiple RICE scores for each initiative to get more nuanced decisions.

#2 Total Cost, not just “Effort”

Projects go beyond just the cost of development, they need to be maintained, tracked, improved upon. A new feature shipped to a customer might come with significant customer support costs too. It’s important to consider the overall impact of a project to the dependencies in all directions - upstream, downstream and sideways. Often time prioritization is done without considering the total cost of ownership / total cost of development and a major contributor to bloat, high KTLO (keep the lights on) workloads and ultimately a poor end to end customer experience. Beware that one team’s choice could impact another in a material way.

Solution: Consider switching from effort to total cost and invite the dependencies (teams) and partner teams in estimating the total cost of ownership. Not only will those teams appreciate the input your decisions will be much higher quality.

#3 Importance and Urgency

Adding the dimensions of importance and urgency can elevate the quality of decision making. When something is urgent and important it is critical and cannot be delayed, evaluate what is the impact from this on the product’s long term success, the team’s health. We need to balance these out for the important but not urgent such that you’re not always prioritizing for those urgent. Planning wisely around using importance-urgency requires judgment and thoughtful considerations.

#4 Types of activities

Typically product teams have scope that covers maintenance, scoping new initiatives, identifying opportunities from customer feedback and product metrics, improving products live to customers, improving team operations, fixing tech debt/product debt and more. The importance and impact across the variety of these activities can be difficult to put a rigid rubric of prioritization around. How do you quantify these such that you can make an apples to apples comparison?

Solution: Consider carve outs for different types of activities vs trying to apply a precise math or estimates to quantify and fit scoring into a framework. These carve outs can serve as a healthier way to make sure teams are approaching the overall task of building product in a well balanced way. Often times teams can over index on certain activities (like building new features) and making sure to assess the spectrum what they spend their time with is important.

Conclusion

I hope it was useful to explore some of the additional factors and perspectives to consider at prioritization time. Comment if you have other thoughts and factors that matter and you’ve used.