Should a roadmap be aspirational? | Justin Woods
In episode 1 of Talking Roadmaps, Phil Hornby engages with Justin Woods, a roadmapping expert, to explore whether a roadmap should be aspirational. They discuss the importance of balancing ambition with realism, the role of roadmaps in strategic planning, and how they can effectively communicate vision and progress. Justin shares insights from his extensive experience, including practical tips for tech teams to create and implement effective roadmaps.
Justin is a roadmapping expert with many years product and tools experience dedicated to improving the craft of roadmapping and bringing it to the world.
He is also the founder of Roadmap Heroes where they empower tech teams to plan strategy, track execution, and clearly communicate using roadmapping tools. They offer a variety of consulting and training services are based on over 20 years experience in software/product roles and hundreds of successful client implementations. Delivering better roadmaps supported by tools.
“It should be an aspirational journey of where we are and where we want to be”
We’ll let you watch the video instead of telling you everything it says. There will be a full transcript of the discussion available soon along with a sketchnote to summarise and a blog post of the best bits. We pulled out Justin’s views on Best Practice and Bad Practice here though.
Best Practice
- Think about what roadmapping is and what it isn't.
- Sit between strategy and execution.
- Strike a balance between being specfic enough and aspirational.
- Communicate it often and take the feedback.
Bad Practice
- Too much information, creating problems and overload.
- Calling a delivery plan a roadmap.
- Not shared often enough and kept up-to-date.
- Be careful of putting progress on the roadmap.
If you prefer to just listen then check out the audio only below - this will also be published on as a podcast on Spotify and other platforms as soon as we work that bit out!
Look out for Episode 2, where Justin will be interviewing Phil Hornby, Product Leadership Coach!
-
Justin, welcome. Great to have you
Here for, thank you.
Yeah. Officer, we're going to explore road mapping, particularly in the context of products and product management, but I know you have a world you operating where you take roadmaps to a broader audience.
Indeed. Yeah, indeed. Sorry,
Go on. I guess we're going to explore a few things, but I do want this to be conversational. I do want this to be a chat between two friends, not an interview. I'm not grilling you and deciding whether you get the job or not.
Good. So I don't need to wait for any competency-based questions. Then Phil, we can actually have a bit of a giggle on as well. No,
And I'm not even going to do the behavioural questions either. I'm not going to be checking for those. How do you behave and all those things, whether I give you the job and what was your greatest failure, greatest success. We'll try and invite those ones.
Good. Sounds good. Sounds good. Perfect.
So yeah, the aim is to really understand road roadmapping, your perspective on it. I mean, I've got a few questions I want to run through ask, going to give some broad structure, but if you say something interesting, we'll probably go off piece and follow down that rabbit
Hole. I think we should, I think there's going to be multiple places where we can go off and down there, so we'll pull each other out where necessary. But yeah, I'm looking forward to going into that.
Perfect. Wonderful. So I guess I'm going to start with one of those core really fundamental ones. What in your head is the purpose of a roadmap?
It's a good question and I think roadmaps over time have been quite misunderstood. I think roadmaps are like opinions. Everyone tends to have them and they all tend to look different from each other. But for me, a roadmap really fulfils a couple of different purposes and I think there should also sometimes be a couple of different roadmaps as well, and that might be one rabbit hole that we go down at some point later. But essentially a roadmap for me is a communication tool. It's designed to communicate a philosophy or a vision, a product direction or a company direction and promote awareness to other people. We have large teams, distributed teams in these days as well where we want to be able to unite people around a common understanding. So communication awareness is an important one. I think also these roadmaps can be used to get everyone on the same page no matter what level they are within the company. So you need sometimes them to be an alignment tool to be able to align teams, but I think you also need them to be a buy-in tool as well. You need to share this out with the business because you've got multiple teams that are going to need to get behind you and buy into this vision that you're trying to share them. So the buy-in is an important piece.
Interesting. Sorry, couple points I'd really to pick up on that. So you talked about buy-in, so does that mean people are allowed to disagree with it and there's a discussion?
I think so. I think these tools or roadmaps themselves are designed to invoke a level of discussion because ultimately as a product leader, as a product manager or roadmap owner even you are putting forth your strategy and your goals that have come from multiple places anyway. And so people are going to have different views on these things. But I think helping to understand the why that these decisions have been made, why are these things important? And the roadmap might highlight a discrepancy where actually you can bring stakeholders together and get them to talk in a room so that ultimately they can reach agreement of what thing to do. And it might be the ordering, it might be that some things are sequential, it might be the level of investment of money or resources, which actually I think is another point behind roadmaps, but I think people are allowed to disagree with it. But ultimately you want the roadmap to lead to where people do agree on something.
Yeah, I mean in that context, what do you think about the principle of disagree yet commit?
I think as long as people understand the why, I think it's absolutely fine to disagree with these things. We might not always agree. I've not agreed with some of the direction that I've had from my stakeholders as a product manager, but understanding the why and then getting behind that and knowing that we move further as a team than we do as an individual. And sometimes it's often that I might, it's not that I fundamentally disagree with the big piece that we're trying to deliver. It might just literally be about the timing. And so understanding, look, understanding the greater good this needs to come first and so I need to disagree but commit to what it's going to be. And I've done that many times before, but sometimes there's always little wins that we can put in after that. So it might be something, I'm going to deliver something for you, then I'm going to deliver something for me or for this other stakeholder. So I think the commit is really important and I think also it's okay to agree or disagree, but you don't want to be working in different directions that I think is fundamentally bad.
Yeah, I think I fundamentally agree there as well. It's like I remember when I was leading product teams having those conversations where we'd have the debate, but ultimately when needing to make a decision, there was a conclusion that had to come and consensus wasn't always the right approach. Sometimes that's the rule to mediocrity. I sometimes think,
Yeah, absolutely. And when you get into these product or road mapping type positions, there's a lot of stakeholders and they all have strong opinions and something to say. So I think trying to bring those people together and to get them to align and commit and also just showing that something, there's going to be a sequence to some of this work or we might not agree, but we believe in the greater good and we actually believe more sometimes in the strategic vision, the vision is going to be separate from the roadmap and again, we can come onto that later, but believing in the greater good sometimes means that the how or how the roadmap is going to say those things. We might just have to suck it up and just say, yeah, it is the right thing to do for the company or for the customer.
Absolutely agree. And actually you've talked about stakeholders, you've talked about all those other people. So who are the people that contribute to that roadmap in your opinion?
I think there's a lot of people that contribute towards it. I will contribute towards it as a product leader because I will understand the product better than hopefully anybody else. That's my job to do that. But that's not to say that there aren't some big players in the organisation. Often in former roles, when I was part of a telecommunications company, I was the product manager of a number of tools in a digital area, but there was also a strategy and planning department in another area. So then you start to say, well, who owns the strategy of the roadmap tool? Is it the product owner who owns the tool or is it the strategy and planning department that think that own the strategy and planning? And so sometimes you can often come at loggerheads there in order to try and resolve that. So I think there's always going to be stakeholders.
You are always going to bring something to it from your knowledge, from the facts and figures hopefully where we want to be making data led decisions, but also a level of gut feel. I've also seen organisations where the manager of that area makes decisions on the roadmap and I'm not sure I necessarily agree with that unless they are a complete product person. And then I think a lot of it is also down to the users. When I've owned product tools, they've been internal tools. So some of my stakeholders, and I use that term quite liberally because they hold a stake even if it's not necessarily significant, but they're the key users of my product and then they might have their users as well. And so getting all of that information into one place, I see those as all being contributors. So really the roadmap sometimes can be a bottom up to understand strategy and what everything is going on and then driving top down again. So I think it's important to bring everyone in on that journey.
And I think you've actually, you've talked about contribution, you've talked a little bit about ownership there as well, and you've talked a little bit about audience. What are your thoughts around that differentiation?
Yeah, it's a great point and we can often get stuck into this. Who owns the roadmap and what responsibilities there are? I think again, it's good to have structure, but you want to keep it. You want to have some process behind it. For my business analysis days, I've looked after documents, requirements documents or BRDs, and I've been of the mindset that I'm the of that document, but the various stakeholders are the people that own the requirements or the needs on there. As a business and analyst, my job is to faithfully capture that business need but not necessarily to influence it. And so because of that capturing that business need, the need comes from the business, not for myself. So I see myself as the owner of the document and I'm accountable for owning that and maintaining it, but I think other people will be responsible for the things that belong to that they bring to it.
Sure. And actually hinted at some related elements through this conversation so far, there's things I guess that feed into it, things that feed out of it, there are things that sit alongside it, different artefacts, different elements. I think you mentioned vision and strategy at one point. Can you give us a feel for that ecosystem, how they relate and from your perspective?
Yeah, absolutely. And there's also from what I believe and what I've experienced, so those could be different things as well. I don't think, again, every company does it consistently, but that's okay. But I think the roadmap itself is not the be all and end all. The roadmap should actually come after the vision and the strategy. We want to be able to understand what is it that we want to achieve before we start to think about what are some of the high level ways of getting there. So a roadmap is often talking about timeframes and where we are now and where we want to get to. I mean that comes back from when we navigate in our cars, we put in a destination and then it shows us the route to get there. I think that's where the term road roadmapping has really come from. So it should be this kind of aspirational journey of where we are to where we want to be, but the way we want to be is really captured in the strategy, the vision, the mission statement.
Those want to be the high level north star that we want to achieve. I think we should absolutely have a strategy before those things. I don't think we should have a roadmap without a strategy, otherwise how do you know where you're going? So I think some of those artefacts would be the strategy, some of the goals and initiatives as well because the goals and initiatives are the things that I like to bring down into my roadmap. So I can actually say this is a strategy where we want to go, these are the milestones that we want to achieve and some of the metrics and goals behind it and maybe some larger bodies of work. And I expect some of those to come down into the roadmap. And then maybe from that roadmap, what comes out of that are going to be things like agreement investment delivery plans and sort of execution side of things. So the roadmap sits in between those things. It shouldn't necessarily be delivery and it shouldn't necessarily be only strategy as well.
Okay. So it's a bridge between those two domains. I think some people would say between the strategy and the technical, I prefer to use the words operational for what we're talking about to be tactical problem solving. But yeah, it's bridging between that getting stuff done and what's the stuff we should be getting done and where should we be driving towards. I like that.
Yeah, absolutely.
I do also find it interesting that talk about a roadmap and coming from navigation, it's an interesting metaphor that we've chosen to use, I find of a roadmap because the map itself doesn't tell us how to get there. It shows us all the options.
Absolutely. And some of the roadmaps that I've started to lean into a little bit more are the ones where they start to, again, they should be aspirational. And I think there's often reference to the cone of certainty. So something that is near term, we're much more confident around what it is and that's what we're going to be going into next. Whereas we look further out, I mean hence the popularity of now next later as something is much further out, there is much less certainty around there. And the same is true of road mapping. We know what's going on in our local road network, but not necessarily further down. And so giving the flexibility to make those changes, setting some form of aspirational journey, but not actually saying that's specifically the way we need to go. I think the destination remains the same, but leaving agility in how we get there, is it going to lead to a more successful roadmap? And actually I think a roadmap that better stands the tests with the business because if you are prescriptive on how you're going to get there, there can always be problems with execution or operational side. Whereas if you are high enough level that says this is where we're going to get to around this time, then it's less specific on how you're going to do that.
Yeah, I mean you all know that no plan survive contact with an enemy or as Mike Tyson is famously saying, no, everyone has a plan until they're punched in the face. Absolutely seem to try and preempt everything that can happen, all the decisions we're going to make. I mean for me, I can't imagine that we can ever realistically do that. And yeah, if you try and prescribe the solution, I guess you're in that place. You are trying to preempt everything and you're probably going to be wrong.
Yeah, absolutely. And I think it feels more like a delivery plan as well. It's too specific, but some of the roadmaps that I've liked have been kind of a little bit conditional saying, Hey, we're going to do this initiative or we're going to go after this kind of opportunity, and at the end point of that we're actually going to evaluate whether that was successful and then go and do either if it was successful, we're going to try this or if it wasn't, we're going to do that. And I don't think we should get that completely in a roadmap otherwise it's going to look like a flow chart, but kind of some bigger picture type things of saying we're going to try this and almost bringing a level of agility into our roadmaps and not letting that be some waterfall two year document of what we're going to do I think is quite nice. I haven't perfected how that works and that's something that I want to research a bit over time, but ones that allow that flexibility I think is realistic and helps people to see some thought behind what we're going to do and how the curious nature of how we're going to do it.
I want to put just a flag there and use the words agility a few times. I want to save that till a little bit later, come back to it because agile isn't necessarily the panacea. Everyone talks about agility and agile a lot, and waterfall is this evil thing. Now some industries use waterfall methodology very effectively. So I think it's something to come back to. But you've also talked about a number of points there around different elements and context. You talked about a now next in future timeline, you talked about a timeline as well, and you've talked about app aspirational and direction or work, almost the destination being on the roadmap as opposed to the solutions. So can you maybe tell me more about what you think about as the key elements, key content of a roadmap?
Yeah, absolutely. And I think just coming in from what you were just saying there, I think timeframes, not timelines is one of the most important ones, whether that be quarterly basis or whether that be if we have specific releases because we've got a monolithic product or we're in hardware and we have to release during certain times, then sometimes that's a little bit inevitable. But we want to be able to decouple a business from thinking about releases when we're going to deliver software. And more around this is the focus on what we're going to be doing for the next three months or the next six months, whatever timeframe we want to use. But not putting timelines on there I think is really important. And again, that comes into agile side way of thinking, which is look, again, that cone of certainty, here's what we're certain we're going to be working on now based on all of our knowledge and all of our, what everything is telling us to do is right next.
We may consider these things and then in future, these things are kind of possible. And it's about, I think also educating the business on this. Phil, I might be going down a rabbit hole, pull me out, but one of my clients is moving to scaled Agile. And organizationally that's challenging because the teams have to get behind scaled agile. And the fact that we're not talking about releases anymore, we're talking about programme increments or a period of time, that then means that their stakeholders need to get behind scaled agile. But interestingly, they're also having to educate their customers on them getting behind scaled Agile because their customers are saying, Hey, what's in the next release? And they're trying to say, we were not working on releases anymore. We're deploying our software on demand, so we're going to communicate to you now what we're going to be working on in programme increments. And that's a really big journey for even the customers of a company that are external to the scaled agile process. So that's really fascinating to see that everyone has to come along for that journey.
Man, that brings us back a little bit to that earlier comment about audiences in fact. So you've talked about customers, you use that in the broader context of stakeholders. Now, do you differentiate what you think about showing to you the content you share with them? What's included in the roadmap for those different audiences? How do you think about that?
Yeah, I do. And I think critically here, and I can't emphasise this enough, one version of the truth is the most important thing, but that doesn't mean that it's the only lens by which it needs to be shared. And I really believe in that we need to make sure that we're all singing off the same hymn sheet. The single version of truth is that however you represent that in different ways, it's always consistent. But I don't think sometimes that high level stakeholders are going to be very interested in very specific information. Your users or your customers are going to be very interested in something else. Ultimately, we have to think about what do they want to see selfishly, they want to look at a roadmap and go, am I getting from this what I want to see? And so again, that probably comes down to another conversation we'll have about evolving the presentation of your roadmaps and what you show. But I do think that yeah, there needs to be that you need to tailor your roadmap to the audience because ultimately, again, we think about what that roadmap is for alignment and buy-in communication, awareness, investment of resource. If you can't get these people excited about your roadmap, they are not going to be on that journey with you, and therefore you might end up getting this disagreement and maybe a lack of commitment.
I mean, that strikes me as the sort of thing we talk about when I talk about presentations, a presentation you write for your audience, a communication medium. And so that roadmap as a communication tool, yeah, it's for the audience. It's not about what you want to say, it's about what they need to hear or how they need to hear it.
Yes, absolutely. For sure. And
That brings me onto maybe this concept of style or visualisation quite nicely. So any thoughts on that when it comes to roadmaps?
Yeah, I think I've seen so many different stars of roadmaps over the time. I think the most novel one that I've seen was a solar system where the various planets, the planets that were closer, the ones that work where we were sure we were going to do something, going all the way through out into the Milky Way and the solar system, which was the aspirational third horizon type thinking. But we need to be careful that we don't, it's not all graphic design and style over substance. I think the roadmap needs to show exactly what it needs to show. I know it sounds profound, but it needs to show exactly what it needs to show to do its job and nothing more. So if we overwhelm people with informational stuff they don't need to see, then you are probably going to dig yourself a hole somewhere down the line or you're just going to lose the message in the graphics.
But similarly, I've seen some roadmaps have been done in spreadsheets, and that's absolutely fine if that is appropriate, and that's what we've got. So I think there needs to be that balance between presentation and substance. But yeah, solar system was the most bizarre one that I've ever seen. And a spreadsheet is the classic one that we've all done because when we join these organisations and don't have road mapping tools, sometimes spreadsheets and word or PowerPoint is all we've got. And so we do our best with that too. But I think there's another thing that we might come onto, which is the difference between how you present your roadmap and how you manage that roadmap.
Well, heck, you've taken us there. Let's take me down that rabbit hole.
So I think they can be one and the same. I think the dangerous point is that, and this happens to so many people, is that we start off with our Excels or our PowerPoints, we create a roadmap in there, but then it becomes very difficult to what version is it? Roadmap 2022, final, final, final, final stakeholders name. And so versioning becomes difficult. Who have we given what? And as I mentioned earlier, we want a single version of the truth, but we want multiple lenses. And so how do you keep that consistent? I think for me, a tool can be a great way, as in a piece of software can be a great way of being able to centralise that information and make it one version of the truth. And sometimes we can use different filters on that to create different lenses for the stakeholders, but I've seen some of the tools have been very basic and they've not created beautiful looking roadmaps. And so again, I think there needs to be a level of finessing on your output so that people look at it and go, oh, I'm excited by that. I like the visuals, I like the colouring. Some people can't get excited by Gantt bars made by cells in an Excel, and I get that too. So I think where possible we should manage and present from the same system. We should never manage in a system where we're presenting the roadmap, trying to manage dependencies in PowerPoint. Good luck with that. We've all been there.
Yeah, I mean there's a couple of points I want to pick up there. One is what about dependencies and particularly in a portfolio context, is there a difference between mapping the path or the journey of a single product versus that portfolio or that product line of things that are interrelated?
Yeah, I think so, especially when we're working on large, when you're working on large products where maybe you've got multiple product owners or product managers working on components of that thing. So think a large portal and then you have different product owners on there. If those product owners are fighting for or vying for the same levels of resource, there does need to be some level of deconfliction also. It can sometimes be the difference between sequencing. It might be that we just do something before something else and that leads to a deconfliction of resources or effort there. But isn't that going into
The risking, turning into a project plan and that solution space mindset? Again,
It does, but I think there needs to be a level of that upfront, but even if it's just a light touch. So where I'm going with this is sometimes if we're looking at strategic initiatives and planning those out over the year or our goals, yes, it becomes very difficult to put a dollar cost or an effort there, but I've seen what companies do it well is just a notion of 30% of our resource or our effort is going to go here, 60% here, 10% here. If you don't plan for it at the top level, then it becomes very difficult to deconflict that lower down. But I think we do get down to that point then where we do run the risk of then creating a very high level prescriptive roadmap. So we need to do just enough in order to understand our priorities and that roughly we're going in the right direction. And then almost the next level down might be, again, not execution, but it might be, okay if this is the way we want to take these product areas and it unites these teams, now we want those teams to take those and break that down into their kind of initiatives. And so we take this multi-layered approach and some tools I've seen do that and they've done that quite well. I think if you try and do it all at the same time, you're not going to get there.
Sure. Now, maybe a slightly loaded question. I know you are quietly embedded with a particular tool, but do you have a preferred tool for working with mapping?
Well, I do, but also there's other tools are available and I'm always curious on what is there. So I think for road mapping, there's no doubt I've been an AHA user for the last seven years as both a customer when I was a product leader at Vodafone, then joined the company and now building a consultancy business around that as well. I think AHA does a lot of things well, but I think it's what we should look at with some of these tools is probably the philosophy around the tools and the owner and the organisation and what they believe. Because I think features are very easy to copy. They're very easy just to create and spin up. Sometimes we can deploy features in a matter of days, but I think looking at these various tools, you want to look at the philosophy behind the founders and what they believe in and what ties in with your product philosophy as well. So using aha I think does create some really powerful outputs. I think it's unmatched in terms of creating outputs and beautiful roadmaps and reports, but I sometimes feel that there's more that can be done in that space in terms of creating truly beautiful and engaging roadmaps. Other tools, for instance, might be much more lightweight, but the outputs they create can sometimes be a bit more attractive or they can be just a bit more friendly, a bit less corporate.
Yeah, I mean that back in the day when we met, actually, I was exploring Aha myself for my own team and I was about to source it. I suspect if I was choosing myself today, I'd probably go down the prod pad route just because I think philosophically it align better with my perspective. But yeah, I can get where you're coming from and frankly, I have the most my road mapping and PowerPoint. Absolutely. It's always had that single source of truth issue. So yeah, it's an interesting one. So let's take a segue now into thinking a little bit about the good and the bad of roadmaps. Sure. You've run into a lot of them here, so maybe you can give me some high level. What do you think is best practise when it comes to mapping?
I think best practises are around, and you need to think about what road mapping is and what it isn't. So we've already mentioned some deliverables that come up front, and I think we've also talked about some downstream things. We didn't actually talk about the side artefacts that may support that, but that's fine. But I think we need to understand what road roadmapping is and not try and make it do too much. It needs to sit, in my view between strategy and execution. So the high level big picture stuff versus kind of here's what we're going to start to work on in terms of our plans and it needs to stay there. It needs to get people excited around what it is that you're doing and get that alignment. And it also needs to strike this balance between being specific enough but also aspirational enough. I think a good philosophy around roadmapping as well as communicate it often and take the feedback from people always think almost bring agile to your mapping and say, look, this is the information I think you want to see as a stakeholder as a starter for 10.
Now you tell me, Phil, what you would like to do on that and what you would like to see on it. And the next time I create it, I'm going to create some more of that. Now we need to be careful that I don't then turn it into a delivery plan at your request. I need to put some guardrails up there, but ultimately this needs to be for you and it needs to make you happy and bought into what it is that I'm doing. So definitely make it a living document that should be communicated and reviewed often, not as a one-off exercise in Q4 and then put on a shelf until the next Q4 when we review what we've done
Interest. And there's two things I picked up there that I'd love to get your thoughts on. One is that, yeah, it's that living document, so that sounds like it's subject to change. It is plan A, but we're not necessarily going to deliver on it and stakeholders struggle with that. And the second one is, well, that bridge between those two areas of strategy and execution, it's also space occupied by another tool called OKRs quite nicely. And I think I've seen, actually Bruce McCarthy has a webinar coming up where it's OKRs versus roadmap death match. So I guess go to the first one first. I'd look to explore both of those with you. So kind of what's, if we think about what I say first, well, let's do the OKRs versus roadmaps while I remember the first question.
Yeah. So I think for me, I see OKRs as supporting that roadmapping process. So OKRs, I feel let's break them down into their objectives and key results. They feel very much like, this is what we want to achieve by this timeframe and these are the results that we're expecting to see. So I see them as points where it's kind of like this is what we want to achieve and how we're going to measure it, but I don't necessarily always get semblance of a roadmap from that. When I think of a roadmap, I am thinking of things following each other. So I think OKRs definitely need to be represented visually. And so when you represent your OKRs visually, you are getting a level of a roadmap there. Now, interestingly, or from my perspective, that doesn't necessarily tell you the initiatives that you're going to go after in order to achieve those key results.
So a key result is we need to improve customer satisfaction. Now we could do that by making our website better, and so it's more easy to use or we could do that by sending them a hundred pounds every month. Your customer satisfaction is going to go up, but the way that you achieve it can be completely different. And so I think we need to be careful sometimes in how we prescribe those OKRs. But I feel that again, it's kind of like it doesn't necessarily say what body of work we're going to be working on. A key result is not an initiative, it's what you're going to achieve, not how you're going to go after it. So I do see a difference there, but ultimately I would say that any company needs something. So if you don't have a roadmap or OKRs or goals or initiatives, then we are essentially being development led or going after and building the product and we're not looking strategically where we need to go. So I see OKRs as being very useful because it helps us to think about the strategic achievements, but not necessarily the strategic what we're going to do.
Sure. Perfect. And I think I'm broadly agree with you, so I think there's a close relationship there. Get there maybe those things on the side, those other artefacts on the sides that you hinted at. I'm going to go back my first question, I remembered it now. It was about we've being subject to change.
Absolutely. I think we need to preface this with, it's a starter for 10, this is what we know based on, or this is what we are going to set out to achieve based on everything that we know. That stuff may change if we're too prescriptive, who could have seen covid coming or the impact that it would have. And if you are so specific on something, then you set yourself up to fail. For instance, if we set up a true roadmap to get from me to London and we prescribed that I needed to use the car and then the car broke down, essentially I've not been able to achieve what I set out to achieve on my roadmap. If we keep it high level and say, Justin is going to get to London by Saturday and actually the car breaks down, but I arrive there on train, then that's absolutely fine.
So we need to be able to add a level of agility into it in terms of how we execute is different to what we're trying to do or why we're trying to do it. And I think again, communicating to people high enough at a high enough level that's not so prescriptive gives us that agility and just say, look, this might be subject to change, and I think that's really important. That's something that really should be communicated almost every time we share the roadmap. Sometimes put it in text underneath, this is subject to change, but it's the best view of what we know right now.
Yeah, I mean, heck, I remember having so-called safe harbour statements. It was an entire page saying subject to change, don't make any purchasing decisions based on it at the front of the whole deck with them. You try getting customers to accept that. That was the challenge I always found. Absolutely. Yeah, an interesting one. So you've probably already hinted at some of them, but when it comes to biggest mistakes you see on roadmaps that people make, any thoughts?
Yeah, I think sometimes putting too much information on them is a classic, so you're actually giving yourself more rope to hang yourself with sometimes when you're putting those things down or more information than that particular stakeholder needs to see. I think the classic sharing out a delivery plan full of features, it's not a roadmap, but it's something that I see classic, especially teams that are just focused on building and building and building rather than the real strategic vision. I think some of the other bits that I see are just not circulating it enough. Again, it's done as a tick in the box exercise and then it's not shared and it's put on a shelf. It's like, yep, we met that strategy planning session and not revisiting it. And also sometimes I don't necessarily like to put executional progress on my roadmaps as well, so I might put a time of where we are right now, but showing progress of some of these initiatives I feel is better done elsewhere. Again, it's how much are information trying to load up on this roadmap?
Yeah, I guess there's a compromise there that if you are showing some level progress, one of the things I've used is if you use themes of the problems you're solving, it's like, well, the solution is in beta test or it's in early user testing or it's in, we're just doing early user design work, then that gives people a confidence factor without saying exactly what it is. So that can help in that communication.
Absolutely. Again, enough that they get the information they need. Is it this week or is it next year? But it's not a specific date.
Yeah, I guess somehow what related, but antipas things that people think are great but actually cause more problems or a bad practise as opposed to mistakes. Any thoughts there?
I think it picks up on a lot of things I mentioned before, so just sharing delivery plans and saying this is the roadmap is the common go-to we need to encourage people to think more about outcomes rather than output, and that's really what that roadmap should be doing. But I think it's also the one that's very easy to achieve, especially from the agile world. It's very easy to show what we've been working on, but not necessarily why. Interestingly in Agile I talk about backlog many, many times over in the documentation, but roadmap is not mentioned once and so Agile is great for helping a team to execute and yes, we can build some strategy in there, but it's not necessarily for showing exactly where we're going. So again, it's very easy to say, Hey, we delivered so much work in this sprint, and you go, okay, but what was the outcome you achieved? And it's very difficult because that sprint might have delivered small incremental benefits to three different initiatives that you are working on upstream, but if you haven't created that attribution, if you haven't clicked created that these features are going towards this bigger body of work, this MVP or this initiative, then all it looks like is we're building, building, building, building and we dunno why
We're a feature factory. We're a
Feature factory. Exactly.
Yeah. It's interesting because essentially that roadmap is sometimes confused with a release plan I often find, and that's kind of what you're hinting at there, the Gantt chart with the dates with this feature comes out, which gives that absolute certainty and it does go back to the road or the waterfall style of thinking, right? It's like we're going to hit this date with this scope and that's the plan and that's what we're executing again with basically no change, whereas a much more agile mindset as is coming through many times is many times actually subjects change. We're going to learn as we move and we might end up doing something a little bit differently.
Yeah, that's right. And that's why I think communicating often is important because it almost reinforces the fact that you are being agile. If you communicate it once, people think it's just you're going to stick to that throughout the year. If you show them that actually that information is contemporary and up to date and it's changing, then I think you also get people more involved with it because it becomes more living and they're more invested in following what's going on.
Sure. And so if you had to distil down anything, there's one thing that you really hate to see in a roadmap, your pet hit your worst practise thing, what is it?
I think it has to come down to timelines and features, and I know that's two, but I really think that we should be thinking about timeframes and outcomes. We should be bringing those roadmaps and bringing them far higher than where they typically are and thinking about why we are doing it for our customers, not what we're building for the team or the organisation.
So it's shifting from you'll get X on this date to we're going to solve this problem in this timeframe?
Yeah, I think so from being time bound and specific to more outcome focused and timeframes because we know we don't know what we don't know.
Cool. So when you are wanting to learn about roadmaps and the roadmapping space, is there anyone in particular you listen to you, anyone's advice that you take as most interesting?
Yeah, I think there's a couple of places really, and I think I've picked up a lot over the years. We see a lot of roadmaps and we take the bits that we like about 'em being more in the product or roadmapping space. We've again sort of finessed that over time. So I think a lot of my product leaders have shaped the way I think about things. Obviously some of the big people in the industry, Marty Kagan, the product roadmaps, relaunched if you're on the road mapping space is a classic one. Todd Lombardo, Bruce McCarthy, I think there's a few other co-authors in that book. There's also some of the product organisations that go on the seminars and things. Mine, the product is a classic one as well. Looking at the speakers on there, some of the TED talks, and I think maybe the last one, and I think we touched on this actually, Phil was the different road mapping tools themselves. Often when you use a mapping tool, what you are doing is you are going through some of the steps that the founders had gone through, which is what inspired them to create the tools in the first place. And so you can find yourself influenced there because ultimately it'd be great to say that there's a tool that wraps completely around our business process, but ultimately what happens is that you find that some of your business processes wrap around the tool and so there's an influence in there as well.
Yeah, great. And so I guess you've kind of already gone there, but resources, any kind go-to resources either from those places or different people or different websites, blogs, that sort of thing?
I think a couple of the ones I'll often look at search for road mapping in Google actually, because there's a lot of new tools that are coming up where you can actually find new tools springing up with their philosophies that either reinforce or contradict there. I used to go to roadmap.com, which was an aha led community of four product managers, but unfortunately that's been shut now. So I don't think there's really a centralised road mapping area where people can join and I think that's an opportunity, Phil, where we can maybe help our former colleagues and people to unite around mapping. But typically a good Google search will get me there or some of my favourite books as well. But I'm not sure that completely answered your question.
Well, I mean you've kind of already started, I think you mentioned the roadmaps relaunch, but for example, personally I love that as a resource. I think it was just epiphany aha moment, not to be true. Aha moments of right, yeah, that's the mistakes I've been making, this is what I should be doing and I was trying to make those changes in my last role. So definitely get that one.
I think what's been important is maybe showing what good looks like and also what bad looks like. So often it's difficult to see examples of roadmaps because sometimes they can be quite sensitive. There's some companies that are producing external roadmaps and I applaud that because it shows again, strategic direction that could be a problem sometimes in terms of competition picking up on what they're doing. But if you keep it high level enough, you keep people engaged and excited about the direction without alluding to what features you're going to deliver. But I think it's something difficult because roadmaps can often they would need to be redacted in order to be shared. And so it's this difficult thing if we can provide more examples of what good roadmaps look like or bad roadmaps look like, even if we redact some information, I think that could be helpful and probably could be a future segment on rate my roadmap.
Love it. Yeah, I mean it's an interesting one. Philosophically I got to the point where it's like if I'm prepared to share it with my internal colleagues and my customer to show them it, even if it's in a meeting, I assume it's out there in the world and I'm ready to then show it. There's a quote, I forget who it's from now, but we're all in perfect copies. So even if I show the direction I'm going my competition, I've got to fume that I can out execute them or I've got a better insight. And if I'm just showing the problems I'm solving, I'm not doing that detailed this feature on this date, then I'm probably actually, well, I can hopefully rely on that sort of mindset. But yeah, it's an interesting challenge
A hundred percent.
So I'm going to come back to that earlier comment about agility and road mapping and just any final thoughts around that dimension that you don't think you've covered there?
Just I think again, how can we communicate to the business that here's what we're working on now, here's some stuff that's aspirational and almost instead of breaking up by timeframes. And that's why I like the now next later approach because it even frees us up from timeframes there, let alone timelines, but almost it's like showing a backlog of initiatives sometimes. How can we show that? So it's actually instead of being the third column that is q3, that third column is actually here's a backlog of initiatives and we're going to execute these based on how everything else goes before that. So I haven't found a roadmap that quite does that well yet. People might take the ordering of those initiatives as being the top ones the most important. How again do we get out of that and say it's not, this is just a bucket of stuff that we might look at, whereas as it comes closer, we organise that a little bit tighter and prioritise it. And sometimes some of that is just providing that narrative to people, helping them to interpret the roadmap and say this thing that's far right doesn't mean it's definitely happening at that point in time. It's just what I'm considering.
I mean one of the interesting things when you think about the three horizons H three as you mentioned earlier, is sometimes just because it's in the third horizon, it's in that future. It doesn't mean you're not working on it now, actually you've got to start working on it for and figuring things out for it to pay off in that longer time horizons. It's not necessarily even the order of work I find
Totally
Is the payoff order.
Yeah, absolutely. And that might actually come into where value drops are better on these roadmaps in terms of here's where we are going to drop value and that's probably where OKRs fit in a little bit more because that's a milestone in time where we're going to achieve a certain thing, but it doesn't allude to all of the work that's gone above. That's why I don't think OKRs are the be all and end all. I think they're great holding teams accountable and showing a cascade of responsibilities, but like you said, we should be doing some of this work way ahead of time and that's not often captured in OKRs. Cool. So maybe on roadmaps we should actually have some things like we're going to do some discovery around this before we actually do the execution. And again, it leans nicely into Agile, but bringing it into a roadmap perspective shows that actually we are doing some work upfront and there is some resource and investment happening there.
Well, yeah, I mean you could be showing that in that later future column and actually showing the status because that high level of discovery activities as opposed to in final design or in final testing, we're working on it to understand it and that will then ultimately come forward and we'll figure out the best way or if it's even worth doing.
That's right. We want to give a notion of workflow, not trying to be precise in terms of where it exactly is in development or something like this. We want to just soften those names a little bit so that people, those statuses so that people get an understanding of where it is without absolutely finished development. So they suddenly think, well, it's going to be delivered now.
And we all know that the from finish of Dev to actually be customer ready is often not that shortage in
Yes, exactly. Exactly. Especially not outside the world of continuous integration, continuous deployment and for large things, we were talking earlier about cars and things like that, you can't deliver those in an agile manner. It has to be delivered as a whole.
Yeah, I mean that gets onto one of my areas of view. You've got that interesting challenge, the hardware, the physical thing, what works really well, but then you've got so much software, there's more software in a car than took us to the moon. Totally. And actually agile in that space makes sense. And bringing the two worlds together and finding that happy medium, that's always been an interesting challenge.
Yeah, I think so. I saw this in the world of amplifiers for instance, ridiculously, but my home entertainment amps got more from being analogue electronics to actually being computers. And so we need to make sure that actually there tends to be a tendency to let's just sell it now and make it better over time. And that can impact the customer experience in terms of sometimes when stuff hasn't been tested as thoroughly, then that actually then means that there's an impact. I think there's a fine line there. I definitely think it's more attractive to these manufacturers because they can go more iterative and can deploy features over time, but ultimately if that means that it hasn't been tested and works as a complete end piece, then actually there can be challenges to that. So I think again, there's just a balance there and
I think we're seeing that journey and that learning, that iteration happening at Tesla, that's the live test case for the post child because getting more and more capabilities on those cars with no physical changes, but it is the software defined car. It's a very different approach from the traditional vehicle manufacturers.
It is. And we can see then also how you don't necessarily buy your functionality anymore because that functionality can be taken away.
Yeah, I've heard a rumour that on the Model S, the batteries on them are all identical, but you can buy different capacity versions and it's literally a software switch because the cost of manufacturing them all the same was lower than actual benefit
Of hundred percent. And sometimes that's really unsatisfying for the end user. I used to work right at the beginning of my career for a very high tech video and audio and picture production company and they used to create their own storage. And again, the storage capacity was dictated by a software key because all of the devices had the same hard drives in there. So you could look at that and it would have three different types of storage capacity that was you pay tens of thousands of dollars for and you get a key to unlock it, even though the hardware storage was there over time. Similar with engines these days, a lot of engines
That just cries out for being hacked.
I know. Exactly. Or engines, three different power outputs from three different maps of the same hardware.
Yeah. Cool. So I guess it's probably about time for us to wrap up. So I like to leave you with one final question. If you had to distil your philosophy on roadmapping down to one or two sentences based on all that discussion, any thoughts?
That's probably the most difficult question actually, Phil one's at the end. It's a good one to end on. I think it's to understand where the roadmap fits in terms of the deliverables and things that we're working on. And it's to understand who the roadmap is really for. That's the most important thing. If you create it for yourself and what you want to deliver over time, then you'll end up giving yourself enough rope that it does hang you. So I think it's understand where the roadmap fits, understand that it's there to be able to communicate and align teams get investment. And I think that's probably the worst answer I've given, but actually that's the way I feel it is, is to think about what a roadmap is and also know what a roadmap is.
So really understand your context, put yourself in your context and say there is no one size fits all roadmap. It's figuring out how it works for you, using it as a communication tool for your audience. And I'm kind of paraphrasing what you said throughout bringing it all together hopefully, and keeping that. I think one of the things you picked up a few times as well was one version, one source of truth with many views for those different audiences, actually different people consuming it.
Totally. Yep. Absolutely. Phil, I've thoroughly enjoyed my time with you. Thank you so much.
Absolute pleasure Justin. And yeah, looking forward to getting this out to our world, to our audience and figuring out what they think about. Yeah,
Exactly. It's a good start. Alright.
