How is designing a roadmap like a championship? | Matt LeMay

In episode 33 of Talking Roadmaps, Justin Woods interviews Matt LeMay, who discusses the multifaceted nature of roadmaps in product management. Matt emphasizes the importance of defining the purpose of a roadmap within an organization, the relevance of Agile principles, and shares insights on creating effective strategic communication documents. He also touches on the common challenges teams face when roadmapping and the importance of collaboration and adaptability in the process.

Matt is an internationally recognized product leader, author, and consultant. He is the author of Agile for Everybody (O’Reilly Media, 2018) and Product Management in Practice (Second Edition O'Reilly Media, 2022), and has helped build and scale product management practices at companies ranging from early-stage startups to Fortune 500 enterprises. Matt is the creator of the One Page / One Hour Pledge, a commitment to minimize busywork and maximize collaboration that has been adopted by over 100 individuals and teams at Amazon, Walmart, CNN, BBVA, and more.

Matt is co-founder and partner at Sudden Compass, a consultancy that has helped organizations like Spotify, Google, Clorox, and Procter & Gamble put customer centricity into practice. In his work as a technology communicator, Matt has developed and led digital transformation and data strategy workshops for companies like Audible, GE, American Express, Pfizer, McCann, and Johnson & Johnson.

Previously, Matt worked as Senior Product Manager at music startup Songza (acquired by Google), and Head of Consumer Product at Bitly. Matt is also a musician, recording engineer, and the author of a book about singer-songwriter Elliott Smith. He lives in London, England.

“Roadmap Readme: We write down who is it for, what problem does it solve, how do we know if it’s working, and anything else you should know before you read it.”

— Matt LeMay

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

In the next episode we are talking to Nacho Bassino, Product Leadership Coach. So watch out for Season 1 - Episode 34!

• Transcript

  - Hello, and welcome to the "Talking Roadmaps" Channel. My name's Justin Woods, and I'm one of the co-hosts here, where we talk about everything to do with roadmaps. From the good, the bad, the ugly. Ladies and gentlemen, I want to introduce you to Matt LeMay. Matt, welcome.

  - Thanks so much, Justin. Happy to be here.

  - As you know, we're gonna be talking about roadmaps. The channel is called "Talking Roadmaps", but it's really to talk about people's experiences. Now, having been a former product manager myself, there've been times when roadmaps have been particularly unhelpful for me. And there've been times when they've been a great tool as well. So, I'm really interested in understanding your experience with them. And of course, Matt, you're an Agile expert as well.

  - I am an Agile expert who is sick to death of thinking about Agile, so... If you sense some exasperation in my voice when discussing Agile, it is because Agile is something some people made up 21 years ago, and we're still fighting about it for some reason. But I think there's some great ideas at the heart of the Agile movement, and I'm happy to do what I can to shine a light on those ideas.

  - Why not subscribe? Click the bell icon, and give us a like. Matt, from your perspective and your experience, what's the purpose of a roadmap?

  - I'm so glad you asked that question, because the answer I will give you and your audience, to the great chagrin of everybody, over and over again, is, it depends. It depends. The purpose of a roadmap... The question you just asked is the question that every team making roadmaps should ask first. And one that they often don't pause to ask in the context of their own organisation. I've seen teams have theoretical and academic conversations about what is a good or bad roadmap, or what the right approach or wrong approach to roadmapping writ large is. And the truth is, I don't really care writ large. If you are creating a strategic communication document, you are presumably creating it because there is some purpose that it's supposed to serve. There is some audience it is for, and some need that audience has. And that varies from organisation to organisation. If it didn't, then you wouldn't be saying, "There are some times I've had good roadmaps and some times I've had bad roadmaps." So, I think that the question you're asking is really the first question any team approaching roadmapping needs to ask and answer in their own context. And if they're not able to do that, then they probably have a bigger problem than, what kind of roadmap should they build?

  - Yeah, that's a great answer. And I think it's, again, one of the reasons why we don't have an internet-wide template for this thing going, "Download your roadmap template here," because for every company, it's different.

  - Well, we do have that. We just have hundreds of.. We have hundreds of competing templates, each claiming, in its own subtle way, to solve a problem which cannot be solved at a global scale, but only through contextual knowledge.

  - Yeah, such a great answer. And it really makes us think actually about, what is the purpose of a roadmap, or what do you want it to do? What do you want it to do? You know, do you wanna paint it a picture of hope? Do you want it to align people together? Do you want it to be a document to have a conversation around? I love that answer, Matt. That's great. And so, it can have quite a bit of scope there. So, who do you feel is the audience of that roadmap, then?

  - So again, it depends. And that's one of the questions that is really important to answer. So when I work with teams on roadmaps, before we talk about the shape or format of the roadmap itself, the first thing we do is we sit down and write a document called the Roadmap Read Me, which goes on a page. I say, "this is the one page that will follow the roadmap everywhere, that will go ahead of the roadmap." And we're just gonna write down, who's this for, what problem does it solve, how do we know if it's working, anything else you should know before you read it. And that's all we do. Before we think about, "should it be an outcome or output based roadmap? How far should..." We just are trying to figure out, who's it for? What's the problem it's trying to solve? How will we know if it's doing that? And once we have those answers, then we can get into some of those downstream questions, and start thinking about the actual form and format of this artefact. But until you've had that conversation, because sometimes you also realise that you don't need one roadmap, you may need five different roadmaps. You have, you know, for example, if you're working with a marketing team that needs to do a media buy by a certain date, they might need to know, "alright, what are the stories we can tell about this product by this date?" If you're working with an executive leadership team that needs to make resources to them, they might need to know, you know, something really different from another product team that needs to know what metrics you might be impacting, or what parts of the product you might be creating dependencies around. I think in a lot of cases, when you try to solve the road mapping problem for a universal audience, it becomes a situation of diminishing returns. Where, in order to meet the needs of one audience, you confound or frustrate another audience, and you wind up with a document that makes nobody happy. So, really figuring out, what is the purpose of this? And if we have multiple audiences with multiple needs, let's actually separate this out, and figure out what exactly each of those audiences needs, and get that to them. So that we don't think of it as the roadmap per se, but as a constellation of strategic communication documents, each of which is intended to serve a specific purpose for a specific audience.

  - That deeply resonated with me. And actually, I think you beautifully answered a question so succinctly, actually, that will come on to you later, that, Matt, if you can try and remember that one for later, that's gonna be epic.

  - I can never remember a thing I say after I say it. It's legitimately a problem for me.

  - You mentioned the constellation of documents. And that pulls in some of the story, you know, even you just describing that, you know, sort of fed a story into my mind. I was picturing what that looks like. And I think that's a big part of road mapping. And also one of the key takeaways that I think I took from there is that, if you create a roadmap for everyone, you've created a roadmap for no one. It's just like, you know, if it tries to serve all of these purposes all in once, it doesn't actually help anybody.

  - I think that's absolutely true. And you also wind up in the situation that I have seen many teams dealing with. Where they get so bogged down in trying to make the perfect roadmap, that they spend a tonne of time thinking about what road mapping tools should be used, what's the right way to do a roadmap, and very little time actually solving the problem at hand, or even understanding problem at hand. It is so easy, it is a low stakes debate to talk about a road road mapping tool versus a different road road mapping tool, or a road road mapping approach versus a different road mapping approach. It's a debate that people can get very involved in and have strong opinions about, without necessarily implicating their most important day-to-day work. Which I think makes it a very appealing debate for teams that are afraid of having those deeper, more implicative conversations.

  - Sometimes, as a former product manager, you know, I've been working with a business, and they can often go into a solution based conversation, you know, where there's a solution before thinking about the problem space. And I think some, I've worked, you know, I've worked for a very specific tool vendor for three years, with Aha! in the customer success team. So I was helping them with that. But what was very striking to me, is that the tool isn't the silver bullet. And it's just there to help you to expedite, or to share, or to automate certain activities. But if you don't have good road mapping practises going in, then you're not gonna have good road mapping practises going out. And some of these tools can be just very open. And sometimes you can hope that the tool brings a level of best practise in there, but sometimes they don't. So I love that thought that, you know, you really need to be intentional about what it is that you're trying to do with your roadmap.

  - I tell people sometimes, if you don't know how to ride a bicycle, you probably don't need a motorcycle that shoots lasers. And I stand by that. Because a lot of teams, especially teams that are new to road mapping, have some fundamental work to do to figure out how they want to communicate what they are working on and why they are working on it. There's a really, really great newsletter that Ken Norton puts out, and he has a post on his newsletter called "The Tools Don't Matter," which I think about all the time. And in there, he offers some reframings away from questions like, what road mapping tool should we use, and towards, how do we communicate and decide these questions that are more based on the actual purpose that the tools are serving? And I think reframing that conversation to, "what are we trying to accomplish," will rarely lead us to a conversation about feature sets of advanced tools. There is a time, and a scale, and a size, and all those things, where there is a conversation to be had about the feature sets of advanced tools. But again, I think that tends to be a shiny object for teams that are struggling with more fundamental questions around how are we deciding what to work on, communicating what we're working on, why we're working on it.

  - That's such a thoughtful and insightful answer, and I couldn't agree more. You know, I feel that tools are there to expedite processes, and it's, you know, it's very easy to go and buy a tool, and sometimes it's easier than to think about your processes, but those things up front makes, yeah, makes a massive difference. Let's think about then, who owns a roadmap, and maybe who maintains that? Are they different people in your perspective, and what would you say from experience?

  - Yeah. I mean, again, I'd say it all depends, but I think those are also questions that need to be figured out. How often is the road map revisited? One of the things I found during my foray into Agile world, one of the most mind blowing things I learned was from a woman named Katherine June, who's an Agile consultant practitioner. And she told me, basically, the more frequent planning you do, the more adaptable you become. Which... I was definitely that scrappy young fellow going into corporate boardroom, like, "don't do planning." And they're like, "yeah, we have to." And I'm like, "do you though?" And they did. But, what she pointed out is that if you have more frequent planned cadences to adjust, you're more likely to actually adjust. It's not interruptive. it's not politically threatening. So I think this question of, what is a predictable cadence for evaluating a road map, whatever it looks like? Who evaluates it? How are decisions made, how often are those decisions made? Those are really important questions to ask and answer. And if you leave them to chance, or if you leave the answers to those ambiguous, it is unlikely that much will happen with the road map. So, I think having, again, counter to my nature as a fairly chaotic person, I am a big believer in the power of frequent, predictable cadences for decisions that need to be made around things like road mapping.

  - Road mapping is a process. Not necessarily just a single page artefact. And we need to slot into the natural rhythm of your own business. And, you know, we need to encourage people to think about these things more frequently. Yeah, Matt, that's a really inspired answer. Thank you for that. One thing that you mentioned, and I loved it actually, was a constellation of artefacts. And I just, you know, I think it so beautifully, kind of, paints this with some storytelling in there as well. What does that constellation look like for you, in terms of the roadmap, and what other things it interfaces with?

  - So I'll tell you what I wind up doing with a lot of teams I work with. So first, we'll do this Roadmap Read Me, and then the team will say, "Okay, great. We know what this needs to do." And I'll say, 'Great, let's prototype it on paper." Before we start looking up, "what are all the different roadmap templates," just get out a pen and paper, I'm putting five minutes on the timer, and you are gonna go in there and prototype what you think an artefact would look like that captures this purpose. And, it's great to see what people come up with. Because, again, it's different in every context. Sometimes it looks like a Gantt chart. It does not always look like a Gantt chart. Sometimes it just looks like a list of, like, "Here are our priorities for the next quarter," just written out. Sometimes it looks like a visualisation of the product, with different things attached to it. There's a bunch of different ways to communicate whatever it is we are trying to communicate to whomever it is we are trying to communicate it to. But, that, decide on the purpose and then prototype it, is usually the approach I like to take to actually creating that constellation of artefacts. Because it also gets us into some thoughtful time boxing. If we only have 10 minutes to do a visualisation, and sometimes I'll have everybody in the group, I've done an activity that I really love doing, where it's almost like a bracket competition, where it's like, everybody comes up with a roadmap prototype, then we put two against each other, and pick our favourite. Then we pit two more against each other, and pick our favourite. And each time, you get one minute to incorporate the things you like from the one that did not win, into the one that won. And by the end, you wind up with something which the whole team has contributed to in some way, and feels pretty good about. That winds up being a great starting point, and you can get through that whole exercise in an hour with a team. And you go from, "Okay, we know what this thing needs to accomplish," to, "Okay, we've actually had a chance to work collaboratively in creating something that's gonna be valuable for us, and that's gonna be literally purpose built to what we're trying to accomplish as a team." And then, you've got something. And you try it, and you retrospect on it, you see what's working, what's not working. Again, in that Roadmap Read Me, we've said what it means for it to work, and potentially what it means for it to not work. So we know what to test it against, and we can get on with our lives. We can stop obsessing over what is the best way to do roadmapping, and get back to building whatever it is we are seeing that we intend to build on our roadmap.

  - Totally. Absolute gold there, Matt, as well. You know, I love that thought of bracketing. Getting ideas of roadmaps from the very people, you know, not looking externally at what Spotify are doing, or Dell, or IBM are doing. It's like, what are we, you know, getting that knowledge from inside the company, because they're gonna know that rhythm of the business. They're gonna know what, roughly, the stakeholders want to see. So coming up very quickly with that, and like you said, moving on with our lives. The roadmap is just one part of what we do, but getting to a quick answer as a starter for 10, I think our audience are gonna find massive value in that.

  - I hope so. I mean, I think, you know, when I started as a product manager, this idea that you own the roadmap, that that is a source of authority and credibility for you, is something that was definitely imparted to me. But, the roadmap is just a document. It's documentation. You know, you talk about Agile and roadmapping, right? And if we're gonna say working software over comprehensive documentation, which one is your roadmap? It's certainly not working software. So, you know, I sometimes think of the roadmap as like the final boss of documentation, because it is the documentation that is going to be the most seductive to you. It's gonna be the documentation that you'll most want to own, and control, and see as a proxy for your value and your position in the organisation. But for those very reasons, it's also, I think, one of the most important pieces of documentation for you to acknowledge as documentation and say, yeah, we're gonna move through this as quickly as possible. Because our customers don't derive any value from our roadmap, they derive value from the things we are building. And if we spend too much time thinking about the roadmap, and not enough time building things for our customers, then we are doing it wrong.

  - So Matt, some great responses there. Let's talk a little bit about the design of a roadmap. So what do you typically believe are some of the key elements or content that you like to see on a roadmap?

  - You know, I personally always like to see some representation of outcomes on a roadmap. I like to see why. Why are we doing this? What is it we actually hope to achieve? If I just see a roadmap in the traditional features on a Gantt chart with dates, format, I don't care in most cases. I'm like, okay, sure, but why? What do we think this is gonna achieve? And I know I am not alone in that. That is a widely held preference among... folks who speak on podcasts such as this. But I think there's also a reality at play here, that in most organisations, when you are asked for a roadmap, whoever's asking for it is imagining that you are going to show up with Gantt chart. It's what folks are used to seeing. And it's, in some cases, what folks need to make specific resource allocation and other decisions. So...you know, I've been thinking a lot about the danger of our love of best practises in the product management world, because so many organisations, for real legitimate reasons, to some extent, fall short of what people think the ideal is. And I often tell product managers, "You can either fight against that and lose, or you can acknowledge that, and do your best work within those constraints. And in doing so, start to reshape some of those constraints." So, a lot of product managers of a company- "They want a Gantt chart. I hate it, this company is terrible. We don't really do product the right way." And I'm like, okay. Do they say you can't put outcomes on the Gantt chart? "No." I'm like, okay, well then, start with what you were asked for, and start to move, shift the window a little bit. Or say, great, like, "Hey, can we sit down and have a conversation before we do this, where we talk through the purpose?" There is almost always a move to make roadmapping a more useful tool for your particular purpose, and to take those ideals of what a roadmap should be, and begin applying them, even when you have frustrating constraints and expectations to work within. And if there is one thing I want working product managers to take away from this conversation, it's yes, you will probably have to make a Gantt chart at some point in your life. That doesn't mean that your company is, "only a feature factory, and doesn't care about outcomes at all." It's an opportunity for you to figure out how to start from a place that is suboptimal, and thoughtfully, deliberately, start to create a better environment for your colleagues and your customers.

  - Yeah. Such a great answer. You know, we shouldn't assume. I think, you know, you mentioned about, what it is that people are trying to see. And the CEO or the CPO, if they're new into the industry or they're new into the company, so, and they're just wanting to see, you know, what's going on, it's actually, to have that conversation, say, "Well look, what are you actually wanting to see with the roadmap? Are you just wanting to see that I'm promising 20 features in six months' time? Or are you wanting to see that these are the problems and outcomes I'm delivering?" And sometimes, you know, they get what they're given. But if you assume that that's what they wanted, that Gantt chart was what they wanted, then they'll see it and hold you to it. And so digging a bit deeper down, I mean... Matt, you must find this in, you know, in your space as well. When we talk about Agile, people's understandings of it, and people's interpretations of it, are so massively different, that, you know, somebody that might have had a bad experience with Agile says Agile's bad. Similarly to someone that's had a bad experience with roadmap, or vice versa. It's a single term, or single word, for such a massive concept, that we can all have different takeaways from that.

  - That's part of why I don't like talking about Agile anymore. Because people, you know, executives say, "We wanna do an Agile transformation," because they've heard that their team can get twice as much work done in half the time. Meanwhile, developers wanna do an Agile transformation, because they heard it means they never have to commit to a deadline. Meanwhile, consultancies are selling an Agile transformation, because they're gonna get paid a giant pile of cash to do things that don't actually mean anything. So, you know, it can mean a lot of different things to a lot of different people. And I think what you said there is so important, Justin, that when someone asks you for a roadmap, or a strategy, or a vision, or KPI's, ask them what they mean by that. Give them examples, give them options. I, you know, these are all terms that are ambiguous. And I think you're spot on, that if you assume that when they say..."oh, they must want this," then you're not only reinforcing that expectation, you're also not giving them an opportunity to learn. You're not giving them an opportunity to step into their best leadership position and say, "Oh, I don't know, what do you think is right?" Or, "Oh, I've seen this before." Or if they're gonna say, "I want a Gantt chart, give me a Gantt chart," then they'll say that. And at least it'll be validated learning, not untested assumptions.

  - Matt, such wisdom there. I can tell you've been through these conversations many, many times.

  - I have, I have. And I've made all these, I mean I have made all these mistakes so many times. When people ask me for a roadmap, I'll still go off and be like, "Oh, they must mean this." Then I'll, I mean, I've been in a situation where somebody asks me for a roadmap. I assume or interpret that to mean that they want a Gantt chart full of features. I give them a Gantt chart full of features, and they say, "Why are you bringing me a Gantt chart full of features? What is this, 1997?" I'm like, "I thought it was, uh..." So, yes. I think testing our own assumptions, and, you know, finding that balance between acknowledging the constraints we're given, but also expanding and altering those constraints, is so much of the challenge of doing this kind of work.

  - And we were gonna talk a little bit, in terms of the design. We've talked a bit about preferred ways to visualise, or tools. I think we've actually touched on that a lot, which is actually, it's more important to think about what the audience is looking for, and finding the right tool that underpins that at the right time. But I've seen some excellent roadmaps being done in Miro, and that's completely fine as well.

  - Part of why I like doing the roadmapping prototyping on paper, is that you're not... and a huge shout out to Christina Wodtke, who's one of my favourite writers about everything, whose book, "Pencil Me In," I highly recommend. For folks like myself who do not fancy ourselves artists, but who need to learn the skills of visual communication. You know, sometimes somebody will draw something, which I never thought of as a roadmap. But, you know, I did this once with Tricia Wang, my business partner at Sudden Compass in New York, and we wound up drawing a ship on an ocean, visiting different islands, and then what the sea monsters were, that were trying to devour the ship as it approached each island. And that wound up being our roadmap for a project, because that told the story in a way that just made sense to us, and helped us meet our purpose in that moment, which was, "How do we feel narratively engaged? How do we create stakes and meaning and, you know, investment in this project?" So I love using this unbounded visual approach, bound only by a time box. Because it gives us a chance to come up with new ways of visualising things, which, you certainly are not gonna find a, you know, Google sheets template, but you are gonna find in your own imagination.

  - What do you think some of the biggest mistakes people make are in roadmapping? I think you may have alluded to some of those already, but just quickly fire through some of those.

  - Yeah, I mean I'd say number one thing is mistaking the roadmap for the product itself, right? One of my favourite quotes from Alan Watts, who said, "The menu is not the meal." And I think about that all the time, when it comes to documentation. Your product roadmap is not your product. Your user story is not your user. These are, again, strategic communication documents, but they are documents. And when you start focusing more on the roadmap, or on the user story, or on the presentation you're giving, that...it is bad, and it is a trap I see a lot of teams falling into.

  - And talking about, you know, some of those travesties. Are there any anti-patents or bad practises that you see teams falling into as well? Any additional ones there?

  - Yeah, I mean, I think there's another one, which has been a subtext and text running through this conversation. But I've seen teams get into a lot of relentless circular conversations about what is the quote unquote right way to do road mapping, rather than taking pen to paper, and doing something. I see this a lot with product strategy, as well. Part of why I like to get people from purpose to prototype as quickly as possible, is that you actually learn a lot more when you're trying to prototype a living working document for your specific purpose, for your specific team, versus having a conversation about, "What do we think the right way is to do a thing?" Which, again, is usually a pointless and fruitless conversation. So that's why, you know, a lot of coaching calls I have with production, "I'm gonna have to come up with my strategy for the next quarter." I'm like, "Great, let's prototype it right now, in the next 10 minutes." They're like, "What?" And I'm like, "Yeah. Prototype it and bring it to your team and see if it works." But until you try it, you won't know if it works. So don't disappear into a cave for a month, and then come back with a hundred slide strategy deck. Throw something together, bring it to your team, see if it helps them make decisions, and if those are the right decisions. And if not, then keep working on it. But it doesn't have to take forever. And do it quickly. Do it in a time-bound way. Like...you know, again, it is a means to an end. You are not delivering a roadmap to your customer. So, don't... Just don't. Just don't.

  - Matt, you've shared some great people in our, you know, our product, and roadmap, and Agile fields there. So, whose advice on road mapping do you typically listen to?

  - Whoever is making the roadmap. That's the, this is another area where I think, you know, as we've fallen in love more and more with best practises, there is a tendency to take the word of thought leaders over the word of practitioners. And I struggle with that a lot. Because whoever is making a roadmap for their team is gonna know better what their team needs than I am. And I think, you know, the best thought leaders are people, you know, people I really admire and respect, like the Theresa Torres's and Adam Thomas's, and folks like that world, are seeing close to practitioners, they're finding patterns, and they're generalising out those patterns, and saying, "Here is a structure that is useful in a lot of different contexts for you to apply into your own context." And I think that... Yeah, just being able to recognise that whoever's making the roadmap is gonna know better what their team needs and what their organisation needs. Those are the people to trust and listen to.

  - And maybe if we're just bringing a concept or an idea from those people, well we're gonna be iterating on it so quickly to work with our stakeholders and what they wanna see, that we may move on from that anyway. So take that as a starting point, but don't get too caught up.

  - Exactly. And again, part of the reason I like doing this generative paper thing is that sometimes, somebody will come up with something that looks a lot like an existing thing. Like, that looks like an opportunity solution tree, or something and be like, "Oh, well you did..." Like, I think that good ideas have a tendency to spontaneously regenerate themselves. Like, when something is a good idea, multiple people will discover it, independent of each other. So I also think it's fun when, rather than starting with a thought leader styled idea and then customising it, people start with a purpose-built generative idea, and then it starts to look more like something that you read about, and it's like, "Oh, that's really cool." Like, that makes the person who came up with it feel validated, and it also validates the idea that they are inadvertently replicating.

  - Such great advice. Now, I hope the listeners and the watchers at home, you're taking some things away from this, because I think that's really important, is, don't get caught up on this. Enjoy that process. Make it iterative. Make it applicable to your industry. There's no other company out there exactly like yours. So why should your roadmap or your processes be exactly like another company? If you had to distil your philosophy of roadmapping into a couple of sentences, what would you say?

  - Start with purpose. Prototype quickly. Get on with it.

  - Value bomb, right there. Is there anything about road mapping that I should have asked you but that I haven't? Anything that you'd kind of like to leave our audience with as a parting thought?

  - It's such a big, important seeming topic, but again, my advice to people is trust your intuition. Trust your local knowledge. You know what your team needs better than anyone else on Earth does. Don't feel like there is some secret knowledge out there, that only the most advanced roadmap experts have, and that you have to do things the exact way they do things. You know better than anyone else, what you need in your situation. Learn as much as you can, can look at as many examples, absorb as much information as you can, but go with what seems right to you.

  - A lot of what you said really resonates with me there. I'm sure our audience would love to hear more from you, as well. And I'm looking forward to kind of following you closely on LinkedIn, and the more work that you do. As I mentioned, your books are on my reading list. I've actually got Christina's book slightly higher at the moment, 'cause I bought that recently, so I'm gonna be going through that one. But how can people...Tell us, tell the audience a little bit about what you do, and how you can help them, if they want to get in touch and work with you in future.

  - So I'm based in London right now. I am consulting and coaching, doing workshops, doing longer term engagements with organisations that are trying to streamline the way that they work. As you may have guessed, I am an action-oriented human being, and I'm particularly interested in breaking the log jams of organisational complexity, which can be issues for big companies and small companies alike. If you are stuck in the theory, and you want help with practise, if you have big ambitious goals, and you're not sure how to get there, then please reach out to me, 'cause I can help.

  - Matt, I've absolutely loved speaking with you today. What a refreshing perspective on something that people can get really caught up with. But actually, we just need to disambiguate it and make it easy, right?

  - Yeah, make it easy. It can be fun. Roadmaps can be fun, I promise.

  - Matt, thank you so much again. To the audience out there, if you've really enjoyed the discussion between me and Matt, if something resonated, please let us know in the comments or drop us a like. Maybe share this with somebody that you think could really learn from what Matt shared there, already. Even though Phil and myself are speaking with industry experts and practitioners, we always take these little nuggets away from these conversations. So if you find something of value, do share it on with somebody. And if you'd like to take place where Matt is today, and have a chat with myself or Phil, in order to give us your views on roadmapping, do get in touch as well. But Matt, thanks again for being so gracious with your time. It's been a real pleasure.

  - Cheers, this was a delight. Thanks so much Justin.