Offense vs. Defense Projects

I spend most of my time focused on offense projects, the projects that are going to get me closer to my goals. The goals could be around sales, users, traffic, conversion rate, penetration, whatever. Note that offense projects aren't just building new stuff, they can also be fixing stuff that's broken or reducing abandonment within a feature. If it grows your core metric, then it's an offense project.

Defense projects are the price of admission for operating your product. Fixing bugs or migrating to a new version of a dependent service or library that doesn't offer any interesting new functionality are examples of defense projects. Some projects can be both offense and defense, but they'll usually be more one than the other.

In my project prioritization I tend to want to stack the deck towards as many offense projects as possible, preferably ones with potential big impact that are quick to develop (low cost). I'd do this all day long. Unfortunately, using this method alone means the defense projects never get touched, assuming you keep coming up with new ideas for offense projects. The question then becomes how best to work in the defense projects? You don't want to try to get them all out of the way before moving on to offense because then you delay all the metrics goodness until later and miss out on some compounding growth. You don't want to accrue too much technical debt or do them at the last possible minute because then you lose all momentum from the previous offense projects and the team feels like they are on a slog. You also risk missing hard dates.

My method is pretty simple: time-box defense projects, and leave the rest of your resources to work on offense projects. Then, over time, see if you can sneak some small offense projects into the defense queue (sneaky, huh?) or make the box smaller (i.e. going from two engineers to one assigned to defense). You want to block off enough resources for defense initially to keep you head above water and make some gains. Ideally if they're fixing root causes faster than the offense folks can create them, they can pay down some technical debt, thus carving out more resources for offense.

The reason I maintain essentially two different backlogs, is that if I just used one prioritized by offense, the defense projects would NEVER make the cut. I have to have a separate backlog prioritized using a different heuristic, and then apply defense resources towards that separately.

What method do you use to prioritize projects?

-@ianmcall