Let's discuss the basics of stack ranking, including one key issue that can arise when it's used alone, and the “budgetary” approach that helps fix it.
Stack ranking
Simply put, stack ranking (AKA 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 rank obviously isn't an order of events. 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.
A collaborative stack ranking party is a great help in balancing all these demands, but a good product manager's intuition and 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.
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 (more commonly known as tech debt paydown: refactoring, code cleanup, and other such tasks)
"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.
So, 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.
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.