A Simple Way to Prioritize
Prioritization answers the question - what to do next. The common approach is to “do the most valuable item first”, but value to who? The business? The user? And what is value anyway? Time saved, money saved, performance?
And while we’re at it, what about items deemed of similar value? How do we decide? At this impasse, another variable seeps into the equation - effort. Amending our original treatment to something like “do the highest value, lowest effort item first.” Of course, the original problem remains, but compounded - neither value or effort are clear.
Estimates are notoriously difficult to get right. If you’ve ever committed to a home improvement project that you’d have done ‘in an hour’, then you know the reality of estimation error. Estimation error has less to do with competence and more with novelty. Same thing, more reps = better estimates, but software is rarely a copy and paste endeavor.
Value isn’t free from fuzziness either. After all, if you rate value on a 1-5 scale, who decides when something is a 3 or a 4? Are all 4’s across your teams the same? Can we map every item’s value to some absolute dollar value? Not likely.
Product Manager Bruce McCarthy [1] endeavors to address this issue of mushy value and effort though adding yet another variable, confidence. His model attenuates our prioritization score with a dash of reality, asking us to quantify our certainty, effectively lowering our earlier scores for all but items with the most firm conviction.
The wonderful thing about this approach is it creates a question in the mind of the product team. A pause to consider that they may not have the answer after all. In fact, done well, this added step can drive a team to dig into the data or to visit a few more customers to ‘increate their confidence’. All good practices.
While Bruce’s model is strikes a nice balance of sophistication and practicality, any prioritization model can be gamed. So don’t shoot for perfection, it’s best to get a rough relative sense and move on. Speed is an important, but unaccounted for variable in most processes and progress > perfection. It’s very tempting to live in the comfort of a spreadsheet, but great products are not built in Jira.
It struck me while working on a recent personal coding project that I didn’t do any of the above prioritization formally. As I was the designer, product manager, and coder - there was no need to socialize how I was making decisions, but I still found my lack of a formal prioritization curious. I was prioritizing my work, but how?
I soon realized that I was using a much simpler approach. I was fixing what annoyed me most. And then I did it again. And again.
Fix the most annoying thing 1st. Repeat.
Looking back on my GitHub log, I noticed the code I checked in could have been technical debt, a UI element that was misaligned, a label on a button, or a feature I’d been wanting to do for weeks. It was whatever bothered me at the time, and interestingly, the actual code I shipped had nothing to do with the ‘formal backlog’ I had created in my todo list app.
It does show how working with others complicates software and necessitates adding layers to a process, but if you’re working on your own, or with a sufficiently small team, consider trying to fix the most annoying thing first.
“We don’t have or believe in backlogs.” - Jason Fried
If you’re using the product yourself, every day, I imagine this will be easier than you think. You’ll have an intuitive sense of what’s bothersome. Building software doesn’t have to be difficult, but we love to make it so.
If you liked this article. Subscribe on substack.
__
Footnotes:
Bruce McCarthy at Business of Software. The equation is (value/effort) x confidence. Value and effort are a 1-5 scale and confidence is scored between 0-1. For example, a value of 5, effort of 2, and confidence of .5 (ie. 50%) yields a prioritization score of 1.25.