A never-ending and always engaging discussion thread among software product building teams is the Prioritization of Product Backlog.
To me, it is not (& should not be) a never-ending discussion topic, if we have clarity about one question.
That question is, WHY we are building this.
Discuss this with Sales folks & Developers and you may get something like...
-to win more customers,
-to make our customers happy,
-to expand our market share,
-to serve our global market with our self-sustaining, carbon footprint-conscious, cutting-edge technology,
- Yada Yada Yada.
To me, it is not (& should not be) a never-ending discussion topic, if we have clarity about one question.
That question is, WHY we are building this.
Discuss this with Sales folks & Developers and you may get something like...
-to win more customers,
-to make our customers happy,
-to expand our market share,
-to serve our global market with our self-sustaining, carbon footprint-conscious, cutting-edge technology,
- Yada Yada Yada.
Now add CFO & CEO to the discussion, and you may get one more answer...
-MMM ( Make More Money).
Consider your answers and decide which answer matters most to you/your Organization before you decide HOW to prioritize.
Here is my super simple way to prioritize the backlog. (YMMV)
- What gives better value, do that now. (Value to the Users/Market, and hence Value to the Product, and hence Value to our Org)
- What gives better value with less effort, do that right now.
- All other stuff should wait.
It is that simple & straightforward.
-MMM ( Make More Money).
Consider your answers and decide which answer matters most to you/your Organization before you decide HOW to prioritize.
Here is my super simple way to prioritize the backlog. (YMMV)
- What gives better value, do that now. (Value to the Users/Market, and hence Value to the Product, and hence Value to our Org)
- What gives better value with less effort, do that right now.
- All other stuff should wait.
It is that simple & straightforward.
Of course, to take that straightforward decision, I need to do some homework.
- I need to know where the VALUE is.
- For that, I need to be sufficiently outward-focused & understand the Market.
- I need to understand the difference between ‘A Particular User’ and 'Market'.
- I need to scout for the Right Market Needs.
- Finally, I must know that the 'Right Market Needs' are those, which are most sought after / painful for the market, AND most rewarding for our balance sheet.
In short, it all boils down to NIHITO, as Steve Blank said.
A few exceptions to the above super simple thumb rule for prioritization could be the work
that involves…
-Work required to ensure ease of CI or
-Writing instrumentation code (Telemetry Data Gathering) or
-Setting up standards for the team or
-Defects fixing or
-Work required to acquire patents or
-Fulfilling statutory mandates or
-Derisking type of work or
-A strong demand from extreme-extreme-high-value existing customers.
-Work required to ensure ease of CI or
-Writing instrumentation code (Telemetry Data Gathering) or
-Setting up standards for the team or
-Defects fixing or
-Work required to acquire patents or
-Fulfilling statutory mandates or
-Derisking type of work or
-A strong demand from extreme-extreme-high-value existing customers.
Work from all these categories does not (should not) pop up every day.
For routine Prioritization decisions, the above formula is super simple, and it works too very effectively.
For routine Prioritization decisions, the above formula is super simple, and it works too very effectively.
No comments:
Post a Comment