No more roadmaps
Product managers spend aeons creating and rearranging them. Delivery managers obsess over their dates and dependencies. People in “the business” plan financials, campaigns, and more around them. But engineers—the people tasked with actually delivering them—mostly moan about them. The engineers are closest to being right, because roadmaps are little more than detrimental fantasy.
We’ll talk about why, and what I suggest you do instead, but first I want to be clear this isn’t merely a hypothetical opinion piece. At the start of this year I proposed a complete ban on roadmaps at Zego and while lots of people were worried about the implications on the way they work, fatigue with the failed promises of roadmaps led to everyone agreeing to give it a try.
The topic of roadmaps never came up again. Nobody missed the time lost creating or maintaining them. Nobody missed the pain of trying to change what was baked into them. Nobody missed planning around dates that never materialised anyway. Roadmaps just went away, and nobody missed them.
So what happens when roadmaps just go away? What do you do instead?
The biggest concern most organisations will have about ditching roadmaps is how they’ll plan when there are no dates, for example how can a new marketing campaign be planned if the marketing team don’t know the projected launch date. How can financial projections be made if key rollout dates aren’t known? The solution, in the immortal words of Maximus Decimus Meridius, is “we’ve got a better chance of survival if we work together”.
That’s it. That’s the answer. You work together. It really is that simple.
When planning and running projects, don’t have only engineering involved. Involve all the people and teams across the company you’ll actually need for a successful launch. Instead of keeping them at arms length and just updating them on the launch date, get them involved in planning and catch-ups, work with them on requirements, and see what solutions they come up with. Make them part of the project. When you’re working on it, they’re working on it, and you go live when all teams are in a state to do so, not when engineering decides they are ready.
Okay, sure, that’s the shorter-term stuff. But what about the longer term planning? What about things that would normally be planned months in advance?
Ignore them.
If you’re not actively working on a project right now, then don’t bother planning things around its launch because the date won’t be when you think, and it might not even happen. Business priorities shift—particularly once you’ve got rid of roadmaps so they’re allowed to shift—and what seems important now might not seem so relevant in a couple of months time. Anything you do in anticipation has the potential to be wasted effort, so don’t do it. Focus on things that are actually happening soon.
How soon is soon? I’d suggest about six weeks is the sweet spot. I don’t really have any good rationale for this other than six weeks feels like a good sort of timeframe to have an idea of what you’re doing. It’s long enough to deliver some pretty serious value without having to shoddily hack a temporary solution together, but short enough that you won’t be too swayed by the sunk cost fallacy if you realise it’s not working out or you want to go in a different direction.
Sometimes, though, you do need to plan longer term. You’re always going to have a small number of projects that need to hit a particular date, for example launches that have a significant impact on a financial model, or improvements to meet regulatory requirements, or upgrades to meet a deprecation date. This doesn’t necessitate you throw the baby out with the bathwater; you can treat these as special cases where you work backwards from the dates and ring-fence people to work on them, while taking the shorter-term planning approach with everything else, and keep much of your agility.
Agility. That’s the huge benefit you get when you ditch roadmaps. You start to get some business agility back because you’ve no longer got the next six-to-twelve months of deliverables baked into a Gantt chart, but instead you can constantly reevaluate what’s most important to the business and whether your plan for the next few weeks is delivering the most value, in the most efficient way, and change it if not.
I know that’s probably not the definition of agility you’re used to, but that’s because I’m talking about real agility, not the Capital-A Agility from the Deloitte playbook. I’ve got a lot more to say about agility, but it’ll have to wait for future posts because we need to get back on track denigrating roadmaps.
Anyway, to get the benefits of agility, it’s essential these six-ish week periods where you’ve got plans aren’t treated as iterations where you do six weeks and then plan the next six weeks. Instead, you need to treat it as a sliding window where the next six weeks from now is always being evaluated, current projects are being assessed to see if they’re on track and delivering the right value, and ideas are moving into and out of scope. This should be a continuous process, where decisions are made daily or—at most—weekly about changes to the current plans.
You’ll find you change plans a lot more than you thought you would, because you’re always assessing them against the value they can deliver.
That essential project you thought would take eight people two months, but now it’s better understood you realise it’s going to take twelve people and another three months, does it still deliver sufficient value for the new effort? Are there tactical solutions you could take instead which might not be as satisfying from a technical or product perspective, but which deliver sufficient value sooner for much less effort? If you’re evaluating what you’re working on constantly you’ll be much more likely to ask these questions—and act on the answers—than if you’re just shuffling out end dates on a fixed roadmap.
Those little features and fixes that never got onto the big static roadmaps because they were too small or insignificant, can you now get them done when you see they could easily be shipped in a couple of days and add incremental value, or ease the frustrations of customers?
Those unplanned events like realising your database needs attention because you’re maxing out your IOPS at peak, or a security report which you need to spend a few days investigating and patching, or the engineer with critical knowledge on a project who called in sick and will be out for a fortnight. These change your immediate ranking of what has value and what can be delivered, so your plans change to accommodate them, and it doesn’t phase you because you’re doing that all the time anyway.
You’re no longer entrenched in the routine of delivering something because the roadmap says that’s what you have to deliver. You’re always looking at what can deliver the most value in the best way.
A lot of companies go through the phase of thinking they need to introduce OKRs because they realise they’re busy all the time but nothing that really matters seems to have changed much over the last year or so. I’ve been through that myself. I’ve introduced OKRs myself. But it doesn’t work if you still have roadmaps because you’ll always be coerced back into the mindset of thinking in terms of deliverables rather than value.
If this sounds familiar to you—and trust me, I know this sounds very familiar to a lot of you—then don’t try and fix your lack of ability to deliver value with sticking plasters like OKRs. Fix the root causes instead. Like roadmaps.
No more roadmaps.
