Setting priorities for tasks

I find it hard to prioritize tasks when it comes to building software. I also find it hard to prioritize projects in product meetings. And I don’t think I’m the only one. I hear many discussions about how to prioritize, and see formulas on how to do it.

All of it is useless.

For macro planning, aka what projects to bet on now, Jason Fried’s view on prioritization is the single way to go. Do or not do. Now or not. Yes or no.

For small development tasks part of a project that’s already been decided, there is no priority. Everything’s equally important.

Heck, it’s even harmful to productivity to put priorities into small tasks that all need to be done. The best order of operation is whatever you want, from the perspective of the person actually doing it.

Why? In the context that all tasks need to be done, you might as well let the developers tackle the tasks they want and be efficient, excited, curious while doing them. On top of this, you’ll encourage less idling and context switching.

Idling because maybe the top 1 proiority task may not be completely well defined yet, or require input from soneone else.

Context switching because forcing priority won’t allow developers to pick tasks that are related to things that they worked on recently. It’s much quicker for someone who just worked on project A to do a small change in project A than for someone who hasn’t seen project A in months.