There are many forms of prioritisation frameworks. https://www.productplan.com/learn/product-management-frameworks/ gives a good overview of the different available frameworks. I’m not going to attempt to create my own. To be honest, i tried, but when your formula involves the use of logarithmic functions, you know you got it wrong.
To caveat, this article describes my thoughts on a framework for incremental leaps. Non-incremental product innovations e.g building a rocket to Mars or designing a meta verse, probably require a more radical, conviction-based and vision-focused framework of thought.
So for me, a solid incremental framework for product prioritisation should cover the following attributes:
- Simplicity: Making it simple allows stakeholders to understand how decisions are made
- Value-Focused: All products are vehicles to deliver value (scrum). Focusing on the impact and reach empowers the organisation to make customer-driven decisions, rather than effort-driven or politically-driven decisions
- Timeboxed: Thus allows a consistent constraint to the value context. Given unlimited resources and time, most features become useful. the crux is to get it useful ASAP.
unsurprisingly, my favorite framework thus far is RICE by intercom.
RICE is a fairly simple and communicative framework developed by the folks at Intercom. It’s based on four factors:
REACH is measured in number of people/events per time period. That might be “customers per quarter” or “transactions per month”.
IMPACT is difficult to measure precisely. So, I choose from a multiple-choice scale: 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and finally 0.25 for “minimal”.
CONFIDENCE is a percentage, and I use another multiple-choice scale to help avoid decision paralysis. 100% is “high confidence”, 80% is “medium”, 50% is “low”. Anything below that is “total moonshot”.
EFFORT is estimated as a number of “man-hours” – the total manpower and time it takes to COMPLETE the feature
The formula is
Yes, it’s arbitrary. it’s more an art than a science. This is partly why simplicity is important. I see it less of a definitive tool, but a tool to facilitate discussions.
“why would the confidence of product delivery be so low”
“why would you need so much effort”
“how did you justify the reach and impact of feature A compared to B”
it allows for conversation to happen. but it also allows for calibration. Product features can be reassessed with a consistent framework regularly.
When building products, there are generally two dimensions of a feature: Type and User.
- Features: New requirements that will roll out to the internal or external customers to enhance their experience of the product
- Fixes: Updates/upgrades of an under-optimised or broken feature that is currently affecting the product experience
One unfortunate situation is that RICE favours features over fixes. To clarify, small fixes tend to be neglected because their reach and/or impact is small.
Note however that bugs exist in your systems, but planned features do not. This means that bugs, no matter how small, then to accumulate into tech debt. And like real insects, a couple of ants aren’t an issue, but an amy of ants can be a sticky situation.
This might not be a blatant issue with RICE, but the practical recommendation would be to set aside a portion of your sprint and product backlogs to cover bug fixes regularly.
- Internal Users: Users within your direct organisation
- Customers: External users who use your product directly to derive or deliver value
- Beneficiaries: External users who do not use your product directly but enjoy derivative value from them
Practically speaking, you are likely to have a lot more customers than internal users. For anything other than an angel stage startup, your internal users’ REACH is going to be minuscule compared to the customer. Most likely their concerns will never be addressed.
There are probably more ways of addressing this, but here are two possible approaches.
- Different prioritisation boards
For SCRUM folks, I’m not saying you need to use different product backlogs. I am saying that when building the backlog, consider the order of the feature, rather than just the pure scores. e.g add the top two items from each prioritisation board into the top of the product backlog.
Of course the more ideal model would be different teams working on distinct products eg a customer growth focused team and a ops focused team. but not every organisation can afford this.
- Convert this to a common customer REACH/IMPACT score
Many ops work translate to a customer impact. eg better logistics management can lead to better customer satisfaction. You could try to do an estimate.
in my opinion, this helps align the team on a customer centric approach, but adds a lot more uncertainty and subjectivity to the equation. Also, not every internally focused feature translates to customer impact. Automation to reduce manpower cost may have no direct customer impact.
Well, i’m going to use it. You should give it a shot. if you have a better one, i loved to know! ping me up on linkedin https://linkedin.com/in/aaronstevensonlee