Product Roadmap in a Rut? This Chart Might Help.
The more users ask for a thing, the higher we should prioritise it, right? Well, maybe…
Some time ago, in a discussion about managing mature products, I drew a diagram on my notebook. We were talking about how easily we can get bogged down delivering what’s expected, and not spend enough time on fresh ideas that might invigorate our product.
I wrote this post partly to solidify my thoughts on the topic so it would be great if you can let me know what you think. Could this be useful in being more deliberate about what blend of obvious vs. radical improvements we need? Is it just another version of something that already exists? Comments welcome here or over on twitter!
Quick wins (small, obvious)
These are tactical improvements or new features which are relatively cheap and relatively low-risk. They’re either things users request often, or small changes to drive a product or business goal, e.g. increase conversion for some existing call-to-action. We’re expected to do some of these, but I need to make a conscious choice about what percentage of our time the team should spend on them.
Core features (big, obvious)
These are the items we’d expect to put in our roadmap, and there’s some expectation that we’ll deliver them at some point. But I still want to confirm that they’re the right thing to do. (More on this down the page.)
Sometimes all of the team’s time will be taken up with these first two groups. And that might be OK if it’s our strategic choice, for good reasons. But we shouldn’t let this happen by accident, and I mustn’t close myself off to unexpected ideas.
Small bets (small, radical)
These ideas are more imaginative, but still modest. They might build upon output from a specific activity where we explore ideas off the beaten track like a hack week, or they might have come up in discussion or user feedback and been parked in the “maybe one day” list. Unless the team is fully committed with “obvious” work (which should only happen as a conscious, strategic choice, see above), I’d want to explore some of these via safe-to-fail experiments. First, I’d prioritise by potential gains. What would happen if the feature is wildly successful? Where might it lead next? Could it inspire a change in strategy? And I’d want to think about the biggest risks and the quickest, cheapest ways to reduce uncertainty, which might not be by building software.
Radical changes (big, radical)
If we own a product at a point of stagnation or decline, a shit-or-bust gamble might be preferable to the certain doom of doing nothing. But for mature products in reasonable health, betting multiple team-months of effort on some new idea, however eye-catching, is often not palatable. That doesn’t mean these ideas are off-limits though. As with the previous two categories, I’d want to think about the potential gains and potential risks to success.
Reducing uncertainty
Our risk heat-map for this diagram would look like this — bottom left corner is the least risky, top-right is the most. The higher the risk, the more care I should take to confirm the idea is a good one. That starts with identifying the biggest risks to success. Will the customers hate it? Might it be technically unfeasible? What if the business benefits aren’t there?
Now we have a list of the biggest unknowns, and where getting it wrong would have the greatest impact, we can think about relatively cheap, relatively safe ways to learn as much as possible before embarking on something bigger. Can we deliver in small steps to reduce the uncertainty, iterating our way to the right feature, learning as we go, or cutting our losses and pursing a different course if we find out we’ve got it wrong? If that’s not realistic, is a Design Sprint a good use of our energy, to experiment with ideas and test the attractiveness to users without creating an actual production release? Can we spend a few days’ engineering effort exploring technical feasibility?
On reflection
I didn’t realise before I wrote this up that the same two themes would come up again and again:
- we should be conscious of the biggest risks to success, and think of the smallest, quickest and cheapest ways to reduce that uncertainty
- we need to be deliberate in how we spend our time because reactive, tactical work will divert us from our strategy if we let it
This is basic Agile Product Manager stuff, but it’s easily forgotten, especially when we’re facing the day-to-day challenges of managing a mature product.
What do you think? Might this map be helpful for your product? What have your experiences been in trying to balance what’s expected with being more inventive?
