There are certain sentences technical leaders dread. "I think we might have been hacked" is one of them. "I got an offer I can't refuse from the competition" is another.
But the most bone-chilling question out there seems to be: "Can you build a roadmap for the coming months?"
The stakeholder asking that question has no idea of the can of worms he's asking you to open. Developers will whine about the nature of estimates. Product managers will try to push a bunch of unreasonable features. To technical leaders, it feels like they're being asked to make promises that will come back to bite them in the rear.
Such a simple question triggers an avalanche of stress.
With December around the corner, roadmapping season is upon us. Instead of sticking to a realistic 2-month plan, CTOs worldwide are invited to the big meeting: roadmap 2024.
But why do stakeholders ask for such a roadmap? What problem are they hoping to solve?
Over the years, I've learned that there are many reasons to ask for a roadmap. While the question is similar, the problems we try to solve are very different. To build a useful roadmap, we must understand why we're building it in the first place.
So, what do stakeholders ask for when they ask for a roadmap? Turns out, it's usually one of three things:
Internal roadmaps
Companies have strategic goals they want to achieve in the next few months. They see risks or opportunities and want to tackle those head-on.
Let's say the company believes rolling out a mobile app will be the next big step to market domination. Saying we'll build that app is easy. But, allocating the right resources to deliver it while keeping the rest of the systems on track is hard.
When this stakeholder asks to build a roadmap, they're not asking for a Gantt chart that predicts the future. They're asking for a tool to keep our eyes on the ball. An early warning system that goes off when we're not doing what we said we would do.
The thing to keep in mind is that this roadmap is internal. It won't be shared with the rest of the world. So, we get to be explicit, honest, and, above all, flexible. It's OK to reprioritize as long as we keep our eyes on the goal. There are no hard deadlines, but there is accountability.
Such a roadmap typically comes in the shape of a timeline taking into account planned features, that new mobile app, technical debt, and operational workload. Here, Iterative Buffer Planning really shines. These roadmaps allow the stakeholders to ask When questions and see the impact of switching priorities.
Budget estimate
Let's say the same company plans to hire a bunch of mobile developers. Their engineers have been complaining about the workload and have made their point: if we want to build that app, we're going to need more people.
It's common for a stakeholder to ask a roadmap for a team that hasn't been assembled yet. What? How can we plan if we don't know who will do the work and when?
The point of this question isn't to predict the future. The stakeholder knows that you can't plan resources you don't have yet. What they are really asking is: "Give me an insight into the expected workload so I can justify the hiring budget."
They're asking you to quantify the request for more people. It's another internal roadmap that doesn't have to be exact but needs to be indicative.
This usually comes in the shape of a spreadsheet with high-level work items and estimates. Don't forget to include 25% to 50% of operational buffer. If this spreadsheet shows around 400 days of mobile work, the stakeholder has all the tools to defend hiring two more full-time mobile devs in 2024.
Public roadmaps
Finally, stakeholders might ask for a public roadmap to share with customers and investors. This is where roadmaps get their bad reputation. If you publish a tight timeline with a bunch of explicit milestones and deadlines, someone is going to keep you to those promises. It's as risky as it gets.
The reality of doing business is that there's nothing our customers love more than the next big feature. Clients who are happy with the current product would be a lot happier if it also did X. Shareholders and investors know this, and an ambitious roadmap is a sign of growth to them. That's why every company wants some kind of public roadmap, risks be damned.
The problem we're asked to solve here is: "Help us show that this company is growing in the right direction."
Here, the last thing you want to do is show a detailed timeline. As soon as such a promise is public, you've lost all flexibility. One minor setback will cause a ripple effect, and your public promise will go bust. Luckily for us, customers and shareholders rarely care about all those details. They only care about certain big features.
This roadmap typically consists of vague high-level improvements and a rough estimate of when the customer can expect the first version. It's crucial that we keep both scope and timing flexible while showing our intentions. "Performance improvements in Q2" is a good example.
Customers will demand we give them a timeframe for a feature but won't be angry if that Q3 mobile app only gets delivered in December. They will hold us accountable if we completely ditch that promise, however.
The public roadmap is an advanced skill. I'll dedicate a future edition of the Planned Attention newsletter to that. One of the most crucial takeaways is ensuring your team masters internal roadmaps before trying their hands at public ones. If you can't keep your word to those lenient internal stakeholders, you're not ready to make big promises to customers.
These are, in my experience, the most common reasons behind the dreaded roadmap question. If we can figure out what problem our stakeholders try to solve, we can give them the right tools.
So, next time someone asks you for a roadmap, ask them why. Is it an internal one for keeping the team accountable? Is it a budget estimate? Or do they want to show growth to customers and investors?
The answer to that question will decide the kind of roadmap you'll need to build.
Very good read again! Thank you!