Prioritization Problem!
Build your own framework (BYOF) as per the context
Prioritization is a significant issue in general, but it becomes even more critical in an enterprise. Especially, in Banks the pain is immense.
Banks operates with complex structure like Pan’s Labyrinth - with core businesses at the top, each consisting of sub-business which in turn have various applications supporting it. This makes prioritization more messier in four ways:
Fragmented Departments: Different departments operate with their own processes and goals, leading to a lack of cohesion.
Misalignment between Applications and Business Areas: While business might be organized around specific products or areas, the applications that support them are not always aligned with these structures.
Limited IT Capacity
Prioritization is a one-way street: Business does prioritization, the product writes PRD and stories, and development executes it.
Product leaders and Coaches often say that the issue lies in not having a strategy, but the real challenge is moving forward when people don’t even understand what strategy is. Prioritizations frameworks generally doesn’t work in such situations. Ideally, hiring a qualified product leader to help navigate this challenge would be the best bet. However, not every organization has the luxury of hiring. So, how do we make progress in all this less-than-ideal case?
Remember the customer value flows horizontally across the silos and not vertically across the departments or hierarchies.
Most change requests coming from stakeholders are always presented as urgent, high priority items. I’ve seen multiple situations where one single product manager works with multiple business stakeholders. It can take weeks, sometimes even months, to determine which tasks should take precedence over other, leading to endless discussions and analysis-paralysis. The Business are too pushy and demanding, and the only thing Product Manager has no choice but accept all the requests and push it down to development throats. The result is development is started for all the features simultaneously, but nothing really gets finished. I am sure you have experienced this at some point of your career. Sometimes we try to throw more people to the problem, but this approach often backfires infact increases more stress, communication overhead, and often results in poor output with equally poor quality.
I had a frustrating experience with prioritizations frameworks always especially Moscow, Kano, Impact vs efforts etc. The challenge is these frameworks are never suited to the context.
Read this Gem LinkedIn post from John Cutler before you go further.
So, here’s the story, there was situation where a single development team supported multiple businesses, and all the business treated everything as priority one. It was a deadlock situation with absolutely no progress.
Below is prioritization framework which got “accidently” developed by adapting elements from other frameworks to better fit my context. I am heavily influenced by John Cutlers, Joshua Arnold and Ant Murphy’s work and I highly recommend exploring their work for some added inspiration.
It’s simple formula:
Prioritization Score: Value x Implementation x Leverage.
Next, let’s break down what Value, Implementation, and Leverage mean.
Value can mean different things to different people, making it challenging to define and reach a broad consensus on what constitutes "value." Our goal is to clarify how we measure value by focusing on its impact. In my case, value was assessed by answering three straightforward questions
Will this work bring significant revenue/cost savings?
Will this work bring more time savings (Operation efficiency)?
Will this work impact users?
If the answer to these questions is "Yes," the next question you should ask is, "How much?". Try to form a range of numbers wherever possible for the possible responses. For e.g.
Q) Will this work bring significant revenue/cost savings?
Yes (> 10 CR)
Yes (1 CR - 10CR)
Yes (0.5 CR - 1 CR)
Yes (< 0.5 CR)
Q) Will this work bring more time-savings?
(Notice, the TAT values will come as per your product analytics, but we are not having any numbers here which is okay to start with)
Extreme TAT Reduction
Higher TAT Reduction
Medium TAT Reduction
Minor/Negligible TAT Reduction
Q) How many No of users (end users/branch users) would this work impact?
Impacted Users > than 50% of total user base (available/estimated)
Impacted Users 30%- 50% of total user base (available/estimated)
Impacted Users 10%-30% of total user base (available/estimated)
Impacted Users less than 5% of total user base (available/estimated)
Here is a table:
Notice:
The red column is nothing but score which you can define. Say example:
If it is Critical (> 10 cr) the score to the first question, the score is 4
If it is Medium TAT Reduction for the second question, the score is 2
If the impacted users are less than 5% for third question, the score is 1
Let’s add one more question, (This will analyze the impact of the feature with strategic goals)
Does this work align with organization strategic goal, and directly impacts critical KPIs? The Answer can Yes/No.
Yes - Score is 1
No - Score is 0
WHO: The Product and the Business is responsible for owning the Value section. OfCourse, all this data will come from various insights.
Let’s move to the Implementation side of it. Implementation can be answered in two questions.
What is the development effort?
< 2 weeks
2-4 weeks
4-8 weeks
8-12 weeks
Now, any feature which is greater than 12 weeks should be further split as per the outcomes. Ideally, you shouldn’t take more than 12 weeks to ship the feature. Ofc, you can customize this scale as per your context, but I would suggest putting efforts in weeks and not months.
What is your development team’s implementation confidence of developing this work?
This is the question in my view is most critical from execution point of view. The dev team really needs to come forward and divide their confidence in ranges (something like below) but based on assumptions (facts, dependencies, skills etc.) for these ranges. Notice an old team will have all these assumptions, but a new team might start with some basic and build on it.
Notice:
The Development or engineering team should be owning the Implementation side.
Some of you might have a question here why not club the two implementations question together? It is important to separate effort and confidence. Confidence is what unites the team together and instill belief that they really think they can deliver. Instead of relying on finger in air exercise of “fist of five” we are trying to add some subjectivity to our confidence assessment. Again, the scale and the parameters will vary.
Let’s combine everything:
The total business value is determined by summing up all the business value scores (represented by Business Value subtotal), while the implementation total is calculated by multiplying development efforts by the confidence multiplication factor (represented by implementation total). While the Total (in the last column) is derived by multiple business value subtotal with Implementation total. This is row that gives the feature ranking for implementation.
If you notice, the "Ease of Use" feature was critical from a business value perspective as it had 13 points in Business Value subtotal, but since its development confidence was very low, it resulted in a lower total score i.e 15.6. Therefore, the development team should prioritize Feature 1, which addresses trust issues that has 16.8, over the "Ease of Use" feature if they want to realize value more quickly. This framework helps identify which experiments or features should be developed first to maximize early value realization.
Adding Leverage:
Let’s add one more complexity. Regulatory requirements can be a crucial factor that impacts your work significantly. I’ve used a multiplication factor of 2 for regulatory requirements and a factor of 1 for non-regulatory items. Regulatory requirements are often deemed top priority and can supersede other tasks, but they still need to be prioritized effectively. If everything is treated as regulatory and urgent, there won't be anyone available to discuss actual priorities.
Lastly, I suggest not to add more leverage, and only restrict it to one i.e regulatory/legal change only.
The order of priorities has shifted once again. Now, Feature 2, which has a regulatory element becomes a higher priority over Feature 1, which was addressing the trust issue. The presence of leverage in form of regulatory requirements can elevate the priority of certain features, demonstrating how these factors influence overall prioritization. In this way, you can prioritize the list of features. I am saying features as there is an assumption that adequate amount of discovery has already been conducted on it.
This prioritization framework is combination of ICE (Impact, confidence and Ease), WSJF framework, Value and other some ideas.
Build your Own Framework: The objective is to not present you to one more prioritization framework, but to motivate you to create your own framework as per your context and get people to numerically score their ideas with some parameters.
One Size fits all problem: Different business (or departments) will have conflicting needs or even contradictory business goals. Imagine features coming from different departments like Marketing, Sales, Finance, and Regulatory. In that case, this framework will push the decision on the “Implementation side” of this framework by measuring the confidence and development effort by taking into account the available capacity of the engineering teams (This is useful for organizations struggling with engineering capacity).
Please read the amazing article by Rich Mironov - worth a read. https://www.mironov.com/pri-politics/
Progress over Perfection: Prioritization will never be perfect, nor this should be the sole aim of the exercise. There would be still some ideas where there would be absolutely no agreement or even enough data to support but still you need to prioritize that idea ahead of others.
Lastly, below are some articles that will help you understand prioritization in detail.
https://cutlefish.substack.com/p/tbm-245-the-magic-prioritization
https://blackswanfarming.com/qualitative-cost-delay/
https://roadmunk.com/guides/product-prioritization-techniques-product-managers/