When I was younger, I decided that I wanted to buy a dSLR camera so that I could take better photos. I spent weeks and weeks studying the tradeoffs between the various manufacturers, analyzing the feature sets, speculating about the potential lenses I might want to acquire in the future, and asking anyone I knew who’s ever been near a camera what they thought about the Nikon versus Canon schism.
Months later, I still didn’t have a camera, but I probably had a few pages of a notebook filled with headings of PROs and CONs. At this point my dad remarked to me: “Just buy one, the differences are smaller than you think. You’re wasting time you could be actually using to take photos.”
Time and money are both finite, and while it’s usually possible to get more money, once time passes, it’s gone forever. For that reason, prioritizing what you work on or what you invest in is important: you don’t want to waste effort or money on projects that don’t have impact, don’t make you happy, or don’t align with your bigger-picture goals, whether your own or those of your organization.
That said, I’m increasingly of the belief that my dad was right, and it’s easy to over-emphasize the importance of fine-grained prioritization. There’s a real time cost of doing the work of prioritization. You don’t want to be too far to the right on the time-versus-certainty tradeoff:
Boundary cases are useful in understanding many problems, so let’s take two extreme opposite viewpoints and see where they lead us:
Spending no time on prioritization
Without any ranking of tasks in our to-do list, we just do things as soon as we come across them, in something akin to a random order.
If I were picking a restaurant for dinner, in this approach I’d just pick the first place that I came to mind and go for that. But having not done any research I might end up somewhere with really long lines and terrible food and service.
In the software world, the equivalent would be to fix all bugs and start work on all feature requests as soon as they came in: you might end up addressing a lot of surface-level user needs quickly, but you’ll likely not end up making progress on the big, impactful things you’ve set out to so.
The great thing about this approach is that you spend the majority of your time actually doing things. However, you’ll likely end up working on or investing in things that don’t actually satisfy your goals.
Exhaustive prioritization
On the flip side, you can spend a really long time prioritizing your work and getting certainty that you’re working on the right things in the right order.
Now, when picking a restaurant, I’d read a lot of reviews, look at a bunch of photos of the food, call the place to make sure that there aren’t any lines, consider what alternatives are in the neighborhood, etc. But I might spend a bunch of time trapped in this analysis paralysis, and end up doubting my choice once I’m actually there.
In software, I can make a fleshed out roadmap through having lots of meetings with advisors and stakeholders on what they think we should do, collecting data and running simulations on different outcomes, doing user interviews and research, and producing lots of presentations and documents on the side in support of prioritizing. But while this might ensure a better initial outcome, during this planning phase, nothing is actually being built.
You will likely end up getting at least some of this right, and will have a higher likelihood of having the right thing at the end of the process.
Illusions of prioritization
Prioritization isn’t free. You can’t ignore that the process of prioritization itself takes time! At the minimum, it takes up a lot of management time. But it can also affect engineers and makers, especially when work is already underway and in-progress tasks are shuffled around in front of people.
There’s a great example raised in David Allen’s book Getting Things Done about how tasks can either exist within a prioritization framework or can live outside of it. Especially if a task is small enough, you should just do it, because life within a prioritization framework can actually add a significant amount of additional meta-work (managing, reprioritizing, re-evaluating importance, communicating changes in priority) that just doing something doesn’t have:
It’s also rather difficult to be truly confident that you’re working on the BEST use of your time, even after exhaustive planning. When you’re developing new products for users, without actually getting them in front of people, you’ll have a hard time knowing if you’ve succeeded. In the time that it took you to make a meticulous roadmap with a perfect ordering of tasks, the world may have changed around you or you may have learned something you didn’t know about the onset. It is more useful to just buy a camera, and then later figure out what lenses are needed after your own real-world use, rather than to figure out what lenses I might want even without having used the camera itself for any significant time.
Practical implications
I’m not saying that prioritization has no place. In particular, I believe very strongly in prioritizing according to dependencies and logical ordering of execution — something that many people get wrong. If doing project A before project B would make project B a lot easier to do later, prioritizing project A is a good idea. A heuristic I’ve found very useful is to prioritize work that is generally useful and can teach you a lot, or extends a framework or platform, over something that is specific or narrower in applicability.
In short, I’ve found it useful to err on the side of using intuition, gut feeling, and rapid research to prioritize my work and what I do with my money, and then learn from doing and by flexible enough to adjust course along the way, rather than try and justify everything with prioritization exercises that often miss the mark.
