Swing for the stars!

Two techniques for prioritization

Stack ranking and what it misses

Swing for the stars!

 

 

I've been asked a lot recently about prioritization strategies. This is by virtue of the fact that I'm interviewing for jobs, not because I'm on the lecture circuit… but still, since I'm in practice sharing my thoughts, I may as well stretch them into a blog post. Here we go!

Spoiler: Stack ranking is massively important, but has a massive flaw, and I'll suggest a solution below.

Stack ranking

a cairnSimply put, stack ranking (a.k.a. force ranking) is taking a list of all the things that that should be done and putting them in priority order, with the thought that you'll work on them in order from top to bottom. It's the same thing you do when you have 10 things to do today and only time for 5 of them.

In practice, it's not perfectly straightforward. What floats to the top on such a list? The thing that the most (or biggest) customers are yelling about? The thing that the sales team needs to close a strategic account? The thing that engineers are warning will be a Major Problem if it's not Fixed Soon? Low-hanging fruit that can be done quickly and with low risk? Whatever the data suggests will have the biggest impact? The CEO's (or PdM's) favorite visionary pet?

Yes. All of that. As in requirements discovery, many disparate and often contradictory signals have to be balanced in order to effectively stack rank. (That's why product management is so fun!) There's also an element of project management required—if the 3rd item on the list requires the 6th to be completed beforehand, the stack obviously isn't in order yet. Similarly, resource allocation plays a big role—if item 7 falls mainly to front-end developers, and they're relatively free compared to the engineers needed to do item 2, 7 can be promoted even if everyone agrees that it's less important.

The stack rank doesn't necessarily dictate the order in which things are worked—that is a function of project management and/or engineering. But since the entire company relies on the stack rank as a foundation for the roadmap, it's good to periodically reconcile the prioritized list with the development plan.

A collaborative stack ranking party is a great help in balancing all these demands, but a product manager's learnëd intuition and good judgement is a tool not to be underestimated.

How a perfect stack rank can mess things up

Here's the problem with always working off of a really well-done stack rank: when do you get to the potentially disruptive stuff? Ranking tends to result in a coldly realistic plan that will refine a product but won't help it reach for the stars. In other words, risky R&D investments rarely get near the top of the list.

One remedy: "set-asides"

If merciless stack ranking keeps you away from the truly fun stuff (transformative, visionary, whatever business-ese you prefer), you can get back to it by agreeing up front on a development budget that sets aside time for speculative work. An example will make this clear.

"Up front" can mean at an annual kickoff, or some other moment when the bulk of a business unit will come together as one team.

pie graph One year, I established a 40/30/20/10 framework, meaning 40% of our time would be spent on one bucket of initiatives, 30% on the next, and so forth. Your buckets and the appropriate percentage breakdown will vary, but ours at the time were:

  • 40% new features
  • 30% minor enhancements and fixes
  • 20% performance
  • 10% de-cruftification (refactoring, code cleanup, and other tasks the engineers need to do to keep the engine spinning under the hood)

"Performance" in this context means specific projects (epics, in the agile sense), not the kind of constant focus on performance that a team should always practice. Calling out performance and refactoring explicitly in the budget is a way to say to everyone that only x percent of dev time is "discretionary". That's a good way to help sales and customer-facing teams understand why you won't get to scratch all of their itches.

The idea is that if you've said 40% of your time is for new features, even if the stack rank puts a lot of bug fixes higher in priority, you'll still chop the stack into pieces and pick items from each, according to your framework.

Naturally, the percentage breakdown is hardly sacrosanct. It's only a rule of thumb, and interrupts happen to the best laid plans. But by establishing such a framework early on, you can try to hold yourselves accountable to it. Again, the goal is that at the end of a year, you don't want to look back and see that you only spent 4% of your time working on the 40% bucket.

visionary And provided that one of your buckets is dedicated to swinging for the fences, you'll at least have given yourself a chance to do the fun disruptive stuff.

Thoughts?

Do you have tricks of your own? Have you tried something similar and found it to work—or fail? Share it below.