What should the time-horizon be for your roadmap? | Ant Murphy

In episode 67 of Talking Roadmaps, Justin Woods interviews Ant Murphy about crafting effective product roadmaps. They discuss the nuances of using time horizons versus timelines, the roadmap’s role as a strategic communication tool, and how to align roadmaps with vision and strategy. Ant emphasizes flexibility, audience-specific views, and the importance of context in roadmapping. Drawing on examples like Tesla's masterplan, they highlight how to balance uncertainty with long-term goals. A must-watch for anyone refining their roadmapping approach.

With over a decade working in product, Ant has worked across small startups to large enterprises and firmly believes the secret to great products is building great product teams! Today, Ant is a Product Coach and Founder of Product Pathways and has a client list that spans from FinTech to AI. He has coached Founders, Product Managers and Leaders across the globe, from companies such as Miro, Tripadvisor and Stack Overflow. Ant is a regular keynote speaker and hosts a Youtube channel as well as a bi-weekly newsletter read by thousands.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

What should the time-horizon be for your roadmap? | Ant Murphy

Justin Woods and Ant Murphy

In the next episode we are talking to Ron Lichty, Consultant, Advisor, and Author @ Ron Lichty Consulting. So watch out for Season 1 - Episode 68!

• Transcript

  - You need to represent time somehow on a roadmap, that is actually important. But there's a difference between this will be done on June 16th, 2024 versus we're working on this stuff now, and by the way, this stuff next. That shows Time Horizons, that shows sequencing, that shows an element of prioritisation without going down to the finite details.

  - Welcome everyone to the "Talking Roadmaps" channel. My name is Justin Woods and today, I'm joined by Ant Murphy. Ant is the Founder of Product Pathways in the PBL newsletter. And he's also one of my favourite coaches to learn from. So I'm thrilled to have him on the channel. Ant, welcome to the channel, please introduce yourself.

  - Introducing myself. Yeah, I guess I'm a product coach, I work with companies predominantly 'cause I'm in Sydney, Australia, so a lot of my clients are Australian-based and New Zealand, but I work with companies all around the world as well. We were just saying before we started recording that I got a call with somebody in the UK, so yeah, Europe and the US as well. But my focus is really helping people do product better. A lot of my work is more on the transformational side, so super keen to be reading Mighty's book "Transformed" right now I'm in the middle of it. And then on top of that, I also working on another platform, which is Product Pathways, which is all about trying to help product managers do product better and grow. And at the moment it's all self-paced courses, but I'm gonna grow that out. I've got a grand vision as usual, and we'll see that unfold.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Fantastic. As product managers, you're now in control of your own roadmap and you've got plans for that in future. So, and we're gonna be really excited to see that from you. Before we get into the questions, let me introduce the channel. So welcome if you're listening along at home or even watching on YouTube, "Talking Roadmaps" is a channel where we talk all things roadmap to expert, practitioners, tool vendors and thought leaders as well. The first question would be, what is the purpose of a roadmap?

  - A roadmap is really a communication tool. When you bring it down to like first principles, it is a communication tool. Bruce McCarthy likes to throw the word, who is the writer/author of "Product Roadmap Relaunched" for anybody who is interested. Great guy as well. He puts the word strategic in there, it's a strategic communication tool. I don't necessarily think you need strategic, but just to throw it in there so you can think about where it sits and plays, but it is primarily a communication tool to communicate the future direction of your product. Now strategy gets put in there 'cause I think that's nice 'cause it should be a representation of your strategy, but if you think about it from like roadmap, it's directional. So it's trying to give you a direction, here's the direction that we're heading. Now that's very fundamentally different than other things like plans and especially like Gantt chart type things and people throw out all kinds of things for roadmaps, oh, it's for managing dependencies and prioritisation. It's like no, communication tool and directional.

  - Yeah, absolutely. And it's interesting you talked about the strategic element 'cause I think both you and I can see the points for it and against it as well. I think there is a craving to make it more specific, to elevate it from the typical Gantt charts that people are maybe used to. But I mean, it's a terrible word anyway, I think in many terms. But I love the directionality of it. I also love the fact that you kind of hinted that it's strategic and it's cadence in your strategy, but it shouldn't be your strategy in and of itself. And I think that's a mistake that some people make as well is that they don't have anything higher. And so how do we know the direction of the roadmap in the first place?

  - Yeah, and my thing with it too is like, the big thing that I think strategy brings is context and clarity, right? And hen strategy's done really well, it does those two things really, really well. And this is why when we try to do strategies as use tools like roadmaps as proxies to strategies, it tends to fail just because you've got a bunch of things sequenced and it looks nice and however format you wanna do your roadmap and it shows me direction, it doesn't explain why we doing this before that. Like I'm looking at item number one, I'm looking at item number 10, it doesn't explain to me why are we doing one first and 10 later? And an example that I've used a lot in my trainings and workshops is Tesla and Elon Musk's 3-step master plan, which most people are quite familiar with, so it's a pretty good example to give. He talked about building the Roadster and a very fast expensive car and then to build a more affordable family car and then to build an even more affordable car. Now, the vision of Tesla was to basically to build like, I don't remember it verbatim, but it's basically to build one of the world's biggest car manufacturers and then if you think about like their mission statement has gone even further now, which is like accelerating the world towards a sustainable future. And back then, it was about accelerating transportation to a sustainable future. But if you think about like their goal was always mass market cars and that was the vision. And then you're looking at the roadmap and it says build Roadster and you're like, why are we building a really expensive car first? And then you can see like the Model 3 and stuff further down these affordable cars and you're like, why are we waiting eight years to build that? And strategy answers that question. But you can see how, if you don't have that strategy, you don't have that clarity, that context, it's so easy to look at the roadmap and go, I don't get this, this doesn't make any... And it's easy to also argue, no, we should prioritise it the other way around, right? Like yeah, flip it, flip it, do Model 3 first.

  - Yeah, that's a great point. I'm familiar with that too and in fact, I'd love to speak with you later around whether text can even be a roadmap. So that might be an interesting one for us to talk about. But that's a valid point, right? When you look at it, provides the context. You look at it and go, yep, I see those steps, but the challenge that it could be the other way around is completely acceptable. Actually build the cheaper car and undercut. And when we get more money that way, we do it the other way. So that's a great way of thinking about, something that I know and love anyway and I use that as an example. You've given me a different angle on it, so thank you. That's brilliant. Okay, so we've got the purpose of a roadmap and I'm really agreeing with what you're saying there. Who's that audience for a roadmap?

  - Yeah, again, lots of workshops. So distinct answers, stakeholders in a nutshell, but I'll expand on that. Primarily, it's stakeholders. So we're communicating to people who are interested in it. But you can segment that down and I like to segment it down because there's different stakeholder segments or groups. I think segments, I mean, I think it's the product manager in me, right? Like I'm thinking about market and user segmentation, but there's different groups that have different needs. So you can create some logical buckets. Here's some logical buckets. Executives and the team are going to have two different needs and views, but they both need to have the future direction of the product communicated to them in some shape or form. Customers is another one. And plenty of people have done public roadmaps. So not saying you have to, but they have seen this need that's like, hey, we need to communicate the future direction of our product to our customers. So they build public roadmaps. And then you also got another logical group, which is usually like your market-facing groups. And then one that also aligns very close to like the team is also other teams that you might be dependent on and that type of stuff. Now these are also powerful logical groupings because sometimes you might want to have a different view of your roadmap. I don't talk about it as a different roadmap, it's the same roadmap, it's just like a different lens on it. Like executives, it might be a little bit 10,000 feet more higher level. For the team and dependent teams, it might be lower level. For customers, we might obviously, take things away that we don't want to put out public in the market or redact it and just say "super secret project." I've seen that a few times in public roadmaps. I like it and so, I think they're having fun with it, right? And I think I like that like super secret project you'll find out in summer next year or whatever. So you can see how you might do different lenses or different views on the one roadmap based on those segments. But that's who it's for.

  - Yeah, we've gotta be careful oversharing on there, but I too love the kind of the bringing some human quality to it, bringing some entertainment to it. We see that in release notes or things like that from Slack and other companies. It's like having some fun because it helps something that can be a bit stale. It just excites it and drives that engagement and that interest. So yeah, totally agree. Love the segmentation side of things, bringing product management thinking to it. But you're quite right, we wanna share different things with different audiences because it has to communicate and align to that segment, so that makes sense. Who owns and maintains a roadmap?

  - Primarily, if it's a product roadmap, it's primarily the product manager or product owner if you've got that instead and it's just titles really, don't need to get into semantics of that. Although some people might argue about it and that's okay, let 'em do it in the comments. It's primarily, it's gonna be that person. But there's also like different levels of it. As a product leader you might create a product roadmap for your product portfolio that might be a view at that more portfolio or group level that is again, generally higher level, but it shows some cohesion between all the individual products in that area and how that, again, you're gonna have a product portfolio strategy and where that's heading. So generally, who's the person, it goes really close with who owns that strategy and vision for that area and then the roadmap is generally again, a representation of that and to show that direction and to communicate it in that directional manner. So it generally is gonna link to that person. But yeah, product manager, product owner, product leader, quite often, unless we get into other types of roadmaps.

  - Yeah, that's a great thought actually. And technically, somebody that's had a level of strategic input or define the strategy for that. I like that. You know, we know Janna Bastow talks about the prototype of your strategy. Saeed Khan who we've had on the channel talks about an output from your strategy, it's an output from that strategic process. So I think that absolutely makes sense that the roadmap is informed from strategy and so a level of the person that created the strategy actually informs the roadmap, that totally makes sense to me. Through the conversation that we've had so far. You've talked about the fact that the roadmap is communicational alignment and it probably sits in a constellation of other things. And we've talked about the roadmap isn't the strategy and so what is the roadmap's link or or context with other more strategic things like vision, strategy, objectives, how do those play together?

  - Yeah, so like good question, and to me, whether you start with vision or not I think there's probably an argument to be had there. And I don't necessarily think there's a right or wrong, but you generally, at the top of the pyramid, if you think of it like a pyramid is vision, right? So ultimately, what's that? What is the future state look like and where are we headed and why do we even care about this? And you know, visions are often aspirational, motivational because generally when we do new ideas and we work on things, we generally just have this belief that like we we're going to get to this weld or like something can be better, or whatever it needs to be and that's generally the thing that grounds us. And strategy then tends to be the next thing on that, which is really getting into the weeds and the details of like how are we gonna realise this vision? And again, it's that context and clarity and making those decisions, like we could start with the Model 3 or we could start with the Roadster. There's pros and cons to both. Let's work that out and let's make a decision. And that is strategy, make a choice, and that is strategy. Whether you want to put like OKRs inside there or not, I think whether you're using OKRs or not, I think outcomes in some type of measurable milestones is really important 'cause otherwise you've got a strategy and no way to actually measure it. And your strategy is filled with hypotheses that you need to measure and test and learn about and adjust your strategy from the back. Your roadmap tends to be like that next output. So you can think of like outcomes and OKRs is also outputs of strategy, if I use Saeed's word in there, I like that by the way. And then your roadmap is another one, but your roadmap is different. So this is the other different thing too. So your outcomes in OKRs are generally very now focused, so this is the measurable milestone that we're trying to make now. What it doesn't show is what's next and after that and after that and after that. Your roadmap tends to answer that which is like, okay, after that, after that and after that. The other thing your roadmap answers is, okay, we've got this outcome, but what are all the opportunities and features and functionalities that is helping us realise that outcome. And then you can map those things out, which is like, oh well, here's the problem spaces that align to the opportunities that we're gonna explore and here's the features that we're shipping and essentially the hypothesis that you're putting forward on your roadmap, and this is why it is a prototype of your strategy 'cause again, it's all hypothesis, is if we build these things, we believe that that's gonna move the dial on this outcome. And if we achieved this outcome, that is the first measurable milestone in our strategy and we believe we're taking an incremental step in our strategy. And then if we start to realise our strategy, we are off to the races to realise our vision, right? And that's how it kind of all fits together. Backlog can sit there as well, which is then like the finite detail of okay, if we're working on this feature, let's break that down into stories and tasks and all the deliverables and everything that we need to do around that. And there's an element of alignment to other roadmaps and other strategies which I can probably throw in there as well that is absolutely important 'cause we don't live in a vacuum.

  - Yeah, interesting. So much value that you've shared there and so well articulated, thank you. It visualised in my mind one of your diagrams which was kind of the pyramid and the strategy at the top, the execution at the bottom and a question mark in the middle. And that's kind of, you've described that kind of narrated that path there. So thank you, that totally makes sense. And yeah, maybe we should go down if you're ready to talk about that next level, why don't we explore that too? Let's talk about what's some of the key elements or content of a roadmap we would expect to see? And we've talked about it's taking your strategy, it's providing directionality, it's cadencing or stepping it out over some logical parts. What do you think are some of the key elements or content that you want to see on the roadmap?

  - It's a great question. The things that, I have a list, I'm gonna try and rattle off the list, I might miss something, we'll see how well I remember it. But the first thing is it needs to represent the direction. So we need to have the work on it. Now, I break work down into different things though. So a common mistake is that a roadmap is just like features all stacked on top of each others for the next like 18, 24 months. And that's not great because when we think about the future and uncertainty, we think about things like hypotheses, there's no flexibility in that. It's like build this thing then build that thing then build that thing. So the work items that it should have on it is of course, it needs to have features and that's typically like more in the near term stuff. But then I already alluded to it, we should be putting opportunities and problem spaces onto it. And if you are doing like continuous discovery and continuous delivery, you can see how that works 'cause then you've got features in the near term and then you've got opportunities next. And as you work your way through those features and you do discovery on those opportunities, you'll ship the features and those opportunities will become solutions to those opportunities which will be features. The other things that I think are totally okay to put on roadmaps and often we should is like those bigger goals. So an example of that would be like, we go back to the Tesla one, right? So another goal inside Tesla might have been always to expand beyond transport and start to do more sustainable things. Now, they might not have all the details around we're gonna do the Tesla power wall and solar panels and you know, even the truck, right? But you could have like a big lofty goal which would be like, and it could even be as high level as this other alternative sustainability things, product offerings, right? Expand product offerings beyond transport. It could even be that, right? Although they were very niched into cars, so it would actually be probably beyond cars which would include the potential of the Tesla truck and that type of stuff. But even that on your roadmap as a really far, 'cause now we're getting really far term, we don't need the details. We'll break it down. We don't even know like when we're gonna get to it. It could be like a 10-year horizon, although it's pretty far, but. Well, I think for Tesla the context, I think there's a lot of context with time horizons 'cause everyone asks time horizons, how long should my roadmap be? It's like, well, depends on the rate of change and how fast you move. I think, if you think about Tesla and how long it takes to build a factory to build, to produce the cars, like a 10-year roadmap does not seem crazy to me. But if you're a software SaaS startup and you did a 10-year roadmap, sounds a little crazy to me. Maybe reign that in a little bit, but yeah, it's okay to have those really big things and I think that's important as well. So that's the work and the work kind of breaks down into different things, from goals and lofty aspirations to opportunities and then into actual features. The next thing we should have is, we should be modelling that strategy. So we should have the OKRs and the outcomes represented on our roadmap somewhere. And ideally, we should be showing that relationship between here's the work items that is attributed towards that OKR, that outcome, whatever format you use so we can show that relationship that's these things are working towards that. I think that's really important. The other important as attributes is a time horizon. And I use those words deliberately because that's different than a timeline. You can represent time horizons and again, it's directional. So you can represent time, you need to represent time somehow on a roadmap that is actually important. But there's a difference between this will be done on June 16th, 2024 versus we're working on this stuff now. And by the way, this stuff next, that shows time horizons that shows sequencing, that shows an element of prioritisation without going down to the finite details. So it needs to have a time horizon on it as well.

  - Yeah, no, I like that, some takeaways there for me as well, which is I think when people create a roadmap, I get the feeling that they feel that it should show the same type of record consistently through the timeline. And so when they create a feature roadmap, let's say, or specifically a feature roadmap, they might put features across the entire set of time horizons. What you're suggesting, and I totally buy into is that, we don't have to do that. What you should do is communicate comfortably what is applicable within that time horizon. How agile or the rhythm of the business we are able to accommodate change should define that timeline horizon. And then we shouldn't feel bad about putting features in the near term, but then bringing in talking about discovery, problems, outcomes in the later term. I think it just doesn't become very human to do that. Though we think that it's a roadmap that shows features and so we continue features along and get ourselves into trouble. And I think, some tools don't help with that. We'll talk about tools in a moment, but when you configure your tool to show a feature roadmap, it happily just puts features all the way through for 10 years if you wanted it to. So there's a danger there and I don't think it's helping people in roadmapping. It's actually when you step away and think about it in the way that you've really elegantly provided that context and that description, it doesn't need to do that and it shouldn't do that either.

  - And I do think making that change is quite important in my experience 'cause a common complaint I hear all the time, I get to spend time with so many product managers and product teams and even just all their stakeholders too and leaders. And a common complaint is roadmaps are a waste of time. We don't do roadmaps 'cause it's a waste of time 'cause by the time you create the roadmap, it's all changed anyways. Now, if you're trying to plot our features for the next, let's be more conservative, the next, even 12 months or two years, let's just say 12 months to 24 months. If you're trying to plot out all these features across those time horizons, then of course, your roadmap's gonna change a lot. Like you've kind of done it to yourself 'cause you're trying to say, we're throwing this in Q4 of the year or if you're not using quarters, which they often are, but like even if you're not, you still put in these features and then suddenly all the features are always shifting because you're learning more. Whereas, if you can take those steps back and say, well, rather than put in the solution down, I'll put the problem down. And then what generally happens is the features do shuffle, but they're all in the near term and that's not too bad. And then the things outside of that don't shuffle as much. 'cause like that's still a big problem space that we need to do and tackle, like that hasn't changed. Maybe the way that we're gonna solve that has changed or the original idea to solve it has changed because we've learned something or things have changed, or AI's be like, it's a great example. GenAI became a thing, right? And it exploded. And now you're thinking, well, maybe we could use GenAI to solve this. Well, if you never wrote down any type of solution to begin with and you just said, how might we solve this problem, then you can get to that problem and say, well, maybe GenAI's good. And I often talk about the cone of uncertainty and how things further in the future gets more uncertain. And that's really what you're just trying to take into account, it's like anything really far out, let's try and take it up a few notches and let's try and get it away from concrete things because we don't know and there's so much uncertainty. And the more I can kind of bring it back, the more flexibility there is. And even that example that I gave before about alternative sustainability products, right? That can be anything. But if you write solar panels, then Tesla power wall, then those things are gonna move, of course, they're gonna move and then you're getting frustrated with your roadmap. So I think that's really important 'cause people get frustrated with the roadmaps. Roadmaps, they feel like they're ineffective and it's not necessarily the roadmaps fault. It's kind of like the format that they've chosen to put it in and we can do a little better.

  - I think we can and we're to help people do that, aren't we? And we are there to help solve that problem. No, that's brilliant. That makes total sense to me. While we're talking about ways to visualise and style the roadmap, and you've painted some of that picture of those key elements. Let's go back to one of the bits that we talked about at the beginning, which is, Elon Musk called it a master plan and I'm good with the word plan there, but some people might not be. But do you think that even text could be a roadmap?

  - This is an interesting one. So Rachel, she's the Chief Product Officer at Culture Amp and last year at leading the product, she mentioned something in a talk and I got the privilege to speak to her afterwards and like the after dinner and stuff. And she talked about how she's much more in a favour of product narratives over product roadmaps. And I love the idea and I understand, I got her points as much as I can remember from the amount of drinks I had. But you know, I think that a narrative, so the reason why I'm telling this story is because when you say that, I think could a narrative, could a product like a narrative replace a roadmap? And I think yes, is my immediate reaction and especially from that conversation and I think having a well-articulated narrative can be really good to explain it and even that 3-step master plan that Elon did is a form of a narrative, right? Like you didn't try and visualise that on some type of now, next, later type thing. So I think you can, I think definitely text could be a version of that. I mean, I bring it back to first principles often. So if you first principle is I'm trying to communicate the future direction of my product. Now if the format that works really well inside my company is a written format that, you know, whether you call it a narrative or not, it probably will take the shape of some type of narrative, which will be a narrative of your strategy 'cause your strategy is probably more detailed and longer. It's probably just this like high-level narrative around the product and where we're heading and what steps we're taken around that. And if that's an effective means to communicate the future direction of your product in your context, then I think that's awesome. Like I just think that works. So if you're bringing down the first principles, it's communicating an alignment and trying to create that alignment through communication and you're communicating what the future direction of the product as it relates to the strategy, then whatever format that takes, I don't think it matters. The primary thing that matters is are you communicating, are you creating alignment and is it effective? So where I think the narratives probably fall down and the written part falls down is a lot of companies aren't used to that. And you know, for us we've seen a lot of companies, we understand this, but for those who haven't seen a lot of different companies, there are a lot of companies out there that they're very ruled by slide decks and visual things. And written is not really a habit inside that company for many reasons. And that's where I think you'll struggle 'cause then what you'll be trying to do is you're trying to take, and this is just classic, this is why I bring it to first principles. You'll be trying to find a tool or a format that maybe you like, but is not fit for purpose for your audience. So again, if you bring it back to first principles, who's your audience? And this is why I talked about those different views of your roadmap. So maybe you'll do a narrative for execs, like just throwing it out there and then you might have a more visual roadmap for everyone else. I don't see a problem with that either. Again, I actually think that's good practise and I think you're trying to be really effective there. You're thinking who's my audience? Who's the consumer of this? How do I do it in the best possible format for them? Maybe execs in my company, they do everything written 'cause maybe they had some consultants in there to tell 'em that that was a good practise or something or whatever. Or maybe they really like it, but we know how things happen. Then you are just trying to put it in that format that's gonna be effective for them. And that's cool. And then you're sitting there looking at someone else, like communicating to the teams that are dependent on you or you're dependent on them and you're thinking, well, actually a different format will make more sense. And I know that's more effort and some people will freak out by this, but I think we talk so much about influence, influence without authority, et cetera, et cetera. This is how you influence. It's not rocket science, it's being able to package things in meaningful ways for the people consuming it and communicating in effective ways that's how you influence and create alignment. So if you don't do that 'cause you're like, oh, it's so much more effort. Well, don't be surprised if people aren't aligned, people are confused and you don't have a huge amount of influence in the organisation.

  - Smashed it and absolutely, you know, two things there. Roadmapping is about storytelling and I think that's important. One of the reasons I'm passionate about roadmapping is it's visual, but it doesn't have to be. But really the key bit that we wanna be underlining here is, roadmapping is not about you or your product, it's about your audience and it's about sharing what you need to share with them to get their buy-in and alignment. If you're not getting that, then you're completely using the wrong tool and you're going about it the wrong way. So the roadmap should be about them and if it's about them, it should be tailored towards them. So that's just sensational insights there, and thank you. And so let's go into tools a little bit and so do you have any tools that you prefer to use for managing and visualising a roadmap?

  - Well, I actually really like Bastow's ProdPad to be honest. I mean, I think she's brilliant. I think the mission that she started that company with trying to build a better roadmap and tool that actually speaks to some of these good practises that we talked about and common practises that isn't something that is gonna try and encourage you to put 24 months worth of features down along a timeline, I think is fantastic. So, as a tool, it tends to encourage a lot of the more common and better practises and try to steer away from some of the other ones. So I do love that. Outside of that, there are other tools that do it pretty well. I've been experimenting a little bit with Jira's new product discovery, which has a roadmap thing in it, that has now next, later, and things like that. Naturally because a lot of my clients use Jira, although I like ProdPad plugs into Jira and everything like that. There's other tools out there like that I don't think are bad either, Productboard is very popular, but like I put Airfocus above that.

  - It does, every day we're adding to the list. I know, I know, I know. But I'm actually quite an agnostic one because a lot of the times it's like, well, what are the clients already using? And here's my other thing too is like first principles is kind of where I bring it back to. Where I steer clear though is when the roadmap tool and always feel bad about wanting to name names but I'll just give some examples here. So like I mentioned Productboard before, Productboard's not that bad 'cause they've got different views, but one of their views is a very timeline Gantt chart view, right? And Jira's got the same, although they don't call it a roadmap anymore, they call it a plan, but they have that as well. There are a lot of people use that tool for a roadmap even though they say like it's not, although it used to be named that. But I think there's some history there. But there are tools like that that are gonna obviously, gonna push you more down those paths. Now the double-edged sword to tools is, if the tool is encouraging you to do that or I always think about it this way, I'm like, are you making the tool work for you or are you changing the way you work for the tool? So that's probably the principle to think about here or the reflection point. So what I'm getting at is, if you're changing the way you work for the tool because the tool's asking you for start and end dates and all that type of stuff, then I think you've picked the wrong tool. And that's why I mentioned ProdPad first is because it's a tool that is going to, it's not a tool that does that. It's a tool that's going to in fact encourage the better behaviours. But I think that's the main reflection point. At the end of the day, you can achieve great roadmaps in almost any tool that's out there, including things like PowerPoint and like a Word doc, although it's probably gonna be more effort in those tools as well as like a Miro board or those types of things. So I don't think there's anything wrong with any of those tools. Obviously, the more manual tools like Miro and, like pros and cons. Miro, PowerPoint, that type of stuff, Confluence page 'cause you can do almost anything on that if you really want to. When I say Confluence page, I'm not talking about using their roadmap thing in the Confluence page. I mean, actually, you know, like a wiki page, like Notion or Coder, or something and then creating your own thing inside of it. There's an endless amount of possibilities which is great 'cause there's a huge amount of flexibility. So you can choose the format, but the double-edged sword to that is it's gonna be way more effort than adopting a tool like ProdPad that already puts you in like a now, next, later and that type of format. Although if you didn't want to have that, like you wanted to do something more written as we were just talking about, or if you wanted to have something that's more visual in the sense of maybe more of a tree diagram type thing and relational, then you're gonna have to lean towards those tools. But you're going to do that at the cost of hey, this is gonna be more effort to update and maintain. But if you think it's gonna be more effective then I'm kind of like all for it.

  - Yeah, I agree. It's almost lazy to say, well, we're capturing dates on Epic so let's create you an Epics Gantt, right? It's unfortunately the tool, and that's another reason I do love ProdPad as well for that is because it's helping to bring in lean product principles within the tool so that there's process supporting the way that the tool works and the outputs that it gives. Whereas another tool that doesn't give that, will just provide very convenient ways to surface the data. But they might not be appropriate for you or your organisation, but you use them 'cause they're there. It's a bit like vanity metrics on, you know, it's great for us to be able to see subscriber accounts on YouTube, but the real meaningfulness is, how many leads am I getting from that? How many people's lives am I changing? That's much more difficult to find and tools don't really support that so easily. So I love the way that you're coming from there.

  - Yeah and I think just on that, you made me think that's again, bring it down the first principles, critically think actually, ask yourself the right question. So even just your subscribe account example or views example, it's more like, well, it's so easy to get the metrics that are sitting there and you're like, yes, look at all the impressions we're getting, these numbers are great. I have this theory that like impressions were created inside, basically, like the ad and marketing industry to basically be able to sell millions of dollars to like execs and people who don't know anything. 'Cause like it's easy, I'll sell you a million impressions, but they'll all be like, you know, children in Cambodia or something, which is totally not your target market, but you're like, look, I got a million impressions and you feel great and they take all your money 'cause they sold you that they'll give you a million impressions. But again, it's like don't take bait I guess is the probably the tip to take away from here and to to sit down and think like what am I trying to achieve? What are the important questions I need to ask myself to and have answers to? And just because there's a date field, we don't necessarily need to fill that date filled out and we don't necessarily, and just because it's there, like the Jira plans thing, just because it's there, doesn't mean we need to use it. Maybe we should look for alternatives. And even if that alternative is oh, we don't have budget for other tools, you're like, well, maybe I'll just use a PowerPoint deck or something. And again, go back to what I was saying about influence. Do you want it to be easy and suck and have no influence or do you want it to be hard and actually have some influence and drive some meaningful outcomes? I mean, it's crappy to think that like you need to make those decisions in your day to day and it would be nice if you had budget and they'll would give you these great tooling and you'll have access to it. And I agree and there are places that are like that, but not everywhere is like that. And sometimes that's the card you've been dealt.

  - Let's do a quick round on the good and the bad of roadmapping. So can you think of a best practise in roadmapping and then maybe a bad practise or a pet hate for roadmapping as well?

  - Yeah, I'm always like very... You might have heard me talk about this before where like I always try and think more about like common practise first or better practises as opposed to best 'cause everything's so contextual. Just like I said, like with the narrative things and Rachel, like the CPO from Culture Amp, like maybe it'll be silly for me to be like, no, don't do that, if it's like really effective for the organisation, so like, yeah. But to just with that caveat, so asterisk on on best and replace to think like better practises or common practises that I see that work effectively. The question was like the better ones first. Obviously, I talked about some of these already, like flexibility and I always think flexibility in your roadmap comes in two forms. The first form is your time horizons. So avoiding dates and trying to lean more towards time horizons and there's also a middle ground that you can give. There's no reason why you can't go from like quarters to then like the rest of the year to then next year and then beyond. Like that's taking a narrow time horizon, which is a quarter, which is not super narrow 'cause you're giving yourself flexibility in the quarter already and then you go into half a year and then to a full year. So you created flexibility. So whether you use now, next, later, or whether you do that, I think it doesn't matter. I think the important part is you're creating flexibility in your time horizons. The second piece of flexibility comes in the work items on your roadmap. So what is actually on your roadmap? So this comes back to what I was talking about before about going from features to more opportunities to maybe really big hairy goals and problem spaces and that creates that flexibility as we discussed before 'cause you're not putting a feature really far on the roadmap which might become obsolete 'cause technology changes by that stage or whatever, like the world changes. Flexibility is one of 'em. I think that's a big one. I think adapting it into your audience as we spoke very heavily about, huge one, if not maybe the most important. Which is also the reason why I always am hesitant to say again, best practises, 'cause maybe your audience actually wants hard dates and I know that's a hard pill to swallow, but like maybe they do. And maybe you trying to fight that fight right now is actually creating more noise and more issues than actually having more granular dates. And then you can always work with them to try and move away from it, but lose the battle to win the war is what I think. But again, if that's what they need and want, and the alternative is worse, a worse date, right? Me just saying now, next, later is a worse date for whatever reason, there's many reasons that that can be true. I would be like, well, maybe let's put dates on it, I'm not adverse to it because again, it comes back to like, you want to work out what the audience is and make sure that you're putting in the best possible format for them. So I think that's probably the other one that really comes to mind.

  - Yeah, makes sense. So let's think about, if you had to distil your philosophy of roadmapping into it, just a couple of sentences and I think you've done this succinctly earlier and it was a couple of words actually. So if you wanna just use a couple of words then do, but if you had to distil your philosophy of roadmapping into one or two sentences, what would it be?

  - I think I'll bring it back down to that first principle again. It's a communication tool and you can ask yourself why do we need to communicate? Well, we need to communicate to create alignment and create clarity in the organisation. And that's how we rally people behind a direction and achieve our vision and our strategy and get stuff done. So if you bring it back down to that, then my philosophy is that, and that means your roadmap needs to take the shape and form that is going to achieve that in the best possible way for the audience. So work out what your audience is, who they are, work out the format that's gonna be the best possible for that. Whether that means you end up with four different views of your roadmap or one view, one with dates, one with no dates, one that's more of a product narrative or not, all that doesn't matter. Go to first principles, answer those questions and then find the format that that works.

  - Yeah, splendid. That's just fantastic advice. And I wish I had spoken with you about eight years ago, nine years ago when I needed that help as a product manager. But the good news is that people that are listening to you now that are earlier on in that journey are gonna get that sage advice. So thank you for sharing that.

  - I was gonna say myself included on that, you know, it's taken me all those years to get to this as well, and make all the mistakes myself. So like myself included and I guess that's why I share a lot of this too, as you know well and some people who know me know that well as well is don't make the same mistakes, take this and I learned this the hard way, yeah.

  - Yeah, exactly. And so that's a nice segue into giving the audience a chance to hear about what it is that you do because part of your role and a big reason why you've kind of changed your entire career to serving other product teams is to help them to learn from these and to coach them along the way. So tell us a little bit about what you do and how people can find you.

  - Yeah, so you can find me on LinkedIn, Ant Murphy. So look for Ant, they'll come up, you can find me on X, Twitter, whatever they call it these days as well. Although, most things get posted on both. I get a YouTube channel as well, which is Product Pathways 'cause Product Pathways is my other company. Really, I help companies through coaching and advising. So what that is, is I come into companies, I help 'em with things like this. I run workshops on product roadmaps as an example. I actually do coaching. So spend time with product teams, product managers, with executives and leaders. And most of my company work falls into two buckets. It's either capability building, so this falls square into that or it's more transformational. So it's like hey, we want to be more product, you know, adopt a product model and we want to try and move away from all these project plans and delivery things that we have and try and have product strategies and roadmaps and what does that look like. So that's from the company lens. On the individual lens, from an individual product manager or even founder, or product curious person, I guess, if you want to throw that out there, and this is what Product Pathways is squarely focused at, is helping you do product better. So at the moment, Product Pathways has some online self-paced courses that I mentioned at the beginning, but it's got a YouTube channel with a huge amount of free content, creating more free content. I run free webinars every month 'cause it's all focused on creating content, everything that is gonna help you be better in your role and be more effective. 'Cause I truly believe great products are built by great product people and the more I can help you be better and more effective in your day, that flows on to everyone else 'cause you'll build better products, be more effective, you'll have a great career. And we all use those products. I've had the privilege of working with clients and product managers that I use their products. I've coached my product manager at Miro and we're talking about Miro before, right? And you know, like all these things. So I get to benefit from it, you get to benefit from it. I think it makes the world a better place. But that's what Product Pathways is focused on.

  - It's amazing, amazing. And well, look, all that leaves me to say is, thank you so much for spending time with me. You're one of my heroes in the product space and so I'm really excited to share you with the audience. And otherwise, and all that leaves me to say is thank you so much for giving time today at the end of your evening over there in Australia. It's been an absolute joy speaking with you.

  - My pleasure. Thanks for having me, it's my honour.