Prioritizing Product Decisions by Impact & Investment
Ah, the feature backlog — where bad ideas go to die, and good ones risk being forgotten. If you’re like most product folks, the thought of wading through your entire backlog should make you shudder at least a little bit.
One way to get some fresh perspective is to consider the above “investment-impact” matrix, variations of which some of you may have seen before.
Impact may be thought of as the amount of value a feature is expected to deliver to your customers — which problems will you solve, and what outcomes will you help them achieve? Investment is the level of effort required to deliver this value. Sorting features by these quadrants can provide some high-level guidance on whether they’re worth building. Consider the following.
Lower Left: “Meh”
Features that fall in this quadrant don’t cost a lot to build, which is great. Buuuut, they don’t deliver much, if any, value to customers. So, why build them to begin with? In a word: “meh.”
Lower Right: Easy Wins
If only every product management decision fit into this quandrant… This is a mythical land where features are easy to build and deliver huge amounts of value to your customers. If you’re lucky enough to identify an “easy win” feature, take the lay up as soon as possible and move on to the next one.
Upper Left: Obvious Losers
Why would anyone in their right mind prioritize a feature that requires lots of effort but is unlikely to provide value to customers? Apart from technical debt, the answer is: the levels of impact and investment involved aren’t not always clear at the outset.
Upper Right: Big Bets & Tough Calls
When you’re assessing an item that’s likely to require lots of effort — but there’s good reason to believe it will pay off down the line — you’re faced with what are sometimes referred to as “big bets.” We sometimes also call these “tough call” features.
Sadly, the majority of backlogs aren’t made up of mostly easy wins. And, at the outset, it’s not always possible to identify the obvious losers. What this means is that your backlog probably looks something like this:
Assessing the 68%
It can be hard to see the tradeoffs involved when assessing a set of features from the big bets/tough calls category. If we build say, Subscriber Reporting, which features are we saying “no” to? Which customers will this decision impact positively? Which will it impact negatively? What’s the overall business impact?
Gaining at least a general measure of these opportunity costs is especially important when level of investment is high. Why? If 400 of your engineers’ hours are going to be spent on a big feature, that’s 400 hours that they’re notspending on other features that solve other customer problems.
The good news: It’s possible to organize your feature backlog around data values and other important considerations — such as measures of pervasiveness, recency, business impact, and team consensus. Here are a handful of the fields we at Wizeline when prioritizing our backlog to help sort the wheat from the chaff.
And here’s an example of what this might look like in Wizeline:
Here you’re able to see the prioritized features (those above the wizeline) and the un-prioritized features (those below) relative to our release budget, which is in this case 50 points. It’s in this single view that you’re able to gauge and visualize tradeoffs — what you’re effectively saying no to and why, and what the impact is to customers.
How does your team organize backlog items and prioritize features? Send us your thoughts and feedback via Twitter @thewizeline.
This post originally appeared on Behind the Product, Wizeline’s blog.