Always liked Reinertsen’s post on reframing tech debt to deferred work.
“When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work.”
I know the intent is good (it is!) but this common notion that good design is a toolbox of fun little games really prevents the design function from getting taken more seriously. In the business world at least it ensures our seat at the kid’s table.
Worth remembering that priority and sequence are not quite the same thing.
There's a useful framework called RICE where you evaluate/score ideas by Reach, Impact, Confidence, and Effort. Sometimes assigning numeric values feels forced so I often use it as "dimensions to be thinking about" rather than a literal scoring system. [1]
There's some great stuff in Reinertsen's Flow book about different sequencing strategies and when to use each. Eg, When delay costs are homogeneous, do the shortest task first. When task durations are homogeneous, do the highest cost-of-delay task first.