Prioritization is for me one os the most controversial topic, and really hard to set good practices for. In interviews, for example, it is really hard to understand one’s mind on how to deal with prioritization. I will try to explain a bit how I deal with it, and give an example that I experienced.
In books and articles, we can find a pretty way to deal with prioritization. Analyze your ROI (return of investment), the deadline of stakeholders, business opportunities, legal requirements and even making your stakeholders decide by sitting them together until an agreement is done. Of course, I do think those are valid points and I do use those theoretical methodologies. But the real-life is not so black-and-white, is it?
Let me start with my example. I was a Product Manager when I had to deal with a confusing and challenging prioritization. We had all the developer team focus on building a solution let’s call it solution A, to be legal compliance to start in a new market. The idea was finishing solution A, and after that, we need to build the already existing system from scratch again, for technical reasons. It was a solid plan.
Meanwhile, a business expansion team approach me saying that they finished a project to bring our company to another new market and that we need to make also the features required to make this new market also compliance, and that is our solution B. They forgot to align their project with the system and the requirement came days before the release of the product.
And to make things funnier, some of the markets where the business was already established had new legal requirements popping-up, and this is our solution C. When you look at the theory, the legal requirements C usually should have higher priority, right? Well, not always.
After analyzing all the requirements in detail my decision was: let’s keep the solution A as our priority number one. For solution B, we decided to adapt the already existing system, because it would require only a few hours of effort and it would give us time to finish solution A and then communing back to make a more stable solution B. What about the legal requirements on solution C? Well, we estimated the fine we would receive, and comparing to not entering new strategic markets was worth paying this fine for a while.
I know, this was a really specific problem and hard to generalized from. But that is my point. There is no recipe for prioritization. The most important thing to do before deciding is making a deep study in all the facts you have and analyzing the pros and cons of each scenario. Talking with the stakeholders and/or clients is also important, to understand their view on the topics.
It is not possible to cover all exception in the literature. What I wanted to show here is that, if you understand the theory, why is that good practice and you open your mind to analyzing all the possible cases you have to solve your problem, it is not so hard.
And this is the kind of behavior I try to bring candidates in during interviews for Product Manager roles. I try to make them think, and try to stimulate them to explain to me their way of thinking. I must admit, for me, this is most harder than any real problem situation I had ever faced in projects in my career.