Pragmatic prioritisation
Last week, we saw how we can use cost of delay estimates to compare value-add features with indirect gains such as paying down tech debt or improving tools. Doing this on something close to a level playing field can be really useful.
But the problem with all this is that it is often extremely hard to get even vaguely accurate estimates of true value.
- The value of a feature may not be directly linked to hard numbers like revenue
- Most features are guesses of value in the first place. Most features fall well short of our expectations
- The true cost of tech debt may go beyond simple developer inefficiency
- Tool improvements aren’t guaranteed to pay off the cost of integration and maintenance
And so on.
Unfortunately, while cost of delay estimates can be useful in well-understood domains, they can often lead a team astray.
New product development in particular is not a ‘well-understood domain’. We need to take pragmatic concerns into account. For example:
- Fixed deadlines / seasonal dependencies
- Goodwill / reputation / PR
- Compliance / legal commitments
- CEO-driven development (preferably not)
- Security incidents / concerns
- Availability / downtime prevention
- Partnership / service agreement commitments
In theory, all of these examples can be expressed in terms of the cost of delay. For example, delaying a bit of work beyond a fixed deadline will dramatically increase its opportunity cost! Many of these examples have non-linear cost / time relationships.
So while we reduce everything to a cost of delay comparison, the complexity of modelling all proposed changes is just too impractical.
What’s the best alternative approach to prioritisation in these circumstances? I’m yet to find anything better than communication, advocacy and consensus-seeking, all based on good-enough research and discovery.
Have you use anything better for prioritising work? Reply and let me know!
All the best,
– Jim
