As a product manager, like anyone with a workflow that suffers for competing attention, I have to make difficult decisions of how to determine priorities by balancing conflicting stakeholder needs. There’s no simple, right answer for how to go about defining this task, making it the bane of any PM’s existence with limited resources (of time, money and manpower) to contend with.
For the last few years I’ve struggled with finding the best execution for this. Different company cultures necessitated different approaches to it and competing theories only further to complicate matters. Most development can be done somewhat a-syncronis, and dependencies have varying levels of return or relative importance to those outside of the process.
I get asked this question quite often now that I’m interviewing regularly, which has caused me to put some serious analysis to what my own experience with it is.
Task Categorization: Important versus Urgent
Categorizing tasks is a necessary first step in understanding how to balance potentially conflicting needs. Categories alone don’t answer the question of priority order, but they do lend insight by creating buckets for link-minded tasks that make comparisons easier.
Important tasks are ones that are necessary for moving forward. This could be the first in a series of dependencies or a core component from which optimizations or other features would arise. Important tasks usually are tied directly to the business model. Basically, these are things that, in theory, need to occur sooner, rather than later. They are known up front and would be generally speaking built into the roadmap to be accomplished at specific points.
Urgent tasks are tasks that arise, usually unanticipated, and directly effect the progress of a project or status of the existing business. These could be emergencies, such as a hack or blackout. These could be bugs. These could be changes in legal affairs that directly impact part of the product. Most of the times they are not built into the roadmap but are in some way critical to be addressed.
All other tasks can be filed into categories such as Routine (should happen on a regular basis, such as code refactoring and general debugging), Non-Critical (should happen but aren’t immediately necessary for success), etc. These too are competing for limited resources and need to be considered in allocation but generally fall outside of the typical top-priority scale. Failing to address these in due course can turn them into future problems so they can’t be completely overlooked.
Since Important and Urgent both need to be addressed with more immediacy and are both competing for those top level priorities, simply knowing the category isn’t enough to make a decision as of yet. Lets use a quick example of a house. If one only executes on Urgent matters the team is constantly in fire drill mode. Sure, the house won’t burn down, but it also won’t be built up and expanded upon. Conversely, if one executes on Important matters the team is constantly in production mode, the fires stay lit and burn away at the structure while in the mean time new structures are constantly going up. Neither one alone is productive, which is why it is important to understand the impact of the tasks in other ways.
Task TIR: Short Term Success versus Long Term Gain
This is what I’ve dubbed as the Time Impact Result. When it comes to tasks that potentially add value there are two usually competing scenarios to consider, short-term success and long term gain. This is a matter of productivity in some ways, relating how long it takes to accomplish what type of value-add to the product.
Short-term success is something which can be executed easily will have an immediate impact on the product. These are the low-hanging fruits and quick kills that are easy to leverage as examples of progress because they are routinely visible in their execution. The impact typically won’t be enormous (although it can be), but because they take less effort and offer quick gratification they are very approachable. Short term successes become a focus because the perceived pay-off is now even if the contribution itself probably wont’ be lasting.
Long-term Gain is achieved by tasks requiring more resources to achieve but the end-benefit should have lasting and usually large results. The resource drain in accomplishing these more complex tasks finds the pay-off occurring at points in the future and progress getting to that point may not always be visible but the end-product usually is.
Both types of tasks need to be done in order to be successful. Both have visible gain, but not always in the same way and therefor there can be a tendency to over-emphasize one or the other. Let’s revisit the house example to see why this can produce problems. If one only builds to short-term success this could be represented by having a very good looking room because painting and hanging pictures was quick and easy but not much stability to the overall architecture. Whereas, if one only built to long-term gain there might be a very solid foundation and framework featuring state of the art innards but not much to be said for any of the individual rooms decor because all the effort was on the big projects.
As a note, there are tasks that are essentially zero-gain, they need to be done but aren’t going to yield necessarily qualified results such as routine maintenance work. Sure, if you neglect it it becomes a problem, but so long as it is being done it isn’t adding new value to the product.
Different than TIR, Return on Investment typically looks at the whole cost investment associated with a particular build, rather than just the time component. RIO is usually calculated by a ratio of cost-to-projected earnings. Where developers and programmers like to look at the scope through the lenses of a resource productivity which makes TIR analysis useful, ROI is more typically finance or marketing driven look. The two offer differing pictures of the same type of things.
Low projected ROI using cost calculation doesn’t necessarily mean low overall product value. It is entirely possible that just because something is quick and fairly easy to accomplish the cost of doing so could still outstrip the ROI because it doesn’t generate enough revenue to cover its cost. But, just because there isn’t an immediate revenue in a project doesn’t mean it’s lifetime contribution isn’t important. Lets assume a number of low ROI projects are done in succession and all somewhat related in the feature set. The individual parts provide no visible return, but the sum of them together provides a positive return. Similarly, a low ROI project may become part of a foundation for higher ROI projects that come up in the future, but because those future projects don’t yet exist in the calculation means the assumed current value is artificially low. Then again, some critical tasks just cost more even though they seem to do less.
High projected ROI doesn’t necessarily mean high product value either. A long or complex project could cost a lot up-front but upon release the revenue generated easily nets a positive ROI. However, just because a project has a high ROI doesn’t necessarily make it the right choice. Some individually high ROI projects could have dependencies that are low ROI or the cost may be in stress on the team to produce them or the TIR