Can a roadmap be self-explanatory? | Michael Morris

In episode 24 of Talking Roadmaps, Justin Woods interviews Michael Morris, an expert in product leadership. They delve into whether a roadmap can be self-explanatory, discussing practical insights and strategies for creating clear and effective product roadmaps. Michael shares his extensive experience in data, analytics, and open banking, providing actionable advice for product managers.

Michael is an experienced product leader, predominantly in B2B, with over 20 years of experience in the field of data, analytics, and open banking. Michael is currently working at TrueLayer where he is responsible for driving the strategy, development and success of their Value Added Services offerings. Prior to that,

Michael worked at Experian, where he led the product organisation and played a key role in the company's Data Management platform growth. Michael is well-equipped and has a passion for leading cross-functional teams to drive the development of innovative and impactful products.

“If we expect a roadmap to be self-explanatory we are probably kidding ourselves”

— Michael Morris

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

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).

Next up we have Saeed Khan, Product Management Expert at Transformation Labs. So watch out for Episode 25!

• Transcript

  - Hello and welcome. My name's Justin Woods and I'm one of the co-hosts from the Talking Roadmaps channel, the YouTube channel and podcast where we talk about everything roadmaps, from the good, the bad and the ugly. We have expert practitioners, like Michael, who I'm gonna introduce shortly, we have special guests. We also talk about tools and top tips as well. So, without further ado, I'd love to introduce Michael Morris onto the channel. Michael, welcome.

  - Thanks, Justin. It's great to be here.

  - It's great for you to be here as well, because of course, we've got a bit of history. We've worked together in the past through roadmapping. And actually, Michael, you've had a really rich experience of product management throughout your career, and different bits around software development as well, I was wondering if you could just share with us some of your history and your experience.

  - I've been in product probably for the last 15 years, either as a practitioner or leading product teams. Prior to that, you know, probably the standard, almost the Silicon Valley classic, you know, software engineering background, but never destined to be a developer, really, with a computer science degree. But, spent early part of my career in consulting and implementation, professional services, always in the sort of B2B software space, and was probably fascinated quite early, I guess, with the intersection of, you know, business and technology, and that sort of led me almost accidentally into product. But, yeah, I spent a lot of time between, you know, Australia and now the UK with global businesses, doing B2B software product work, and it's been great.

  - Superb. Yeah, I wonder if that's one of the reasons why I just managed to gel with you quite a lot early on. You know, my former background at IBM and as a software developer and a background in computer engineering as well. You said it quite right, there's that intersection between technology and the business that I think is a big attraction for people getting into product management. That's the place that we meet.

  - I knew enough on the technology side to, you know, communicate with the engineers, but, you know, picked up enough from the sort of consulting angle and professional services angle to talk to customers and to, you know, think through the business model and all that sort of stuff, and so being able to play both sides of that coin, I guess, is valuable.

  - It is, yeah, absolutely. And, of course, you've held some senior roles in product at Experian, and now head of product at TrueLayer for the last seven months, so congratulations with that.

  - Yeah, thanks. It's been great. Yeah, I spent a lot of time with Experian, which is a great company, you know, really formative part of my career and had some really great opportunities for which I'll ever be thankful. But, yeah, about six, seven months ago, moved to FinTech in London, who sort of have a pretty good presence across Europe as well, called TrueLayer. So, maybe I'll talk a bit more about that later on.

  - Yeah, fantastic. Yeah, absolutely, we can switch up or talk back around any of these questions as we go. In fact, sometimes we come full circle. As always with the YouTube channel, please do like and subscribe if you find value in this. It helps us, for other people to find us on the channel. And, by all means, share us out as well. If Michael or I mention something that's interesting to you, share it out to someone that you think would find value. Also, if you'd like to get in touch and sit where Michael is today, then feel free just to reach out, get in contact with our email address or comment down below, and we'd love to have you on the channel. Cool, so maybe I'll kick things off with kind of a really direct question here, which is, in terms of a roadmap, what in your experience has been the purpose of a roadmap?

  - The purpose is ultimately to communicate, right? And, I think for me it's to communicate the product plan as currently constituted. And, I use the term product plan fairly deliberately. You know, we talk about the plan, and plans can change, right? We talk about our intention, and even if the roadmap is the artefact by which we use to communicate, you know, really try and frame the roadmap as the product plan or, you know, here's the sequence of items that solve certain problems to work towards our sort of broader vision, you know, here's the steps we're gonna take along that journey, and I think that's what a roadmap should be.

  - Actually, I really like that definition of it. It's a sequence of problems. In fact, I've hashed it up already, but it was a sequence that you mentioned of outcomes or problems that are gonna get us to where we need to be, and I think sometimes people go far too deep into a delivery plan and what they think that needs to look like, but actually that's really elegant. It's just, here is a sequence of things that we're considering that are gonna help us to achieve that. That's a great way of putting it.

  - If we go theoretical and think about, you know, what a roadmap is, right? I wanna get from point A to point B and I'm gonna look at, you know, maybe the various stops I'm gonna take along the way or the route I'm gonna take to get there, and so, you know, a product roadmap is the articulation of that from a product plan perspective, which is why I think that that product plan element is really important.

  - Love that definition of kinda the purpose of a roadmap. From your experience, who has been the audience of a roadmap?

  - I mean, does everyone class as a category? I think, I mean, there's certainly more than one audience. That's for sure, and different groups need different things. And, you know, some of those groups, particularly when we think about internal, right? And, I think we can maybe say, "Hey, there's internal and external audiences." I think many of the internal audiences to our organisations, they actually want to use the roadmap and convey different things to their own audiences, right? And, if you think about it from a sales perspective and a go-to-market perspective, yeah, it's like, what can I sell now and what can I sell later? But, actually, they wanna be able to share that information with clients to get them excited and to galvanise opportunities they're already working on. They always, you know, are interested in, like, of course, what's changing, because that impacts things like sales cycle. You've got other product teams, right? It's a really important audience. So, you know, when we think about some of the work we did previously together, the initial audience for that was an internal product and engineering audience, right? It's like, how do we map this stuff out to identify what dependencies might exist much more clearly? And then, that forces a conversation or it forces a set of actions. And, by extension, I think that forcing the conversation is true of all internal departments, right? It could be implementation and professional services and others. I think what's general across those internal groups is they want some view of what's coming from a product perspective, why it's coming, like, why those decisions are being made. Ideally, when they're coming, right? Which is sort of maybe the big sticking point always with roadmaps, and that might trigger a whole bunch of, you know, actions or other conversations, depending on the department. If we think about the external audiences, customers, investors, and actually each of those, particularly I think when you transition from internal to external, the nature of the content, you know, and the messages being conveyed as part of that communication, you know, I think changes fairly dramatically.

  - That's really true, it actually is. Two bits you mentioned there that I thought were really valuable and possibly hadn't brought out on previous episodes, which is the point that sometimes the product roadmap that you create can be for other product teams. You know, that's really important. It's not just one product team. It's, here are the cross dependencies that we're working on, here are the timelines. So, actually, sometimes they're going to need visibility of your roadmap and your overall trajectory, with which they may align to, but they're also going to need visibility of the delivery plan, so that they can align their delivery and coordinate with that. And, the second piece that you picked up was around the investors, and I think that's a really important thing that we may not have touched on before as well, which is that the investors are potentially going to want to see a roadmap, not in terms of a delivery plan, but what's the overall strategic direction of the company, because they want to know what direction you're going in.

  - The lens varies, right? I think it's, you know, if we're talking about other delivery teams or other product teams, you know, we are getting more to that project type perspective on things. You know, we're trying to use that as a, do we have all the i's dotted and the t's crossed between these two teams? Because, dependencies just always exist. At the investing level, you have the customer level. We're just coming up, you know, that sort of 30,000 foot level, right? And, we're just providing a different lens, different level of detail, I think.

  - You mentioned at the beginning that the roadmap is a communication tool. It needs to communicate to that target audience. So, yeah, that makes sense. What about ownership of the roadmap? Who do you think owns a roadmap within an organisation?

  - I think, I mean, for me, it sort of depends on what we mean when we say own, right? What is it that's being owned? Like, the product decisions and the rationale that become the inputs into the roadmap content is owned by the product manager, right? And then, the product management team and, you know, that sort of organisation, but, like, the artefact of the roadmap and the process that goes along with the curation of it and keeping it up-to-date and sharing it, communicating it, you know, I think that can vary. And, for me, I think that point's really important. If we expect the roadmap to be just this thing, this, you know, digital or on-paper artefact that is self-explanatory, I think we're probably kidding ourselves. So, like, ownership of the process that surrounds its creation and the cadence of its communication, I truly believe that if we're gonna create a roadmap, particularly for an internal audience or set of audiences, it needs to be presented on a regular basis. And so, if we think about that process, you know, who owns that can vary, right? It can be product management. I've had really good success in the past with that being owned by product marketing. Maybe it's product operations, if that's a thing in your organisation. But, having clarity on ownership is critical, but really thinking about it as an entire process as opposed to just, like, the artefact, for me, is really important.

  - That's a great answer, actually, and so vital. You know, it's not a single page in a PowerPoint or whatever tool you're using, it is a process. And, you know, there needs to be ownership of the inputs, but I like your differentiation of that as well, that's great. And, maybe that bleeds into the question around who maintains a roadmap then, because I think we've already, you know, summarised part of that, that could be a product operations or a product marketing team that is going to own the overall maintenance of the roadmap, but the inputs could come from somewhere else.

  - Yeah, and I think, come back to those inputs are essentially the product decisions, right? It's a representation of the product plan as we've currently defined it, and so, like, those decisions are being made by product management, and how those decisions are made, you know, is maybe a topic for a different discussion, but we just say the product manager is the person who's making that decision that that item is gonna be on the roadmap. But, more broadly, I guess, you know, I think that question of maintenance is tricky. And, I think the question actually at the heart of maintenance is, what happens when things change, right? What happens if something on the roadmap isn't the same as it was when you presented it to me a month ago or two months ago or three months ago? And so, if we assume that we have a nice quarterly rhythm, the artefact is produced through whatever process owned by whichever department, and it gets presented on a regular basis, okay, that's really great. In that same cadence, you know, when we present the roadmap, I think it's certainly the right thing to do to share, you know, when things are moved and when things have changed. However, each product or initiative will have different key stakeholders, and if the first time those stakeholders are hearing about the change of something on the roadmap, then, you know, something's probably gone wrong there. And, let's be clear, when things change, they usually shift, you know, to the right, rather than things happening earlier. So, I think that is a tricky one. I would say that when things change, it's certainly the responsibility of the product manager to make sure that key people are informed, you know, as soon as possible, you know, with the right information. As a catch-all, right? If we have a good cadence of updating the artefact and presenting it, we can bring the sort of general population or those other audiences up to speed as part of that process, and I think that's probably okay.

  - That's the difference, I think, between the roadmap being a communication tool and the roadmap being an alignment tool. Because, what I think we're saying there is sometimes someone will spot some things changed on the roadmap, and it's through the viewing of that roadmap that they see the change, whereas actually what you're sharing here, I think, is that as part of a process, they should've been informed already, and then therefore the delivery or view of that roadmap is actually the alignment or acknowledgement of that change. Sometimes a change in the roadmap, it's not just a visual that tells them the change, it's clarification of what was already discussed. And, I think there's a level of etiquette in there, isn't there?

  - It's sort of the no-surprises thing, right? Like, particularly depending if there's an executive sponsor on a given product or initiative, you know, when something doesn't work as a partner, you know, dependency that doesn't quite happen the month you want it to happen and it's delayed by a month, like, you know, that executive sponsor needs to know at the time that thing is happening and, you know, what mitigation we have in place or what the potential flow and impact is or, you know, those things can't wait for, you know, your next quarterly update.

  - Totally agree, and potentially a bit more down at the project or delivery plan level, which we kind of wanna keep separate from the main sort of strategic roadmap.

  - Definitely. I think you see those items shift, you know. I mean, if there's a big enough material movement in an item that you said, "Hey, it's gonna be done at the end of Q2," and now it's the end of Q3, like, that's a visible shift and should be called out, right? But, yeah, I think there's a difference, like you said, between the project delivery view of the world and "Hey, here was our intention "and, you know, our product plan."

  - Yeah, absolutely. You mentioned some other things around, you know, we've talked about delivery plan and project plans, thinking more upstream of the roadmap, potentially, the vision, the strategy and the objectives, what do you see as the relationship between a roadmap and kind of those higher level, North Star type documents?

  - The product roadmap is at the bottom of that stack. You know, those things you mentioned, you know, if we think about vision or strategy or goals or strategic priorities or, you know, pick your vernacular, they provide the direction of travel, they provide the guardrails, if you like, for the roadmap, they provide the, maybe even in some cases, key points upon which product decisions ultimately get made, right? But, those things act as the filter, if you like, for what ends up on the roadmap, so the roadmap represents the more discreet set of product decisions of what problems to tackle and possibly how we tackle them and the order in which we'll sequence those to make progress toward that vision. But, if you don't have the vision or you don't have the strategic priorities or some of those guardrails, then, you know, the roadmap can have anything on it, can't it? I mean, and it's okay. You know, it's the output, right? It's the output of those higher order, you know, artefacts or sets of processes.

  - Yeah, agreed. And, I've seen situations where, you know, companies have a roadmap, but they don't have clarity in those strategic vision, objectives, et cetera, and so the roadmap is, you know, where we are now to the trajectory we're going, but where are we going? You know, the whole point of the strategy, the vision, the objectives, the North Star, is it sets a North Star to where we're going, and so a roadmap is gonna show direction. Sorry, a roadmap is gonna show velocity, but not necessarily any form of direction, and I think, you know, that's a really dangerous position to be in.

  - One of the things that, for me, is really important, and it's why I say, when I think, you know, if you take an internal audience and we say, "Hey, we have a roadmap," I believe it should be presented, because I think what's really critical there is context, right? The context for the roadmap, the context for the plan is not inherently on a single slide that's got, you know, a bunch of text on it, type scenario, right? So, understanding those, the context through strategy, through vision, et cetera, I think, is the path to a successful product roadmap artefact.

  - I love that wording there, it's the context. That's so important, you know, anything without context is, you know, we should question that, whereas that sets all of the framing that we need. That's a great answer, thank you for that. I wonder if we go into kind of the design then. So, we've talked about kind of the core of a roadmap and what purpose it serves. From your experience, what do you believe are some of the key elements or the content of a roadmap? What do you like to see on that roadmap?

  - Maybe I'll start with what I don't like to see. Maybe it's a reaction or it's a just this sort of innate desire to show people all the stuff we're working on. Here's all the good stuff, here's, you know, a product manager wants to demonstrate that their product team, the engineering team is really busy doing stuff, and so, you know, you end up with a roadmap that's got loads and loads of stuff on it, right? If we talk about roadmap as, like, being some visual representation, which I think we'll talk about. But, so, you know, firstly, I don't think it has everything on it, right? I think a good roadmap doesn't have everything on it. It has the most important things. And, one of the things that I've found useful is, again, coming back to maybe the idea of context, is, okay, you got the roadmap, which, you know, people probably have some sort of visual representation in their head, it's got some timeframes on it, it's got some boxes on a screen with items, and I think, and yeah, that's fine. But, actually, to say to an internal audience, okay, here's this view and here's, like, the most important things, but actually, of the most important things, there's actually something that's even more important, right? And so, pulling the key headlines of that out into things that we've called in the past, maybe like a spotlight, right? So, I've got, hey, there's five items across this roadmap in this particular work stream, but in the next quarter or two, like, here's the spotlight. You know, if you're gonna take away something, Mr. Salesperson, like, here's the thing you should take away, and so separating those key headline items from, you know, the roadmap sort of gamp view of the world, if you like, and saying, you know, here's a key highlight, here's what you should really pay attention to, here's the customer need, here's the elevator pitch that you can see, you know, here's the key benefits, here are some of the key features beyond just looking at that sequential view, I think, it's also something that goes into a good roadmap. So, you know, I don't think about a roadmap being just that sequential view. I think you can enrich that roadmap by saying, "Okay, now we're gonna do a spotlight "on these one or two sort of headline items", which I've found to be really useful, and again, in communicating to the audience what it is you're trying to accomplish.

  - Right, and that completely really well feeds in to what you were talking about was the lens, which is thinking about your target audience. What do they want to know? And, spotlighting that for them. That really resonates with me. What about some of the anti-patterns or bad practises you may regularly encounter? I think we joked at one earlier on, which was kind of things always sliding to the right as a typical anti-pattern for things, but are there any others that come to mind, some kind of anti-patterns or bad practises that you've seen in roadmapping?

  - Treating it like more of a project plan, where, you know, if you think about, you've got these quarterly horizons and, you know, maybe we could talk about what I think about that, but, like, you've got these quarterly horizons and you've got a bar that says, you know, "Gonna deliver this widget." Trying to make that look like the length of time that it's taking to do the work, right? Or, linking dependencies between that item on the roadmap and another item, I mean, like, I think that's an anti-pattern, right? I think you're in the world of project management and dependency mapping and a whole bunch of other stuff and you're asking the roadmap to do too much.

  - I read somewhere the other day, someone was saying that they're tired of the sales team getting a ruler out and measuring the length of their boxes, and I just thought it was hilarious. But, you mentioned a couple there in terms of how there are horizons, and I'd love to go into that a little bit more in terms of, do you have a preferred way to visualise and style for a roadmap? It sounds like horizons may be part of that for you.

  - Yeah, I mean maybe that word is too, you know, too fluffy. For me, I think what I've found to work over the years is, your next quarter, right? Really clear next quarter, the quarter after that, and then actually maybe we're looking at half, right? So, and you could even, you know, to think about the visualisation, I've got Q1, I've got Q2, I've got H2, and then maybe I've got, like, a future column, right? This is in discovery or this is stuff that's in the labs or whatever. But, when I say horizon, I just think, you know, one of those key blocks of time, you know, monthly's wrong because, you know, some things work that way, and actually, visually, that becomes really challenging. But, yeah, you know, a quarterly or, you know, with a half here or there, I think is probably the way to think about it. The presentation beyond the timeframe is also really interesting. So, you know, if you're a one-product organisation, like, it's pretty straightforward, right? I can take a one-product view, maybe, you know, if I think I've got some sort of swim lane element to this roadmap, I can think about layers of technology, right? Depending on how you're organised. If you're a multi-product organisation, right? You know, you've exponentially complicated the consumption of that information, right? To the audience. So, you know, picking the way you present the information, be it by, like I said, maybe it's technology layer, maybe it's use case, maybe it's strategic priority, right? I think, again, if you go to context, couching the roadmap in the strategic priorities is a really useful thing to do because that helps you cut through some of the, "Why are we even doing this?" Right? If you couch it up front in those, whatever those key themes are, for me, there's no hard or fast on that. You know, I think you've really gotta look at, again, what your audience is looking to get out of it or what you're looking to get to them. And then, picking a model that works from a thematic perspective. I do think those themes are important, because when you think about elevating through the levels of roadmap, if I wanna come up to, you know, present to my investors, let's say, or my board or my executives, maybe I'm just presenting the themes, right? And, some key initiatives for the theme, right? And, the impact of that. But, you need something. You need some sort of thematic overview as you look to present. The other thing that has been useful over time is to think about tags. And so, by talking about tags, we think about things like, is a given item on that roadmap relevant for just one geography or all geographies? Or, one vertical or all verticals? Or, you know, and the sort of tags can be, you know, infinite, but if you think about visually, you're trying to save space, you know, being able to tag a given item as being more or less relevant to a given area, you know, is also something that I've seen as being quite useful.

  - Yeah, that's really good, actually. And, that's really relevant to slicing and dicing the content of your roadmap. Depending on that target audience, we might find that we've got area managers or domain managers, for example, that are interested in a specific geography and everything that affects that. And so, tagging it for geography makes complete sense for everything else. So, we've not talked about that one, but I really like that, Michael, it's a great way of being able to just consolidate information. Really small, but again, showing it in different ways, different lenses.

  - Well, I mean, if we connect that to, you know, to an experience that I've had, you know, some time ago is our go-to-market organisation was geographically aligned, right? So, like, presenting something to the North American team that's, like, only UK-related, that seems like something you probably don't, you haven't quite got your message to your audience right, so yeah, we would, in maybe a product management tool or whatever the repository is that you're creating the key inputs, you know, you're tagging things as, you know, this is UK or this is North America or this is global, so when you go to extract that information and put it into whatever the artefact is that you're gonna present, you can say, "Yeah, we're just gonna present, "like, the UK version of the information "or the U.S. version of the information "or the Australia version of the information." And so, again, your audiences vary by, you know, as much as the roadmap content does.

  - Yeah, they absolutely do. And, something that you mentioned there, which also feels important is it's very much about reading the organisation and the audience and creating the right roadmap for them. You know, when we were talking about what you like to see on the roadmap in terms of the themes or couching some of those strategic imperatives that we've got, it really depends on what your company wants to see. That's why we don't have a one-roadmap-fits-all for all of these companies, because it really depends on how the company is, the maturity of the company, the maturity of the products, what the stakeholders are used to seeing. I think some experiences have been where we want to introduce a roadmap and it's in such a different way than the organisation thinks that actually the message never lands, because we need to transition them to, you know, understanding that roadmap as well. It's loads of stuff here that I think some things like tagging is going to help us along that journey.

  - Something you said there, I think, is really important and maybe this is a caution, right? Is that, like, the roadmap you have today won't be the roadmap that you're presenting to the organisation in two years or three years' time, right? Because, I think, if you don't have a roadmap today and you start presenting one, like any good product, right? You're gonna get loads and loads of feedback that you're gonna have to filter through and say, "Okay, like, what's valid, "what's not valid, and how do I improve it?" So, I think, think about, you know, the artefact and the process, all that sort of stuff, as a journey in and of itself, and you'll improve and you'll find new ways to do things and your organisation will adopt, you know, some things better than others, and those things will become the sort of cultural norms for the way you do roadmaps at your company. And also, to not be too surprised when any time you choose to change something, right? You're gonna put yourself back into that cycle of people going, "Oh, well, it didn't look "like that last time," or you know, whatever, and so it will be iterative and I think you should expect that sort of change to take place.

  - That's a great point, right? You know, we should be product managing our roadmapping process as well. You know, take that through the points that we would normally go through around experimentation and discovery and getting that feedback, I think that's vital, so I love that point. Maybe we finish up in terms of, do you have a pet hate to see on the roadmap? Something that you're just like, "No, we shouldn't have that on there." Anything that comes to mind?

  - Can I say the fact that roadmaps have become a cultural sort of norm as a pet hate? The fact they exist at all? And, maybe this is the point, right? Is that when the roadmap becomes the single focal point from stakeholder groups from which to engage with product. Like, I think that is a sign that there's a bunch of other stuff that isn't going right in your product org. You know, when you end up having conversations about, "Well how do you prioritise? "How do I get stuff on the roadmap?" You know, how one stakeholder another needs to get, you know, more influence on the roadmap. You know, ultimately, I think when good product planning gets superseded with outsourcing product decisions or the roadmap to the masses, and I think unfortunately in many ways, like, when I say the cultural norm of roadmaps, that's sort of what it's become, right? And so, for product managers, for product leaders, a big part of establishing a roadmap in your organisation is that education process. It is how product decisions are made, you know, without inviting a whole bunch of, you know, sort of unwanted, you know, microanalysis. But, you know, I think, like, that's part of the package. And so, for me, that would probably be the pet hate, is just that the roadmap has just become this thing from which, you know, all product interactions happen. I don't think that's a wise, you know, it leads to incrementalism, it leads to thrashing for teams that disempowers product people. So, yeah, that's probably, the rant, I guess, but maybe you asked for it.

  - No, I totally agree and I think, you know, we're looking for the experiences of real product people, I'm nodding along, you know, it's not the be-all and end-all. I've heard terms like, "Oh, it's not in the roadmap for next year," or it's, you know, "The roadmap's locked," or things like, "The roadmap is this "sacrosanct document that can't be changed," and I think those attitudes need to change. And, whilst we're on a channel called Talking Roadmaps, you know, roadmaps, and we enjoy them, they're not the be-all and end-all, and I think they need to sit alongside such an important plethora of other strategic documents, other downstream documents, and it's just one piece and it's more of a process and a communication tool than what it looks like. You know, if you've got a roadmap on the back of a napkin, that's probably fine too. So, those are the important things here. I guess, in terms of your experience, and I know that we've obviously got a major one, but are there any tools that you prefer to use for managing and visualising roadmap?

  - I would say no preference, but I think I probably have landed on some go-tos, and probably not surprising. I think product management tools can be super helpful. You know, they can help with planning, they can help make, you know, force the collection of key information from product managers. You know, these things that become the inputs, right? To the roadmap. They provide some structure, you can link them to engineering products like GEA or whatever, which is great. But, they're mostly for other product teams, right? They're for product people and engineering people, maybe product marketing, if you've got, you know, product marketers who, you know, are really in the mix with the product team. And, maybe if you're lucky, the more technical teams like professional services, right? But, outside of that, you know, in a previous role, we had a subscription to one of these product management tools and we could see the logins, right? Everyone, like, via Okta or whatever could log in and we could see the usage of non-product people. And so, the traction outside of that was really small, so I think product management tools are useful, they have their place, I think they can help with planning and stuff, but they're not the place for a roadmap that, you know, is then consumed by your internal audiences. Where I've landed is, you know, you probably can't beat a set of PowerPoint slides or Google Slides, you know, that you can turn into a PDF. You know, and when I talk earlier about creating a roadmap for an internal audience and then presenting that roadmap, that's probably where I am, right? I'm thinking that, you know, you've taken this collection of insight either from docs or from a product management tool, you know, I'm working in filtering the most important things with my spotlights and my headlines onto this slide or slides, and then I'm gonna present that. The other thing that I think has become really important, at least, I mean, is it important? I don't know, I think it's become probably a target state for me, I think is, I do see a lot of value in a version of your roadmap that's online, on your website, customer-facing. You know, A, I think it cuts through some of the noise, and I think... There's an overhead in all these audiences we talked about, right? There's an overhead in creating roadmaps for all these different departments. You know, it's probably part of the reason that product operations was born as a concept, but I think your go-to-market roadmap, you know, with your sales team, at least, if you're in B2B software, let's say, and your customers can get pretty close. So, if you can get to a place where online, you know, you've got a version of a roadmap, you know, presented really nicely, very simply, easily consumable, headline items, you can bring your go-to-market team and your customers sort of on the same page, right? And, you can really easily communicate that. I still think you have those other options, right? Your Google slides or whatever, but I think for me that's maybe a bit of a utopia that I do see as being something that you really gained leverage on, I think there's an opportunity there to have good discovery-based product conversations as you think about how you share roadmaps.

  - Yeah, that's a great point. I mean, there's nothing more flexible than PowerPoint or Google Slides or, you know, the Miros and Murals there. You show explicitly what you want to do, or sorry, what you want to show, nothing else, it makes it very easy for you to filter, present it in the corporate way that you need to. I think there can sometimes be challenges trying to manage the roadmap behind that, but as a presentation tool, you know, it gives us the biggest flexibility, so I think that's a great answer. I've got a couple of questions in terms of maybe some of the advice on roadmapping. So, are there anyone's advice out there on roadmapping that you listen to or reference at all?

  - Yeah, probably a couple, I mean, and I know you had Rich Mironov on recently. He's been a go-to for me for a long time, particularly 'cause he's a B2B sort of enterprise software bend to what he's talking about, so I think Rich is great. Yeah, before we started recording, we talked about Marty Cagan. I think he's probably at the top of everyone's reading list. You know, certainly over the years, Intercom as a company have a great blog and podcast, which I've really enjoyed over the years. So, yeah, they're maybe a few places that I go to.

  - Intercom's an interesting one, so that's one that I should check out, and our audience as well, go and have a look at that, because, you know, seeing what other companies or just other product managers are doing, as a guidance, can often be really useful. You know, you just look at it and go, "I like what they're doing," and then we learn from that. You know, sometimes we learn things from all sorts of different places that we capture and take those as our own best practises.

  - For me, the point you've made there is the critical one, right? Which is, you know, if you're gonna pick up Rich's view of the world or Marty's view of the world or the next person's view of the world and, like, just stamp it on your org, like, you know, again, that's probably not gonna work either, but where I've got to over time and I think my advice to others would be, fine, maybe you do do that and that's a starting point, but I would say, do broad reading and broad research and create a solution that works for you and your organisation. You know, so much goes into the melting pot that ends up in a roadmap, right? So, focusing on product planning and getting that right, and then you mentioned this earlier, I think, but I don't think you can go past, you made a comment about product-managing the roadmap, right? Or, like, this artefact, and I think, speaking to your audiences, right? Understanding what it is they think they need. What is it they think they want to see? What experiences they've had at previous organisations that have been good or bad, you know, on a department by department sort of level, is, you know, in this scenario, they're the customers of this particular thing. So, I wouldn't go past, you know, just talking to them and, you know, blending then all of that information into something that works for you and then iterating over time.

  - Such a great point. You know, go and ask your audience what they want and then deliver it to them, and then iterate it from there, right? Don't assume that we just build something and that's all they get. Michael, that's such a good point, I love that. So, as we look to close out today's session, and we've got a few more questions to ask you, so I'm curious, if you were to distil your philosophy in roadmapping into a couple of sentences, how might you describe that? And, that's often the most difficult question we ask.

  - I would say roadmapping is the output and representation of good product planning. It's a communication tool that needs ownership, but it needs context.

  - Yeah, that's great. And, it does capture a lot of the points as well, you know, talking about that context, the communication tool again, so important. It's often, you know, there's things that we need to communicate on there, but really, if those things haven't landed, the roadmap hasn't done its job, so I love that. And, is there anything about roadmapping that I should have asked you that maybe I haven't? So, any questions that I could have asked you, or some points that you'd like to kind of reiterate or make?

  - Maybe, it's not necessarily a question that you didn't ask, I mean, we sort of touched on it briefly when we get into the, okay, product team communicates product roadmap to audience A, let's just call it a sales team. Sales team then want to take that roadmap and communicate it to audience B, right, i.e., the customer. You know, should there be rules around distribution of a roadmap, might be a question that is worth asking. You know, and on that, you know, I guess a few points maybe like, having a disclaimer up the front of either internal or external presentation of a roadmap, i.e., we reserve the right to change our mind, is critical. If a remit does get sent to the customer, I mean, in the past, we've tried to look at rules, and they're not hard and fast, 'cause it's hard to enforce some of these things, but, like, rules that say, you know, if you're gonna send a remit to a customer, ideally a PM or senior PM or senior product person's copied on the email. You know, if it's getting presented, i.e., you're gonna take the roadmap and you're gonna present it to a customer, well, like, maybe a product person should be in the room or even a product person should be actually doing the presentation. And, like I said before, I think in those circumstances, the roadmap can become a point of leveraging, of having a catalyst for good client discovery conversations that aren't just sales conversations, and I think, so yeah, some disclaimers and rules around distribution of roadmap, I would say, is probably a worthwhile thing to think about.

  - Yes, that's a great point and one that I've sort of been reading a bit more about in terms of, you know, the boilerplate of what we put or maybe things like expiry dates on there, just things that set expectations because this can quickly come from an internal confidential document to something that can easily be shared, and if it doesn't go through those right rules, then we can cause more problems than we solve.

  - I made a point before about, you know, an online customer-facing version of the roadmap and I think there's a whole bunch of that sort of stuff to consider in there, right? You need to have those same protections in place, you gotta think about competition as well in that scenario. Like, there's other problems, but I do think, yeah, that your points there are really important.

  - Based on your own points, Michael, but that's such an important thing, you know, not falling into those common anti-patterns or bad practises that many new product managers or people that are creating roadmaps can fall into. That's perfect, so look, I wanted to give you an opportunity just to kind of share with our audience what it is that TrueLayer do. You know, is there anything that you want to tell our audience about TrueLayer?

  - Quick elevator pitch, I suppose it would be remiss not to. So, TrueLayer is an open banking payment platform, leveraging a sort of combination of recent regulation change and new technology that banks have enabled to reimagine the way the world pays, essentially. That includes everything from providing alternative payment methods to your debit card, to, you know, how the money actually settles with merchants, to a range of value-added services to help merchants streamline and improve the payment experience. So, they're all the sort of types of problems and things we're working on at TrueLayer, and open banking certainly is becoming more prevalent as a payment method, particularly across the UK and Europe.

  - Michael, thank you so much for joining us today. It's been great to see you again, 'cause obviously we've spoken in the past. I've really enjoyed what you've had to say. Just to close off then, so for our audience, if you've liked what Michael and I have said, please do give us a like down below or drop a comment if something particularly resonated with you. Please do share this with people if you think something we've talked about would help them or really resonate with them. And, if you'd like to sit where Michael is today and have a conversation with myself or my co-host, Phil Hornby, drop a note down below or get in touch and we'd love to speak with you. Otherwise, Michael Morris, it's been an absolute pleasure speaking with you. Have a great weekend.

  - Great, thanks Justin.