Top priority

A common situation that I've heard many frustrations about is when a team or product owner get a top priority assignment. But what does "top priority" really mean for most teams?

In general terms top priority means at the highest level of importance and to avoid unnecessary stress it makes sense to classify how to treat these, because top priority doesn't necessarily mean that this and only this should be done right now.

For a team that frequently needs to deal with top priority assignments some perspective can be useful on how to view this type of work.

"top" usually means that in a prioritized list of things to do this one should be picked first. Eg:

1. "top priority"
2. Second priority, do this after "top priority" is done.
3. Etc...

However for most teams this is simply not true. If you have a service running and operational responsibility the list really looks like this:

1. Keep the lights on
2. "top priority"
3. ...

As a product owner dealing with the strategic priorities of your team I suggest to look at it like this:

1. The problem
2. Team definition
3. Create a platform
4. Impact and reach
5. Keeping the lights on
6. "top priorities"
7. Unimportant stuff

So anything that you can be assigned as a team is really not that important. As long as your team can own and master the other really important things you are in a good position. When you get a feeling that your hand is forced to do things you do not consider important you can both use the above things as counter weights in arguments ("We'd like to build that feature, but the system is down so we need to fix that first.") or simply as reminder that you are in control of the really important things.

The 1-5 are the real top priorities that are the essential considerations for a product owner and the team. I'll make it my top priority to write detailed posts about each one of them, or well...