What do you want next?

We are focusing on A and B, and in a month or so we’ll start focusing on C, while also keeping focus on A and B.

Sound familiar?

When we do prioritization at work, I insist we have a single column of priorities or coarse features. In other words, “what do you want delivered next?”*

If a team or person isn’t working on one of the top two or three priorities, they’re doing unimportant, and possibly counter-productive, work. You’d be amazed how many people are working on things someone arbitrarily said was important, which aren’t inline with actual priorities.

You’d be even more amazed how unimportant most “high priority” work is when it needs to be stacked along with everything else. A feature can easily sit at the number 4 spot for months. Just be careful work doesn’t move up the queue just because it’s been in the queue. I don’t think this is a problem, though, because when you tell a product person “we are only executing on the next 2 things to deliver” they are going to have to make hard decisions.

I’ve worked on projects from 10 to 500 people, and generally the times we were humming along was when we had one or two priorities. We ended up producing crap when we had n priorities (where n is often the number of people or teams). Big teams don’t mean more priorities. It is just the granularity of the priorities that changes.

This sort of rigid, columnar prioritization communicates to product people that work only gets done when it’s at the top of the column. I’ve run across countless people, both managers and developers, who just sort of, well, expect that stuff just sort of, well, gets done, somehow. And generally it appears as if things are getting done, until everyone finds out they weren’t really. Are there significant bugs in some old system? It’s not fixed until it’s a priority. Is that new system still unpolished? It’s not improved until it’s a priority. Want to build something that requires some serious infrastructure? Well, that infrastructure stays at the top of the column until it’s done, to the exclusion of other work. Do you want good tools? Well, it means you aren’t going to get features.

It’s an extremely simple and powerful technique, and I highly recommend it if you are having trouble coordinating a product group.

* This doesn’t include ongoing product support, small fixes, and improvements. I think you need a way to handle this outside of normal feature development teams, with some sort of “live support” that can react quickly. A topic for another post.