Is your roadmap a paper victory? | Maarten Dalmijn

In episode 55 of Talking Roadmaps, Phil Hornby interviews Maarten Dalmijn about the pitfalls of traditional roadmaps and how to avoid creating "paper victories." Maarten shares insights on building empowered teams, setting effective sprint goals, and delivering real value in Agile and Scrum environments.

Maarten is a consultant, speaker and trainer at Dalmijn Consulting. Maarten helps teams to beat the feature factory all over the world. Millions of practitioners have read his best-practice articles on Agile, Scrum and Product Management. He specializes in helping companies to build empowered teams that can discover better ways of delivering value.

Maarten is a frequent speaker at Fortune 500 companies, government organizations and international industry conferences. He has worked with many award-winning start-ups and scale-ups. Maarten is an ambassador and editor at Serious Scrum, the largest Scrum publication on Medium. He’s also the author of Driving Value with Sprint Goals: Humble Plans, Exceptional Results.

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 Vidas Vasiliauskas, he is a CEO at Teamhood. So watch out for Season 1 - Episode 56!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about all things roadmaps, the good, the bad, and the ugly. Today I'm joined by Maarten. Maarten, can you introduce yourself?

  - Yeah, hello, hi, I'm Maarten Dalmijn, I'm the author of a book on Sprint Goals, "Driving Value with Sprint Goals." And yeah, I work as a Product Management/Agile Consultant, dabbling a bit in the world of Agile and product management. Prior to that, I worked at startups, scale-ups, corporates in product management roles, and one year ago, I decided to take the leap to help companies all over the world. So that's, maybe, let's keep it short, but that's what it is.

  - Sounds good and yeah, I know that journey as a former product leader who's also a now a 10 product coach, it's an interesting journey and I do love the leverage we get in terms of helping organisations personally.

  - Yeah, it's really cool. It's very different, like yeah, it's an adjustment, but it's also very, very interesting. But yeah, it's a nice position to be in, yes.

  - And if I remember rightly, you're crossing the Netherlands.

  - Yes, correct, I'm in the Netherlands. Yeah, so I was born in Amsterdam, and I live in Hilversum, which is like 20 minutes from Amsterdam.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. What's the purpose of a roadmap?

  - So the purpose of a roadmap, I think it should answer a few questions. Like, so where do we want to... So what are we trying to achieve and what do we intend to do to achieve that? And I think it's really important to separate the two, because very often what you see is that roadmaps really focus on what we want to do instead of what we're trying to achieve. And yeah, there's a difference between the two.

  - Okay, and so unpack that a little bit more for me. What do you mean by what do we wanna achieve?

  - So basically, delivering a feature doesn't mean you're delivering value, right? It's about like, what made does the feature make possible? So it's really about how are we creating value and how are we're capturing the value? And that that's basically the outcomes we're looking for. And of course, features can make those things possible. They can deliver value, right? They can create value and they can help with capturing the value. But it's not like that if we deliver a feature that it's guaranteed. And that's where kind of in the roadmap, you need to separate the two, because otherwise, yeah, you have a feature factory and then you deliver the feature and you believe that delivering a feature makes it certain that you're delivering value. And that's why I think a roadmap should help with that. Like separating, decoupling those two things.

  - So who are we communicating this to? Who's the audience that's looking at this thing of our, what we're trying to achieve, the value that we're creating and capturing?

  - So I think it also really depends in the sense that, let's say you've got a public roadmap, some companies do, right? I think if you were to make the public roadmap the same as your internal roadmap, all that uncertainty regarding like, what are we trying to achieve? They don't care about that. They just wanna know, Hey, what's coming in Q1? You know what I mean? So I think putting that aside, right? I think the roadmap is for the people in the company, especially if you're working in a product company, there has to be common understanding. Like if you're working at it for a SaaS product, I don't think it's just for the C level, it's also for the teams that are doing the work. So they know yeah, what are we focusing on? What do we believe matters? Yeah, and at enterprise companies for example, very often it becomes a coordination instrument, you know what I mean? Because coordination is the problem. So then they list features. So that's why it's very difficult to answer who is the roadmap for, because I think it serves different purposes. And very often, for example, the C level, I'm talking about, but the C level, they wants this sense of certainty, this confidence that the teams know what they're doing. So yeah, there is a purpose, right? But different people expect different things. And as a product manager, you need to manage those expectations and not like, hey, a roadmap that looks glorious and perfect on paper, I call it a paper victory, maybe won't set us up for success.

  - Yeah, I mean, one of the previous guests, I think you can call it consensual kind of realities, like we're all buying into this future view of the world. We know it's probably not really gonna happen. And yeah, I mean it's, it's something that is casting a view out into the future, but you're right, there are different audiences. I think I'm on five different audiences, which probably all need different views of my roadmap at this point, which becomes a bit of a pain now. But you went there, you said as a product manager, so you said. So is the product manager the person that owns the roadmap?

  - I think owning a roadmap is a difficult question to answer, right? 'Cause let's be honest, if you're working at a product company, the roadmap is crucial for the whole company. I mean, sales, marketing, the CEO, everybody cares about the roadmap because if you work on the wrong things, it will impact the whole company. And that's where I believe it's the job of the, maybe not the product manager, but like one of the lead product managers or the head of product, or chief product officer, to make sure that to facilitate the right conversations. You need the input from sales, from marketing, like it needs to be something that is not just the product management department throwing what they believe over the fence, like you said, like there needs to be this shared understanding across the company. And that's the conversations you have to facilitate. And that's what makes it so incredibly difficult. But everybody has to share the same understanding and you can only have a great roadmap if you include all these different perspectives because building a product is very holistic. It's not like just marketing, just sales, you know what I mean? They all influence the product.

  - Couldn't agree more. I give a talk called Your Roadmap Sucks and one of the kind of problems I identify around roadmaps is, each treated as one person's artefact. When reality, it's the team's artefact, it's a team alignment, communication. This is the direction we're going. It might be the product manager that does the admin work and puts it into it, but yeah, we've gotta kind of, and I guess that may be pretty, it brings an interesting opportunity to bring sprint goals into that. How would a sprint goal align with what's going on the roadmap and those different audiences

  - So here's where it gets interesting, right? So if you think about it, you've kind of have like different phases. Like you have discovery, you've got delivery, you've got validation. And it's not like that there are waterfall phases, one happens before the other. Like it could be that you go from validation back to discovery. But the main thing I'm trying to say is when you use sprint goals, you're in the sprint, you're trying to deliver something, right? So what's really important is that you understand, hey, this is the outcome we're trying to achieve and this is the output we're producing during the sprint that we believe help achieve that outcome because outputs drive outcomes, you need both. They're linked. So the moment you talk about sprint goals, you're really getting more into the delivery level because what I don't believe is, so you have all these people saying like, yeah, you have to do discovery during the sprint, but let's be honest, most sprints are two weeks. So discovery means planning enough customer interviews, you know what I mean? Like that's not gonna ha... And then coding it and then, it's not gonna happen in two weeks. Like I don't believe that, like sometimes just getting the right customer interview already takes two weeks, you know? So yeah, so where does principle fits in? Really in the delivery parts. And now why is that crucial, it's because deliveries uncertain. Our estimates are wrong, we discover surprises. So sprint goals help keep that scope flexible because we're saying, hey, this is the goal we're committing to, we're trying to achieve during the sprint. There may be other things we're working on during sprint as well, but this is the one most important thing where you believe we can make the most impact. And yeah, I compare it to the commanders intents, like you have mission, like this is gonna be a military comparison. So I'm not trying to glorify war, but every mission is accompanied with a commander's intent. What are we trying to achieve? Why does it matter? And that means that the people on the battlefield, the people that do the work, or in our case the scrum team, they're free to adjust plans as necessary to meet the goal. Which is great, because that means the product owner or product manager, they don't have to answer every question, make every decision. Yeah, so that's it in a nutshell.

  - If discovery's not happening within the sprint, but we want to involve the same people in discovery, how do we align those things?

  - Yeah, so maybe I'm just wanna make sure I'm not causing a, how do you say, misunderstanding. Like, but it's happening probably a sprint before, you know what I mean? It is in a sprint, in the end, you need to plan it and you need to involve the right people. And as you know, like with product trios, it needs to be people from the team. So yes, you should plan it, but there isn't this forced sprint vowing to read it, everything has to happen in one sprint. That's the main thing.

  - Got it. Yeah, and so then I'm absolutely aligned. It's like essentially you are doing the prep work a little bit to then be able to focus on the delivery. In fact, sometimes I reformat the now, next and later roadmap into deliver, discover, and I call it explore, which is kind of the strategic context of finding the problems, for example. Because one of the things I realised a long time ago when I looked at the now, next and later was later meant, I'm trying to understand the problems, next means I'm trying to understand the solutions which might include a spike in my sprint. And now means, okay, I'm focusing on getting this done so I can get it out the door.

  - Exactly, that's exactly how I'd like to work as well.

  - Now this all goes into a context, and I guess the same thing's true with the sprint goal. This vision, the strategy, there's objectives, they're all kind of informing these things and making them kinda link together. How do they link together in your view?

  - The way I see it, a vision is something that doesn't exist yet, right? That's kind of like what you're trying to make possible with your products in the world. It's a dream kind of, you know? Like it's something which is not yet there. It's like the future state you're trying to achieve. I'm trying to think of a good example, right? But maybe like the iPod, right? Like a thousand songs in your pocket, like before the iPod, that's already like one sentence kind of a vision, what you're trying to achieve like a thousand songs in the pocket. They didn't have that, nobody had that then. The strategy basically, is about what are we trying to focus on? Like where are we playing to win? And a good comparison I always make, a friend of mine was a poker player and he was a really good poker player, but he actually, he played against football players because they had a lot of money and they were not that good at poker. And that was his strategy, basically.

  - I love that idea of a strategy.

  - Yeah, yeah and they have big egos. So when they lose, you know, they hate losing, so they wanna win, you know? So it's the perfect... So he was actually playing against like, yeah, famous Dutch football players, I'm not gonna mention names. And yeah, he was making a killing. And this is strategy. So how do you link together, right? So you need a vision, you need a strategy because they inform your roadmap. Because your roadmap is kind of like a set of choices you're making as a result of that vision and that strategy. You cannot do everything. And they're like relevant context that guides the creation of your roadmap. And basically, the better your vision and your strategy, the easier it's to say no. That's the way you should see it. If you have a weak vision or a weak strategy, that means anybody who comes to you with an idea, it will be yes, that's the moment you know, you have a weak for vision or strategy. The moment you have a strong one, good example is the PalmPilot, like when they created the PalmPilot, they made it a pretotype, I think it's called a pretotype. So was like a wooden block because the guy who made it, I forgot his name, unfortunately, or he was involved in making it, he made a previous product which was too big and nobody used it, right? So he was like, it has to fit in your shirt pocket. And he always carried it around because everybody like, okay, so we're gonna make this sound better, will it still fit in the shirt pocket, you know? Yeah, so if it can empower you to say no to things, then it's really, that's of a good indicator. And very often, the visions I see, the strategies I see, they're not empowering people to say no.

  - Then in fact, I think I remember that same story. I think he also forced himself into testing. If you could build the habit of, I have a meeting, I have to put something in my diary, can I force myself to take it outta my pocket, tap on this thing a couple of times and put it back away, for example. You might even have been part of the general magic team, if I remember rightly. If we go back, which is a great example, a great video to watch on there, Amazon Prime. IPhone was invented so long before iPhone.

  - Yeah, it's interesting. We can also talk about that, but what I found even more interesting is like there's this story that Steve Job was like totally in favour of the iPhone. He wasn't, you know, why they created the iPhone? It's because they saw like, I think a Nokia phone which had a sound MP3 player and they were like, this can kill our entire iPod market. We need to do something. And they had to convince Steve Jobs like, Hey, we have to do something. This is going to eat our whole market. And then they did the iPhone and they ate their own, they cannibalised themselves, which is great.

  - I mean, I even heard one story that there were two teams working on the iPhone in parallel. See, who could come up with the best idea inside Apple, I don't know if it's true, and the joke I heard was that when Steve on the very first version showed himself deleting a contact with a swipe or something, it was the person who was leading the second team. I dunno how true it is. I mean, it could be one of these urban myths, but it just sounds so possible.

  - Yeah, it sounds really cool.

  - Now obviously, you're getting into this, into the Agile world quite a lot, Maarten. So I'm guessing there's also some other artefacts that flow out of the roadmap and link in. Could you kind of join those dots for us?

  - If you work with Scrum, which is the most popular Agile framework, you have a product backlog. And that's basically a list of things you're gonna be working on. And the main thing there is you need to keep it short because that's what I very often see is just like with the roadmap, it's a long list of things which basically, should have you very worried. It's kind of like having a refrigerator with like 20 cartons of milk, they're gonna spoil. Like you don't want that. And that's the main thing, it's kind like you should have enough for a few sprints and that's about it. And yeah, of course, there's a sprint goal, but that's something you create every sprint. It's not something you create ahead of time and you have a product goal. But yeah, Scrum is pretty rigid about that because it basically says you have one product goal for the whole product, which doesn't make sense because yeah, you have got acquisition, you've got retention, you always got multiple things going on. And I understand for one team that they have one thing to focus on, but for a whole product, just one thing to focus on, I don't know, it seems a bit too radical.

  - Yeah, I'm wondering if we need a roadmap goal as part of our kind of whatever this planning or iteration cycle is, you know, if we're updating every month, every three months, should we have a goal or does the product vision act as that equivalent, I wonder?

  - I know what I always tended to do and I'm just curious to hear what you do is every sprint review I will pull out the roadmap and just show this is the current state. If nothing changes, if stuff takes longer, I think that's really important and, because you do it regularly. Yeah, it also really shows the emergence, the uncertainty 'cause that's the main thing that people struggle with. Like very often it's used as instruments to provide a false sense of certainty. And I think by regularly revisiting and regularly repeating over and over again, that it's emergence and you figure it out as you go along, I think that helps a lot. And that's why yeah, I do it every sprint review and that can be very short.

  - So for me, get every sprint reviewer probably every day with somebody I'm talking to about it. Because you know, the one thing I've realised is I might be talking about it every day, but the people in front of me probably aren't in front of me every day. So they hear it at a much lower frequency. And so it feels to me like I'm a broken record, but for them it's like, I haven't heard this for a month. I've suddenly seen what's changed. I'm actually, one of the things I'm quite a fan of is finding ways to make it more stable without taking away that reality of uncertainty. And one of the things I've often found there is changing what you put on the roadmap instead of putting on the features or the epics, maybe putting on the problems I'm solving, what do you like to put on your roadmap?

  - I'm a big fan of a Now-Next-Later roadmap and yeah, really focusing on like, for example, like you said, if you're doing discovery, really focusing on this is the problems we're solving and then if you're working on it more on a solution level, like saying, hey, this is the feature we're building to achieve X or Y and yeah, I think it's probably pretty similar to what you, because you already said that, I think we follow a similar approach, that's my guess. And what I absolutely don't do is provide timelines for stuff we're not yet working on. You know what I mean? Like at most, maybe the quarter, we intend to tackle it, but that's it. And if we're working on something right now, then I have no problems to say like, Hey, we're working on this right now, we expect it to be done in July or 15th of July, or whatever, that's cool because you revisit it every two weeks and you just stress, hey, this is based on the current understanding. There will be surprises that's the nature of the work. And yeah, that's what the conversation needs to be having. Like, hey, we don't know everything before starting. I call that the fog of beforehand, before starting, you don't know everything. And if you try to fight that by doing more planning, congratulations, now you have the fog of speculation, you're only making things worse. So that's very important.

  - I mean, there are things you... There's an interesting point there about planning and analysis, getting there. There are domains where we can plan, where we can do it and there are domains where we can't. Now software tends to be not the great one, unless we have an absolutely clear delivery. Like I've dealt with people in say the, I think it was the credit card market and they have a clear cadence at certain dates, they've gotta release certain network update that are two-way standard. And frankly, you can plan to that. You can hit that date and you can set that as a deadline 'cause it's an external constraint. So I'm okay putting those on, even if I haven't done much work, I might have done a basic, you know, spike or something like that, say, is it even feasible? But yeah, I generally avoid the dates wherever possible.

  - Yeah, no, I completely agree. So I agree with you. So I actually worked in E-commerce, right? So let's say you're rolling out a new payment method and you've already done it nine times before, you probably can pretty reasonably predict how long it's gonna take. There might still be surprises, right? But most of the time, and I think the other thing to keep in mind there as well is there's a difference between doing something new and polishing something you already have. Like if you've already built something and you're making small improvements, probably you can do that pretty predictably, you know what I mean? But the moment you're doing something completely new, let's say you're building a completely new notification centre, that's a different ball game. But if you're like adding a new notification to that notification centre or a small something, that could be pretty predictable. So that's also something, it's a very good point you're making. It's not black and white.

  - And that's the thing, a lot of leadership has grown up in the past of a more manufacturing-oriented world where that planning, that mindset of analysis can get us to the answer like, heck, building a bridge or going into space, we've gotta do the analysis to figure out how to do it. Yes, there's some iteration that Elon's gone through, for example, but all with known experiments to test to get certain results. And it was all about making sure that when they do finally really hit the button, it's gonna happen. It's gonna work and it's guaranteed. And it's a planning process. Like you build a bridge, you can go through a lot of best practise to figure out the stresses, the strains, all the rest of it. Now, when you dig into the ground, you might find a different substrate than you expected. So there's still some emergence stuff. In the city I grew up in, I remember there was famously a place where the river between the east and the west. And the local court council decided they wanted to do a tunnel for underneath the river. And they did it and they tried and it kept collapsing because it was just sand. And they actually knew it, but they kind of had this bravado, we'll make it work. What they should have done is done the analysis, really and said this doesn't work. Ultimately, they built a bridge because it made sense.

  - No, but I think you're absolutely right. And you were talking about Elon Musk, I mean, the way I always call it, every step we take shapes the way, like we're surrounded by this fog beforehand. We've done everything before starting, every step we take, we remove some of the fog and let's be clear, right? Elon Musk also makes mistakes. It's not easy. A good example is the model three factory where they used the robots. Like he wanted to automate everything. That was a big mistake because he realised that a lot of stuff that he wanted the robots to do, humans still were able to do better than the robots. So when he realised that that's the moment he was able to ramp up the production for the model three. And I think that's the key learning here. Like you need to really watch out because if you believe you're smarter than you really are, you're gonna do something like that. Instead of having every step you take shaped away, try it out, see if it really is better. And it's really dangerous because we're so trained to predict and plan because we're smart, that's what brains do. They simulate, like predict and plan instead of acknowledging, okay, I'm not that smart or I might be wrong, let's see what the evidence says. And that's very hard.

  - The analogy you used there earlier as well, fog, is one that Luke Herman uses in his software profit streams book of like the fog is in the landscape, and we navigate that landscape with tools and techniques like roadmaps, like sprint goals, you know, we go up high so we can take a vantage point. That's our vision, that's our strategy. We work out, we look at the map to say what problems might we encounter as we go along. Product's no different.

  - Correct. And the key thing to keep in mind, and this is a quote, but I know from what is, "the map is not the terrain."

  - And therefore, we might find some of those unexpected emergent things as we start going through them. Like if we're a Roman army, we might suddenly find a lot of Teuton warriors in the middle of that forest.

  - There will be surprises. And then you have to deal with them. And that's the main thing we need to expect.

  - Do you have any preferred tools or ways of visualising a roadmap in your world?

  - Kind of my philosophy is, every step you take helps shape the way, right? So I don't start with tools. So usually what I tend to do is, most companies I joined use Jira. It's just an unfortunate fact of life. Well, maybe it's a fortune, it's not that bad, actually. I hate Confluence more, Jira, I can deal with it as long as it's next-gen Jira. But the main thing is, in next-gen Jira, you can just make a come on board and then you just make Now-Next-Later with epics. And it's just very simple. It takes half an hour and you have something and then you start using that, and then you discover we this or we need that, can we... And then when you've went through that and you feel like it's not good enough, then you have adequate understanding to pick a tool. And that's the main thing I always try to tell people, don't start with the tool, first start with like what you have and how far it takes you and the moment you bump to the ceiling, kind of like the robots at Tesla, right? You notice the problems then you know what you need for your context, then you know what you need at your stage of the organisation. And that's the main thing I always do. Like start with something simple and not start with a tool.

  - In fact, I often start with mirror these days or an old white, or a traditional whiteboard if I'm in a room with people, or just good old PowerPoint, I know people malign it, but it's so flexible.

  - I have the feeling we use similar approaches.

  - Well I like to think that's 'cause that's what the best do.

  - Yeah, you're too modest, Phil.

  - What in your view is best practise in roadmapping?

  - So I think the most important thing is, start with humble plans. That's what I call it, humble plans. So acknowledge that your plans cannot take everything into account and it's really important to, like you said, talk to your stakeholders, include them and make them understand that the purpose of a roadmap is not to exude confidence, to have this glorious plan that looks magnificent and signals to everyone we know exactly what we're doing and when it's gonna be done. Absolutely not. It's like you said, it's supposed to be a guide. I think that's really the best practise. Like the roadmap should look, make us feel a little bit uncomfortable and uncertain because that's the reality. It is uncertain. There is this fog and I think that's the number one thing you have to do, I think that's really a big best and the other thing as we already talked about it is, it has to be emergent because we're doing discovery, we're doing delivery, we're doing validation. Every step we take helps shape the way. So we discover, let's say, we're working on something and we're discovering, it's more valuable than we expected. So maybe we're gonna be working on that longer. You know what I mean? Like we're gonna improve it even more, and I think that's the crucial thing. There needs to be room for this learning and emerging. Those are the two I think, best practises. And if you do that, then you're already like doing great compared to yeah, many companies I see.

  - So what we're saying though is we definitely don't kind of make it super, super pretty wrapped. Invest tonnes of time in polishing the visual, then print it out on a plotter and stick it on the wall.

  - Yeah, absolutely not. But here said, this is the one caveat, right? The reality is you need to meet the company where they are. And that's the challenge because if you are working at this big enterprise company where you have 10 teams with all component teams, you need to coordinate with 10 teams. What I'm saying is not gonna work, you know what I mean? You need to probably have an ugly feature-based roadmap with all dependencies because your challenge will simply be getting anything at the door, you know what I mean? And you first should fix that. And I think that's the challenging part. You need to really realise like what part, like what kind of company we're in, what is the current situation and the reality is, where you want to be and where you are, if there's a big delta, you need to create a slipstream. You know, like you need to be a little bit ahead, but not too far 'cause otherwise, there's no slipstream. And if you are too far ahead, you lose them. Like you're gonna have dirty air, you're gonna just disconnect everyone. And I think that's the balancing act you have to do. And I think that's really difficult to do well and that's the challenging part. But don't start with a Now-Next-Later roadmap, like you and me kind of were talking about with discovery, living, validation when they are miles away from that, because you're just gonna alienate them. We're just gonna think, what the hell are we doing? Does this person know what they're doing? So yeah.

  - In fact, I often even encourage, let's have a roadmap for our roadmapping. It's like how are we gonna evolve? We are here, we want to be there, how are we gonna get there?

  - I think that's a very good point because yeah, then you can also really acknowledge, hey, this is the current situation, so we're gonna really involve them, have sessions, what is a roadmap for, and gently get them out of their comfort zone.

  - So we've gone for the good practise. What about the bad practise or the anti-patterns?

  - There are so many anti-patterns that you see like having a long list of features with all the timelines specified for one year advance and then the team starts working on it, and then after the first month there's a delay. The whole roadmap, you're not gonna deliver anything on time. I've seen this happen like at a company in the whole year, everybody in the company is frustrated. Those are, I think, the clear anti-patterns. Like I absolutely hate Gantt chart roadmaps. Like I mean, I do understand they have their place. If your delivery is the main obstacle, it makes sense, you know? If that's already challenging enough, you are happy to get anything outta the floor. But please like, that's not the maturity of companies, I hope at least.

  - I mean, so I've got a little thing on, we're trying to write some guides on them at the moment of 12 different roadmapping visuals styles and Gantt is one of them. And one of the things I like to say is, if your company has a Gantt chart feature-based, date-based roadmap and is delivering tonnes of value, it is working for you, don't worry about changing it, but I doubt it is if that's your practise.

  - I agree with you as yeah, I mean, probably there aren't, but I do want to stress, like I said, if you've got this huge coordination problem, that probably is the reason why you have this roadmap, it's a symptom of another problem. And that's the problem you need to fix. And if you go to the Now-Next-Later roadmap probably, yeah, minds will be blown and you won't deliver stuff because this problem hasn't been fixed.

  - What are your thoughts in terms of, if you find yourself in that context, what are the the biggest things that a team and organisation could think about of how to break their way out of that, kind of that madness, should we say?

  - Team structure is incredibly difficult. Like, I think it's really important if you have 10 teams that need to coordinate to deliver something, to reconsider your team structure, in an ideal world, you want to create as little distance as possible between the team and their ability to create and capture value. You want to minimise that because inter-team collaboration is incredibly difficult. And the more teams, the more difficult it gets. And you should really reconsider, are we organised in an effective way? And that's what you should be talking about. And I really don't think that dependency management there is the solution there. Like that's a duct tape solution. It doesn't work. And that's the main thing, the first thing you have to do. And I don't think there is a clear answer there of what you should be doing. You've got teams topologies, which a great book, which talks about different ways of team templates that you can use and how to organise the different teams. But that's what you should be tackling first, I believe. And then when you tackle that, then you can reconsider the roadmap because otherwise, it yeah, you're not solving the actual problem.

  - Yeah, I guess we're in the world of how do you scale Agile and I think the philosophy I've fallen into is the best way to scale Agile is to descale the work, not to try and scale Agile. Unlike should we say some of the more prominent methodologies at the moment that seem to go the other way of adding more overhead.

  - What I always say is skill as you solve problems, don't skill to solve problems. And yeah, I think that's really crucial. And I actually studied life science technology. You start with a small reactor, you see that it works and then you scale it up and then that's exactly what a lot of companies are not doing. Like they're using a scaling framework, boom, badda-bing, badda-boom, everything's there. And then, okay, let's see if it works. No, that's not how it works.

  - Now I know you have a concept of the planning cycle of madness. Could you kind of maybe unpack that for us and how that relates to a roadmap?

  - So basically, you've probably seen this happen at companies before. So what happens is management is unhappy, right? Because we haven't delivered our roadmap on time, everything's been later. So they tell the people in the teams, Hey, step up, you've gotta do a better job at planning. So what happens is big room planning, everybody goes in meeting rooms for days and days talking about what they will be doing, all the dependencies over and over and over again. And then what happens is, yeah, the plans get injected with this false sense of certainty, this fog of speculation and then surprises happen. And then we're anchored in plans, you know, that slow us down and prevents collaboration and then congratulations, everything's delayed, management isn't happy again. And then the whole cycle repeats. And I've actually seen this happen 10 times over again at enterprise companies like the whip, you know, you need to do a better job planning and it's just incredibly frustrating.

  - Totally, been working with a large enterprise company recently, where the request is we need to improve predictability and the assumption is more planning.

  - So what I always say is, the more we prevent to suck at predicting, the more we'll guarantee to suck at adapting.

  - So Maarten, whose advice on road mapping do you listen to?

  - So I really like Janna Bastow. Like she, I think she has very similar opinions on planning and roadmapping. I really like the Now-Next-Later roadmap she invented. I use it a lot. I really like Paweł Huryn because yeah, he just writes a lot about all these different facets that also roadmapping, but also vision and strategy. I think those are great people to follow.

  - If you had to distil your philosophy on roadmapping into one or two sentences, what would it be?

  - Start with humble plans. Every step you take shapes the way. Go where there's no path and leave a trail.

  - Maarten, been an absolute pleasure having you here today. Always like to give people a chance towards the end of the session to just give their pitch how they can get in touch, where they can find you and how you can help, fire away.

  - You can find me on LinkedIn, send me a message if you want me to ask me a question or send me an email, I've got a website. You can find it when you see me on LinkedIn. And I've written a book on Sprint Goals, so if you like what we talked about. Yeah, my book is basically about that. How do you handle uncertainty by leveraging goals.

  - Been a pleasure having you here today, Maarten. Thanks very much.

  - Thank you very much too.