How do you manage priorities in case of insufficient resources?
🛤 Mission Alignment
This exercise should help identify my capacity in critical analysis, decision making and strategy shifting by avoiding and/or maneuvering around ‘force-majeure’ insufficient resources.
🔬 Scope
Usually, a well researched, carefully planned, and agile built product should rarely fall into the ‘insufficient resources’ category. Therefore, for the sake of this exercise, I’m going to consider that the project was very well planned, however, due to a some force-majeure, we have a lack of resources. I’m going to consider multiple scenarios:
Scenario 01: lack of human resources (e.g: Developers)
Scenario 02: lack of financial resources
Scenario 03: lack of human & financial resources
Below, I will mention several prioritization techniques, and then will use the Eisenhower Matrix and its variations to tackle the above scenarios.
✅ Prioritization Techniques
A prioritization technique helps you know the importance of tasks and goals by providing you with a formal method for evaluating the necessity of completing each task on your list. The process of prioritizing lets you make informed decisions about what you need to do, what you don't need to do, and when you need to focus on certain tasks.
There are plenty of prioritization techniques, and I am going to list some of them in here, but focus on only one of them for this exercise.
MoSCoW (in combination with a KanBan view)
M - Must Do: M tasks are things we absolutely have to do.
S - Should Do: S tasks are things we should do, but they’re a lower priority than M tasks.
C - Could Do: C tasks are nice-to-dos. We’d like to do them, but if we don’t it’s probably not a big deal.
W - Won’t Do: W tasks are things that just aren’t worth doing.
ABCDE (Very similar to MoSCoW technique)
A tasks are things we must do (same as MoSCoW's M tasks).
B tasks are things we should do (same as MoSCoW's S tasks).
C tasks are nice-to-dos (same as MoSCoW's C tasks).
D tasks are tasks we should delegate to someone else (or automate).
E tasks are tasks we should eliminate (same as MoSCoW's W tasks).
Prioritization Matrix
The priority matrix technique consists of laying all of your tasks out on a four-box matrix. The x-axis represents one value, and the y-axis represents another. Each quadrant, then, represents priority based on the defined values.
It's a technique that's easier to show than to tell:
Bubble Sort
Bubble sort is a process for comparing the importance of every task on the list to the importance of every other task on the list.
Scrum Prioritization (Agile Prioritization)
In Scrum prioritization, we evaluate each task on our list using three criteria:
How important is this task?
How important is it compared to the other tasks on this list?
Is any other task dependent on this task?
Then, using the answers to those questions, we assign each a number 1-n (where n is the total number of tasks on the list). We can't have two tasks that are #1. We have to make one #1 and one #2. Every task gets a unique number.
RICE Scoring
Reach: to start, Reach helps us bring the focus back to the customers by thinking about how many people will be impacted by a feature or release. We can measure this in number of people in a certain period of time. So we can ask ourselves, “how many customers will this impact per month?”
Impact: now that we’ve thought about how many people we’ll reach, it’s time to think about how they’ll be affected as individuals. To do this, we need to think about the goal we’re trying to reach. It could be to delight customers (measured in positive reviews and referrals) or reduce abandonment. We can use a multiple choice scale:
3 = massive impact
2 = high impact
1 = medium impact
0.5 = low impact
0.25 = minimal impact
Confidence: so much of Product Management has to be unscientific. Although data should be used as much as possible, sometimes we have no choice but to rely on intuition and gut-feeling.
A confidence percentage will help us with that. We can give our estimates a percentage to boost its priority-level when we’re lacking the data to prove its importance. We can also use it to help de-prioritize things we’d rather not take a risk on.
Generally, anything above 80% is considered a high confidence score, and anything below 50% is pretty much unqualified.
Effort: You’ll need information from everyone involved (designers, engineers, etc) to calculate effort.
In an ideal world, everything would be high-impact/low-effort. Although this is so rarely the case, it’s what we should be aiming for.
Think about the amount of work one team member can do in a month, which will naturally be different across teams. Estimate how much work it’ll take each team member working on the project. The more time allotted to a project, the higher the reach, impact, and confidence will need to be to make it worth the effort.
Kano Model
Delighters: The features that customers will perceive as going ‘above and beyond’ their expectations. These are the things that will differentiate us from your competition.
Performance features: Customers respond well to high investments in performance features.
Basic features: The minimum expected by customers to solve their problems. Without these, the product is basically useless to them.
The main idea behind the Kano model, is that if we focus on the features that come under these three brackets, the higher our level of customer satisfaction will be.
To find out how customers value certain features, we use questionnaires asking how their experience of our product would change with or without them.
As time goes along, we may find that features which used to be delighters move down closer towards ‘Basic Features’ as technology catches up and customers have come to expect them, so it’s important to reassess periodically.
👥 Scenario 01: lack of human resources (e.g: Developers)
In the case of the lack of human resources, we will use a variation of the Eisenhower Matrix called the ‘Effort-Impact Matrix’.
In the effort-impact matrix, we evaluate tasks based on how much effort they'll require to complete and the impact that completing them will have. The tasks in the two right-side quadrants are our priorities. "Low effort, high impact" tasks are likely our highest priorities because they represent quick wins.
💰Scenario 02: lack of financial resources
In the case of the lack of financial resources, we will use a variation of the Eisenhower Matrix called the ‘Value-Cost Matrix’.
In the value-cost matrix, the top two quadrants are our priorities. "High value, low cost" items are our quick wins, and "low value, high cost" items are things you should probably avoid doing.
⚠️ Scenario 03: lack of human & financial resources
If the project/product is lacking multiple resources, then we would prioritize using the actual Eisenhower Matrix.
We evaluate each task based on its urgency and importance and then place each task in the correct quadrant based on your evaluation.
Important and urgent tasks are our top priorities.
Important but not urgent tasks are lower priorities—things we should schedule for later.
Urgent but not important tasks are good candidates for delegation.
Not urgent or important tasks are things we probably just shouldn't do.
By placing each task on our list into a quadrant on the Eisenhower Matrix, we can determine what we need to work on now, what we need to work on later, what we need to delegate, and what we need to delete from our list.
🏟️ Conclusion
In conclusion, we’ve assumed that the product research and strategy were well planned, however the organization hit some force-majeure which resulted in a lack of resources. We’ve managed to express the different ways of prioritization that could be used in this situation. Nonetheless, we focused on the Eisenhower Matrix to tackle 3 suggested lack of resources scenarios.
Meanwhile, feel free to read the resources below for additional insights and information regarding product management prioritization.
Managing Priorities
