Prioritisation & Prioritisation Frameworks
Good prioritisation will give your product the best chance of succeeding. A clear product strategy will guide your prioritisation. But how heavily should you rely on a prioritisation framework?
As a product manager you should be very selective about what is on your backlog. A bloated backlog becomes hard to manage, can cause confusion, offer false hopes, require more work to prioritise.
A clear product strategy should guide what makes it onto your backlog. “I’ll add it to the backlog” is a line that product manager’s use to appease stakeholders when they come with requests. But saying “no” (or not not) reduces conflict by facing into requests that don’t align with the strategy sooner rather than later, and makes prioritisation (with or without a framework) easier because you have less initiatives to prioritise.
If you have a clear product strategy, and well maintained backlog, how heavily should you rely upon a prioritisation framework?
Prioritisation Frameworks
RICE is a prioritisation framework I’ve used a lot as a product manager, and I’m going to use RICE as the example in this article.
If not you’re familiar with RICE, the framework creates a score for each initiative. Four factors are scored (Reach, Impact, Confidence and Effort) and then the RICE score is calculated by multiplying Reach, Impact, Confidence together, before dividing by Effort.
RICE Score = (Reach x Impact x Confidence)/Effort
In theory the initiative with the highest RICE score should be at the top of your backlog.
Creating Consistency Before Scoring
When I’ve used RICE I’ve set some standards before scoring the four factors to give consistency across each initiative and each time the framework was used. These are outlined before and are digital focused.
Reach: how many customers will the change impact?
Only purchasers
Customers at bottom of funnel
Customers at top of funnel
Most or all customers - fundamental experience or proposition change
Impact: how much to you believe the change will impact individual customer (or business) needs?
Minimum
Low
Medium
High
Confidence: Are confident are you in the scores based upon your data and insight?
High = 100%
Medium = 75%
Low = 50%
Effort: investment required from Product, UX, and Engineering, as well as any business teams
Very Small
Small
Medium
Large
I believe sizings larger than large start to become meaningless, and often mean that works needs to be broken down further.
Help or Hindrance?
Using the structure of a framework in a consistent way should help you to move away from guesswork. But does it help you to prioritise creating the most impact?
Imagine you’re working at retail company that sells and installs white goods like washing machines, and the pain point you’re trying to address is failed installations. A solution you’ve added to your backlog is adding new messaging on the order confirmation page. Reach scoring could ignore solutions aimed at purchasers (where the problem lies) over messaging to all browsers on the lister and product pages. As the product manager, you need to decide which change would be most effective.
There are good reasons to score impact as low or high depending upon on the level of change. For example, whole page layout change is likely in most cases to have more impact (good or bad) than a single word change. But do you need a framework to tell you the difference and potential benefits and risks of these changes?
The impact score is also very open to suffering from bias. Yt was my idea therefore it’s a great idea and I’ll score it high. Versus it came from a troublesome stakeholder (we all have at least one of those) and therefore it be scored low.
Confidence is also subjective, but this is where experience and product sense can come in. If you’ve made similar changes before or if you have a lot of data on something you can be confident that something needs to done. BUT if you’re scoring on whether to move ahead with a solution to a problem, can you be so confident in how you’re proposing taking action?
Similarly with effort, past experience with a product team can give you experience on an estimate of small versus large. But we all know that estimates are only estimates, and with dependencies, tech debt, and many more things, any piece of work can really become any size.
If you know that you don’t have much resource available, you may be thinking that there’s no point embarking on an initiative that is estimated to be large. At the same time, what if the initiative that is essential to delivering your product strategy and vision is a large? Would the RICE score deter you from taking action? Whether that action is starting work, selling the dream to senior management, and requesting more team members?
Key Takeaway
I’ve only talked about RICE but hopefully it’s gives some food for thought about relying too heavily on a framework. The context that you bring as the product manager is still essential to all prioritisation decisions.
Good prioritisation starts with a well managed backlog that only contains initiatives that align to your product strategy, and you may find that as you gain more experience in product that you use prioritisation frameworks less and less, and start to rely on your knowledge of your product, customers, organisation and market.