Which item to work on next? How to not forget about technical debt? How to remember about support needs? These are all the questions that usually fly through my head when looking at the next value-optimized deliverable. When I add effort to the mix, things get a little crazy. I am not a massive fan of upfront effort estimation.
In many situations I was faced with a dilemma. The value-optimized deliverable, including all of the metrics predict a massive success. Though engineering experience tells me, that sooner rather than later we might find a lot of traps. Short-term decisions to put the product in front of customers will come back to haunt us. Support is going to forward numerous tickets they can’t handle themselves. And here is the platform team in the organization coming at us, that our product just broke our internal standard and will need to be rewritten reasonably fast.
Sound familiar?
Most prioritization techniques I have dealt with focus either mainly on cost or value. And probably right, as they target to be simple. In my opinion prioritization shouldn’t be simple. In the end we are dealing with something, that will stay with the company for years, generating revenue, cost and customer satisfaction. I find prioritization discussions absolutely critical and vital. Before a single line of code is written.
Here is how I attempted to take a stab at that problem.
Time management is an oxymoron. Time is beyond our control, and the clock keeps ticking regardless of how we lead our lives. Priority management is the answer to maximizing the time we have.
John C. Maxwell
The framework has 4 main elements.
The intent here is to capture more than just business value or specific teams need to use a technology. This then translates to a lot more holistic view of your priorities and choices. Time-effort is excluded on purpose. Lets be honest, you will commit much more time than you plan. Whether its in the hidden maintenance cost or unpredictable support cases. This framework is supposed to help you deciding which way to go, not how much time you think things might take. All you need is a decision whether you’d want to invest in a specific direction.
I’ll get back to effort and timelines in the summary.
How to approach the collection of data points?
Business Value
Is your primary target with any change or removal of a service. Both for money-paying customers as well as external consumers of the free services. This is where product managers play a key role. It’s all the standard product discovery and discussions.
Primary audience: Business sponsors and user/customer research
Accountability: Product manager
Non-functionals or cost of service
This is where all the discussion on choice of technology, patterns and all the technical feasibility reviews should go. Including thinking on the long-term cost of the choices made.
Primary audience: principal engineers and platform teams
Accountability: Technical Lead
Team value
This is where the aspect of – is it the thing we buy into as the team. This answers the question whether it can be built according to our team vision. Will there be any corners cut? Does it help us to achieve the long-term vision we have set out for our services? As well as whether we agree to it from cultural perspective (example: company would like to collect more data about our users, but we do not feel it is the right thing to do)
Primary audience: The Team
Accountability: Technical Lead, Product Manager
Internal Consumer Value
With each new project, whether we like it or not, we will modify complexity of processes in other teams. Support, technical service consumers, HR and many other functions need to have their say.
Primary audience: All internal functions that are not the immediate benefactor of the change
Accountability: Technical Lead, Product Manager, The Team
The framework is designed primarily as a discussion tool. You can use weights (i.e. you may say because of our priorities BV will get 50% weight). To get a score, you can use stars, fluffy unicorns or voting with comments to collect the data. How you decide to use it, is secondary to having focus on these 4 areas.
What is very important, before making any decision on priority, finish assessing each of these areas. Allow all of the functions to contribute. In many cases, I have found what has started as an engineering NF initiative, resulted in massive business value (in most cases improvements in delivery efficiency, which then resulted in better customer feedback).
I will not lie, properly assessing each category is a lot of work. The benefit you get though is colossal. You are finally more informed on where to put more focus. Also, if done properly, you have just eliminated silos in your company. You know. With all of the conversations.
I have mentioned the timelines and the fact I care for them less. While PMI would tell you to estimate upfront, I found basing your priority decisions on unknown unknowns a trap at best. Using APT framework you can decide what’s best for you. Then say – we’d like to spend a maximum of 6 months on this project and then review how it is going. This will change the perspective. It will finally decouple priorities from effort.
Just to note products like google, iPhone, even Cyberpunk 2077 were all late or delivered with early issues. It took them years to stabilize. And at the same time revolutionize the world. If someone would say that iPhone will take 7 years to perfection, using it as a primary prioritization input, it would have killed the project.
To wrap up – a prioritization technique (APT) is:
- focused on informing how to set your priorities
- conversational
- holistic
- decoupled from effort required
- in my opinion provides a much better guide to the tough prioritization discussions
Gustaw Fit 