Tom’s Roadmap Heuristics – a work in progress

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.

A kind of roadmap of sorts – this early one got thrown away almost immediately.

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.

Show your decision points – added 4th December

I touched on this in the session last week, but forgot to include it in this post. We tend to act as though a given team or initiative can just trundle along, working through the quarters – but sometimes we need to call out a point where we take stock and make some hard choices. Everyone needs to know that’s happening, so they’re ready. In traditional GDS-style life-cycle this would be “has your alpha proven you should do a beta” (or – even better – “has your alpha disproven the hypothesis that a beta isn’t worth it”). But it might also be when you decide whether getting from 20% to 50% on a metric is worth the effort.

I tend to put these in the “context” – and yes on a quarter-based roadmap that’ll be a clear timeline, but in a now-next-later roadmap it needs to be somewhere that everybody knows about and which is discussed regularly. A slide that appears in every checkin/huddle/show&tell, as appropriate.

The reason we should make this very visible is because the team need to be ready for that decision to be the best one possible. And they need to talk about it to the decision-makers early on. “Dear Senior Civil Servant, what will make you think that this service/app/portal is delivering OK, but ultimately is a great/terrible idea – so we can get you the evidence for a good decision”. It’s a constraint that helps people prioritise the most important learning to get to the next good decision. And it helps prioritise discussions with wider stakeholders about what matters when: “I know you want us to look at feature x, but is this going to help us make sure we’re ready for that big meeting in July, or is the team going to look unfocused and then put onto something else?”

But dependencies, Tom? (Take 2) – added 4th December

OK, so I slightly got distracted by the above rant about High Integrity Commitments. And yes, I was also tired and just wanted to press ‘publish’. So here’s a better answer. But it’s probably not the one anybody is looking for.

People worry about how you use roadmaps to track dependencies between things. Rightly. But the problem in this is a twofold one of forgetting:

  • Even in old-style project management, dependencies were a total pain to manage, and often a lie. Yes, there’s a bar in MS Project saying that something’s going to finish at point x and then a different bar can start work. But in practice, this was a mess of handoffs and delays and horsetrading and miniature scope-creep/disappointments. That little dependency tool is a fractal mess. So please don’t put the blame on roadmaps for this being hard.
  • Many folks haven’t done tons of this in more traditional environments, so it takes them by surprise – we have forgotten how to have these conversations as a practice.
  • Within the world of empowered agile teams, we see anything that stops every given developer running at 100 miles an hour as an impediment to be reduced – rather than The Actual Work Itself. And that leads too easily to power imbalances – that this is ideally someone else’s problem. We’ve forgotten how to collaborate in an authentic fashion.

So there are a few techniques to apply, and they’re not really even “roadmapping”.

Firstly, as Marty Cagan says in “Empowered”, make sure the teams working on the same things have the same OKRs. Someone’s side-project or favour can’t derail a whole quarter’s work.

Think about the layers of dependency.

  • sensibleness – should we do this
  • feasibilty – can we do this
  • approach – how will we do this
  • confidence – how much it’s likely to change
  • delivery – when will it be ready

Some of those you may be able to put into a team’s OKRs. Team A: by the end of the quarter, you need to have shown this has value and can be done, and have a draft approach you and Team B are 70% sure they can work with. Team B: you need to be 70% sure you can adopt the thing they’re talking about, and it’s going to be valuable for you too.

Perhaps the delivery date is the key thing – in which case you’re in the world of scope management and making sure everyone knows the minimum feature set across both areas – and this is all anyone talks about. You’re storing up risk for the teams further down, but hey.

But the detail of how those five factors unfold and mesh together over time is not something you can just leave to chance on a roadmap – just like you couldn’t on project plan. Making it happen is the real work. And doing in such a way that anyone in any team can pull the (conceptual) andon cord because after user research or tech spikes they’re not convinced this is a good idea any more – rather than just delivering blindly and hoping – that’s the real hard work. But we have to do it if SAFe and its false certainties aren’t going to somehow take over.

5 thoughts on “Tom’s Roadmap Heuristics – a work in progress

  1. Pingback: Week notes: 27 November – 3 December 2023 - Neil Williams

  2. Pingback: Weeknotes – Ending 01/12/23 – Bridging Boundaries

  3. Pingback: Weeknote – 3rd December – some light unfurling - LeaningForward Blog

  4. Pingback: Nudging along the government (DDaT) product management career framework - LeaningForward Blog

  5. Pingback: How do I make my product roadmap a better communication tool? – I Manage Products

Leave a Reply

Your email address will not be published. Required fields are marked *