How do you prioritize?

Published on 29/04/2021

When you’ve been working as a product manager for a few years as I have, one of the questions that people ask you most is, “How do you prioritise?”. At first I was not sure if it was curiosity or just a general feeling that almost every individual has in companies: why isn’t the product team working on that important topic(s)? Then, I understood that behind the inquisition, some are very interested in the mechanism of prioritization (or product management) and others are just trying to figure out whether you’re just doing your job, but that’s part of the deal...

I’ve also had the chance to work with industrial product managers. They pretty much have the same problems. Whether your product is software, machinery, PVC pipes or food, in any case, it always feels like anyone can do this job. Nevertheless, it actually requires a very large skill set of surface knowledge to make your way through.

So do I prioritize? That is a very simple and very complex question to answer.

The short version? It depends.

On what does it depend? Company momentum, size, culture, product kind, user/clients maturity level, competition, current indicators, target indicators… many things.

The long(er) version? Stay with me...

Fundamentally, when people ask this question, they ask for a process. They think that if they understand the process, they will understand the “maths” behind the prioritisation. And therefore, if I am not respecting the prioritization formula: I am not doing the job right (or I am bad at math or both).

Bad news: there is no machine learning algorithm, JavaScript lib or math formula that you can take and plug to your backlog to list/sort/spit out the smartest thing to work on. And if there were, it would imply to define what “smartest” means in your specific context. Not to mention that context should also be defined...

I'm going to try to describe a process whose main goal, I deeply believe, is actually not to be a process. Constantly, you have to challenge that your non-process is still making its point.

People who know me a bit know that I am very much against (all kinds of) processes ; as their inaccuracy / uselessness / obsolescence / nonsense is as much probable as their possibility to actually be more of a social compromise than a real value-bearer.

“Why?” will you probably ask me? One simple reason: the only constant is change.

How to prioritize in constant change?

How to define a way to do things in a permanently changing context? How can you know if this is the best way? Even if you ask “Is this the best way NOW?”. There is a big chance that this moment will not last much. So, why trying to project ourselves in doing a work in some way, if the context implies to change the process repeatedly?

Therefore, the first is to accept that change. Give it a warm welcome once and for all and just deal with the fact that you will never know what is going to happen.

Most of the time, change is scary. Probably something that is deeply anchored in us and is, for some reason, the opposite of the Darwinistic adaptability. A testimonial of our core duality.

People try to reassure themselves with a process because a process won’t change (at least for a given period of time). As you can’t control the context, you control the process and feel secured. Also it can become a way to justify your choices/decisions or just your day-to-day job… “I respected the process”. This is a way of clearly claiming we live in an insecure environment or in a professional context where mistakes, failures and other joyful issues are not accepted/welcomed.

So, is making mistakes the point? No, obviously not. The lowest number of errors the better. However, some will pop. Therefore, when you try to prioritize topics in a constantly changing context, you should aim at making the smallest errors possible and avoid the biggest. Big errors are harder to change/fix/replace than the small ones ; especially in a very polymorph context.

When you create a process you intend to increase your productivity (or others) by industrializing tasks as you consider they will be pretty much similar from one another or very much likely to be of the same nature and the outliers will be dealt with differently. You presumably saved several people’s time/money but you also cut off the space for creativity and problem-solving techniques.

• ”Hey, there’s a problem.”
• ”Probably, but there is a process.”
• ”Ok.”

You actually didn’t solve anything but framed the problem into your funnel. Humans are both great and bad at solving problems.

And life is short, so let them try.

What if, instead of defining a process, the challenge was instead to create as little process as possible in order to adapt faster and survive? Survival can sound too much but isn’t it actually what companies are expected to do? Growth? It is just a way of surviving. Growth is successful survival. Not much more.

Imagine you define a process with third parties in order to be able to do more and be more efficient. Third parties change, priorities change, members of your team change and the typical tryptic between quality, duration and cost also change geometry. What do you do then? Is your process helping? You’re probably already thinking into changing it, right?

When I explain all this, people tend to reply: “Yes, alright, but that change doesn’t happen all the time.” It is partially true. Some evolution tickets have been in my backlog for years. So I must admit some things don’t change. I also tend to reply that they obviously can’t change their mind right now because it would prove I am right.

So now that we described the biggest difficulty of prioritization, let’s list the different methods.

Reaction VS Vision

One of the counter-arguments to the no-process philosophy is the following: How can you be sure to pursue a (product) vision if what you actually do is just reacting to the context?

That’s true. There is a high level of failure risk if you don’t follow a vision and prefer to always adapt and never make strong statements or decisions. Always changing paths will enrich the journey but will make you lose focus on the destination. This relates to a more philosophical question which is how can you be when you’re always becoming?

Instead of always trying to create or refine processes, the quest is to have the lightest processes possible in order to be able to change anytime. Being changeable is your priority. Making things adaptable is your main task. Always make sure they are changeable in a way that matches your vision.

If your vision (or the CEO’s vision, or VP Product vision…) is to become the best x for y, put half of your efforts in reaching this and half of your efforts in making sure that if the vision changes and becomes the best x for z, it will not be too hard to reroute people, work and processes. Sail a light ship.

Obviously there are things that can only exist if they are imagined in a long term. At SaaS product level, it may include stuff like: tagging plan, translation management, codebase writing guidelines, philosophy over security… These are examples of things that if you don’t foresee a little, it will break into pieces one day and probably the day you need it most. Pretty much everything else can go back and forth and change the way you consider your work entirely.

Pacificating Priorities

So apart from being as little process possible and as “sticky” as possible to the vision, what are the other ways of prioritizing?

I have to admit, prioritization is very frequently a peace vehicle. You have all kinds of parties to satisfy or bring solutions to and constraints to deal with. There is a big chance you manage it like the Justice would: everybody is guilty and everybody is a victim. Let’s cut in half the topic and give a barely satisfying 50-50 to all. You make sure that your decision is the best social compromise for all: users, partners, integrators, internal teams, your team, the board, the investors, the media…

It sounds really sad, right? Well, it is just a way to consider all the facets of the problems. In the end, the worst part is that it looks like more of a no-decision than a decision. This is why people are mad at executive, legislative and judicial powers. They all tend to satisfy and to dissatisfy everybody at the same time.

An example: the Sales team needs a highly-customizable feature at an interesting price and the Support team needs one simple filter for free to all users. There is a good chance you will: do both, half of each or none and deliver something mixing a bit of this and a bit of that. Why? Because nobody is right and nobody is wrong. Even if you spend time with a long list of personas, users or edge cases… you’ll receive as many replies as you can get and finally won’t know much more about the best thing to do.

You’re prioritizing by picking the topic(s) that bring peace to the Galaxy. You’re doing social compromise and somehow, it is your job too.

Data will tell the way

Ok then, so let’s rely on the data we have (or think we have). What if I can “explain” my choice/decision with some figures/graphs and a scientific approach? Would it be possibly challenged? Oh boy, yes. So challenged.

The first observation is that you will always miss the one data/indicator/metric that would have helped you to prioritize. You’ll find a close one or an inconsistent dataset throughout time or even the one you were looking for but no, no. You’re mistaken, you thought it was it for a moment... but no, sorry. It’s called a Eureka mirage.

So let’s track/measure it and go back at it in the future! Alright but here, you’re not prioritizing, you’re doing what is going to be explained in the next chapter: postponing. That’s another way to deal with priorities but so far, you’re not picking anything.

You look at the vague insights you have, you cross check them to see if your hypothesis is likely probable and you “magically” come up with “charts” that make more or less sense. Charts that are both true and incorrect. Charts that contain all the biases a dataset can come up with.

If you do have the very not probable dataset that will help you explain why you picked that topic, there will always be someone discussing your source, period, sample, filters… and your scientific efforts will be annihilated. That’s ok. You tried. There, there.

Prioritizing by not doing (now) or by saying “no”

One of the ways is picking the one most important topic by not picking all the others. So instead of looking for one. You just put together requests, backlog and all the feedback you may have and start by removing the pieces one by one until you get up to 3-5 items and start to ask several times why you would/should do this and not the others. When you get to 2 items, you can pick a joker (call a friend, ask the audience or get a 50/50 (totally biased random shuffle).

Suddenly, all the folks waiting for you to pick what they consider “their” ticket/request experience disappointment. You just disgusted 90% of your fanbase without being aware. People who don’t know you exist already hate you. It is a fact.

Everytime I get asked: “Why are you working on that right now (and not on this)?”, I list the 5-10 epics I consider important, urgent or priority, and ask them to pick three. Very frequently, they reply that it is indeed difficult to pick. When I offer to now pick the ones they shouldn’t work on, many people tell me it is even harder. Nothing from outer space. It is just a trick that saves you 2 hours.

In the end, what you are really doing here is postponing. Same as for processes, people ask for dates. If you give them dates, they will stick to it and let you live free. If you postpone dates, it is ok. But they need dates. If you don’t give dates you’re not accountable so you give dates. With dates, you’re a player in the team, with no date, you’re just a lone dog.

So, my advice, always say: “Yes, later.” If they ask when, “Not before 3 months.” Whatever the size of the chunk we talk about is. 3 months. 1 is not enough. 6 is too much. 3 months, anyone can picture it. One size fits them all.

Why don't I give dates (nor ask the developer team to provide dates)? Dates are deadlines. If you have deadlines, you’re dead (when you don’t reach the line). Well kinda. You (partially) lose control of the sense and the value of what you work on. By having a deadline to respect, you become more obsessed by the date than by the problem you should be solving. You’re turning (back) product into project. You’re transforming (back) value and scale into money and service. You’re doing the exact opposite of what product managers are supposed to do. I am not saying it is bad. But are you a project or a product manager?

Most teams work in projects instead of products. So, they need dates (because of their project schedule (and all their documentation which always needs to get updated like RACIs, Gantt charts, Plannings...). So, let’s get through this: give dates.

Moreover, once someone told me: “If you don’t give them dates, they will give you some.” So, you give them dates and you postpone them. There is always a good excuse. Yes, it does not make sense but what would you prefer to focus on? Giving dates or solving problems? This is the time we live in, people want fake deadlines and accept them to be postponed instead of not having any date.

On the other hand, some people are more comfortable with a straight “no”. As in: “No, we won’t do it.” It must be related to personalities or something. I don’t know. Some are even more relieved with a “no” than with a “Yes, later.” It’s like you finally gave them something they can go over. They finally have the information to pass over and over to all the cascading line of people asking for dates. Some people say that line starts (or ends) right in Hell.

Get your guts involved

I am not saying it is the best way to prioritize but sometimes, you just deeply feel something is wrong or has to be corrected. And you may be the only one who thinks it is important but damn it, you smell there is something cooking under and you want to fix it. So, well, you pick it. You abruptly decide what to work on.

Product managers who work 100% of the time like this are great leaders or charismatic assholes. One or the other. Glory or failure. That is clearly not the best way to de-risk topics but, who am I to judge. You follow or you contradict but you’re not lukewarm with that kind of decision. It can really/only work if it is fully assumed.

Best-case scenario: the topic you picked and the way you think of solving it satisfies all and you onboard all teams on the vision. Worst-case scenario: you were wrong, you’re an obnoxious freak to the eyes of everyone and every bad news is your fault.

Every single way I am listing here is submitted to the concept of bias. This one is probably the one with the most bias. It is probably the most dangerous and underestimated aspect of the decision taking process: struggling against your own bias, even if fully aware of it.

In addition, with time, you have a tendency to believe that you own a topic, a scope or that you understand it all. Wrong, you don’t. The only thing that belongs to you is your backlog. Now stop the egocentric shit and go back to spec.

Democratic illusion

Another way of prioritising is not picking anything and let people around you pick for yourself. This is something that mixes previously mentioned techniques and adds a secret weapon: surveys. Like anything, surveys have their bias. The good part is you kinda control their bias.

So, ok, you invite others to vote for stuff whether it is in a Google Form, a Slack Poll, a Nolt board or whatever… They vote (when they do). Now what? You still have a list of epics to deliver and the one with most votes is not mandatorily the one you can start with, should do first or would have bet on. Damn it. In addition, new topics popped up. Ooohh maaan...

What happens next? Well, people ask you about that survey results. So you give them and here we are again with the “Why did you pick 4th instead of 1st?” or “What is the point of asking us if you do whatever you want anyhow?”. You’re back at disarming bombs for another period of time instead of just focusing on understanding problems, providing the team quality tickets on well defined problems and making sure the delivery is being understood and features are being used.

Then, what I call the “inception of democracy” happens. You ask people to vote, you pick a topic and as there is a chance you ask them to vote by groups, you may have different results and then, you have to decide again. In the end, you always end up deciding.

Not to mention when a big client comes in and asks for a feature. Sure, there are companies that don't let this happen. But not so many. So, you welcome the change on your roadmap and do what you can.

The recipe

You kinda saw me coming with that, didn’t you. Yes, as you recall, it depends. So a mix of all this is what I am used to doing. Not proud or anything. I am just telling you. This job looks easy but it is not.

You do what you do best, you pick a topic. You try to have verbatims, data, a good understanding of the problem, a few drafts of solutions, consensus with other teams, market research, something that sticks to the vision… a bit of this and that.

Most of the time, you will be alone. You with your decision, regrets and remorse. Until next prioritization. Here we all are, in the mist of doing the PM job.

Thanks to Yann Heurtaux for his proof-reading. Image credits go to: Baking Bubbles & Dreams, Steve A. from Boston Globe, Tim Urban & Star Teacher Training