Prioritization is Always Relative
When asking non-technical team members to prioritize their issues on an absolute scale I’ve noticed that they always classify their issues at one of the two highest priority levels.
For example, we track bugs in Freshdesk, so when a non-engineer finds a bug, they’ll file a ticket there and then I have a Zapier hook set up to push those new issues into Trello. Team members can select a priority level from the following list:
- Low
- Medium
- High
- Urgent
If a bug is marked “Urgent” that means I should probably drop everything and address it, otherwise I can wait until the end of the day to triage “High” priority items, or our next product meeting for Medium and Low priority issues…at least that’s how I intended it to work. After a few weeks of this, I’ve noticed that my team members — all wonderful, normal, and rational people — mark almost everything High or Urgent, even when they’re definitely not.
For example, last week a feature request was submitted by someone on the team to remove a text input box from a page. Simple enough request, but we had had the text box there for months, so I wouldn’t expect there to be a reason to drop everything and remove it. It was marked “Urgent.” When I grabbed another team member to follow up, they responded, “Oh no, don’t remove that! We need that.”
Clearly if the box was treated “urgently” and removed today there would be problems with other members of the team. I marked the issue Medium priority — meaning that we would discuss it at the top of the next product meeting to let all team members know why the change was being requested — and moved on with my day.
What is relative prioritization?
Above was an example of absolute prioritization gone wrong. Because team members feel the only way to get their issues noticed is to mark them Urgent, everything becomes “urgent.” In reality, we can only do things in relative priority to other things.
For example, if you gave me a list of 10 “Urgent” bugs to fix, I’d still have to put them in some sort of order before fixing each one. If I had 10 engineers, I might be able to distribute them and get a few done in parallel, but it’s more likely I would pair them up to tackle each bug one at a time.
In product meetings, we prioritize things relative to one another, and we rarely argue about what’s really important. This bug that’s preventing two users from doing a third tier feature is obviously less important than the bug that prevents users from submitting payment forms, right? Everyone agrees, and we put the bug with the bigger impact above the one with a smaller one.
This is relative prioritization, and it works really well. Absolute prioritization does not. Even with training, it’s easy to see why every team member - jockeying for their own interests - will eventually fall into the bad behavior of classifying every one of their issues as the highest priority.