I’ve previously trailed a massive blogpost-that-might-be-a-book about roadmapping, but I suspect it’ll never get finished enough. However, earlier this week I was at a chat about the future of Product Craft within government, and mid-discussion spontaneously reeled off a list of my top reckons on the subject. Given that I had managed to do it on the fly without much thought, I decided to have another go – using largely the same scrappy approach.
Caveats: 1) this is ‘perpetual draft’; 2) unlike a lot of product writing it’s aimed at larger organisations where technology/digital is seen as a supporting function to “the business”; 3) these are in no particular order of priority; 4) these comments are aimed at no particular team I’ve ever worked with.
Roadmapping is more important than an actual roadmap. Too often we do a massive one-off exercise and then never look at the damn thing again. We need to get good at these discussions. And at turning them into an artefact that’s up to date.
External milestones can go in, delivery dates can’t come out. If something needs to be delivered by a particular date because something else essential is happening, like a transmission date or an event launch, then that’s essential context for the team. Not telling teams that context is pretty negligent on the part of leadership. But…beware external forces loading extra fake external milestones to try and make projects go faster.
(In the image above, you’ll see the pink postits at the top. This is another aspect of capturing context – me saying to the team “what I think will be happening in the organisation at this point”)
Now/next/later may be your friend – it isn’t everyone else’s. Too often I see “later” being used as a catch-all for everything we’ve ever thought about ever – a place to put stakeholder promises we’d rather forget. The new “icebox”. But this leads to two problems. Firstly that teams haven’t truly thought about which parts of “later” are the most important – they don’t know the critical path to getting “the most likely thing” to happen. Secondly, because they don’t know much much “later” there is to be done, they don’t know how quickly to declare their “now” done so they can move onto “next” and get to that important pile of “later” before funding or patience runs out. Which leads to…
Roadmaps aren’t delivery plans. But you should regularly have a go at trying to create one. The process of trying to turn that pile of ideas into a delivery plan is – in itself – an important activity. It flushes out truly critical unknowns – what’s it going to take to know whether that crucial item will be one month or six? How soon is it sensible to investigate that?
Include discovery activities in your roadmaps – what are you trying to find out? You really don’t want to be taken by surprise when starting something new, and you also need to focus the minds of your stakeholders on any decisions that they need to have made, or the most important things they need you to find out, if those precious developers are going to keep on working on the most important things. Don’t have the team hanging around for two weeks while you wait for something to be signed off!
Changing your roadmap based on new information is important – but is part of your governance. Too often changes to roadmaps or changes in scope happen quietly in the corners. We had all those caveats on the slide saying “this may change at any time”, right? And hey, we don’t want to worry people, do we? Sadly, this means that we end up hiding important knowledge from those who most need to know it. What have you found out that means the plan is wrong? How might it affect the overall strategy? The biggest danger is that your leadership are still out there proudly defending a plan that you know is wrong, and they don’t. They’re doubling down on bets to give you air cover, that you know they should be backing away from. Projects used to run late, but the decisions about why led to inspection and improvement. Just because we’re agile, it doesn’t mean we should let ourselves off the hook on this important process.
Know how to safely change your roadmap. Find out who needs to know, and when. Make sure they’ve always got easy access to the latest version, and know what’s changed. Showing a senior leader a roadmap, but then saying they’re not allowed to show it to anyone (because you’re worried it might change) helps nobody. Like planning, you need to learn from devops or incident management. If it hurts, do it more.
The best roadmaps are made of problems to solve, with value attached. I love outcome-based roadmaps. Ideally there’s a supporting document that expresses them as a set of candidate/possible OKRs (depending on how far out they are). OKRs are harder than they look, particularly if done as a process or culture not an artefact i.e. properly, but the thinking behind them is really important. And hard. Which is why people try to get out of doing it. HOWEVER, if a team doesn’t have a sense of how much value is going to be released by looking at a particular problem – and there’s not a business stakeholder on the hook for getting that change to happen in the real world – then there’s no way of knowing how long to spend on that particular problem. So people over-research, or gold-plate features. Know how many weeks of effort would be break-even, at the very least.
Sometimes it’s ok for the roadmap to have nouns in, if that’s the best way to create alignment. Don’t be synthetic and bury the lede. Sometimes the end result really is “replace legacy system x before the contract runs out”. Don’t dress it up as an outcome and confuse the teams.
Everything on the roadmap should have lots of context, that’s easy to find. Sometimes we’ve talked about possible ideas that could release the value, which might not be terrible as starting points. We waste time getting teams to think about it from scratch. Sometimes there have been lengthy discussions about why this thing needed to be on the roadmap. The team shouldn’t be five weeks into the quarter when someone finally digs out a deck containing critical information from their inboxes. “I thought you’d seen this” is a way of offloading the lack of preparation onto the teams. Lead with context, or it’s your own fault. Have a folder/confluence page for every big outcome, as soon as it’s on the roadmap.
Make sure the roadmap is tied to something based in the real world that shows why this is the roadmap. As Janna Bastow says, your roadmap is a prototype for your product strategy. Explain your product strategy that led to you making the roadmapping decisions. Make it easy to understand and easy to find. What are the even/over statements or principles you use to prioritise; what’s your understanding of the business context that led to you making these calls? Transparency here is critical. Radiate intent, so that if one of those principles turns out to be false, people can help you alter your roadmap to deliver the right value sooner. It also shows you understand your organisation. Which leads to another point…
A roadmap is a strategic alignment tool for building trust. The way you use your roadmap, the way you explain the decisions behind it in ways that have empathy for those that depend on you, the way you show your thinking…it’s all part of a two-way conversation. You need to use it for user research and to build understanding, not just for telling people why you’re right. You want people to know you’re acting in the organisation’s best interests, with integrity.
There will always be someone who wants to use it as a delivery plan. To defend against this, make sure that you have the air cover about these ways of working, and is prepared to back this at a senior level. (Which means giving your leadership something useful to work with – they need some of the raw material, and the behaviours, above). If you’re behaving responsibly and sharing bad news appropriately, the organisation should be able to say that they were foolish for taking it as something concrete, rather than being able to “hold you to account” for a document they clearly misinterpreted.
But dependencies, Tom?
I’d also say that sometimes you do have to commit to a date. Marty Cagan talks about these as “high integrity commitments” where the team is given the time to do the investigation to work out how long something is likely to take. But I’d say you can only have one high integrity commitment at a time – because there will be unknowns and other stuff is going to have to flex. (Remember, the BBC adopted agile methodologies on the Wimbledon set-top-box application because it kept missing deadlines, and agile was what let them ship something in time.)
However I must admit I worry about this phrase. It should be the team making the high integrity commitment. But, like “Minimum Viable Product”, I think there’s a risk of it being devalued when leaders think it’s their job to make the high integrity commitments – that it’s their integrity that matters – and the teams are just there to deliver against that spent political/social capital. I hope I’m wrong. But let’s see.
