Does your roadmap need a retro? | Dan Olsen

In episode 49 of Talking Roadmaps, Dan Olsen and Phil Hornby discuss the importance of retrospectives in product roadmapping. He shares insights on how retros can improve team alignment, uncover hidden issues, and drive continuous improvement. Dan also emphasizes the role of feedback loops in maintaining an effective and adaptive roadmap.

Dan is a product management trainer, consultant, and speaker. Dan wrote the bestselling product management book The Lean Product Playbook. Through his talks and interactive training workshops, Dan helps companies build great products and strong product teams. His clients include Google, Facebook, Uber, Amazon, Box, and Walmart. He is also the founder of the 12,000-member Lean Product Meetup community. 

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 David Pereira, he is a Product Leader and Thought Provoker. So watch out for Season 1 - Episode 50!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about the good, the bad, the ugly, everything about road mapping. Today I'm joined by Dan Olson. Dan, introduce yourself.

  - Hey, Phil, thanks. It's great to be here, my name's Dan Olson. I am a product manager, trainer, speaker, consultant, and author. I wrote the book, "The Lean Product Playbook" that some of your listeners may be familiar with. I just really enjoy working with product teams and organisations to help them uplevel their skills and how they practise product management.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. And I love the book. What I did realise literally this morning is I don't have a physical copy, so I've listened to it in Audible, is how I consume most books these days. So I had to order myself a copy this morning. Amazon don't get here quite the same day.

  - Yeah, no, it's cool, yeah, no, also, before I had kids, I had a huge bookshelf and I would read physical books and after kids, the only way I power through, I power through audible books all the time, so I feel you.

  - Well, I have a full a kind of approach. I listened to it on Audible, if I like it, I buy the physical copy. And this one just made it through, somehow didn't make it there 'cause I did like it and I re-listened to it in the last week to get ready for today.

  - That's great, yeah. Well, I'm excited 'cause if you listen to the audio book, you might wonder if I'm the one that reads it or not, but if you know my voice and if you know me, most people can probably tell it's not me reading it. I just found out that they're actually gonna let me rerecord it and I'm gonna get to narrate it. So I'm very excited about that.

  - So Dan, let's jump straight in there. I mean, obviously the core content of this channel is road mapping, but I know we're gonna bring a lot of stuff around lean, and discovery, and solution, and planning and this sort of thing. So we're gonna follow those rabbits down the rabbit holes as we go. But let's start out with something really, I guess the low ball question of what's the purpose of a roadmap?

  - Sure, yeah, I think, you know, one of my favourite diagrams of product development is the one that's like the big squiggly line on the left and then it kind of squiggles and squiggles and eventually gets straighter and straighter and straighter, right? You know, our job as product people and product teams is to create order outta chaos, right? There's so much uncertainty and all this. I also like to play a video of people herding cats, right? We have to get people together, get them on the same page, get them rolling in the same direction, whatever your favourite metaphor is. And so I think that for me, the top goal of roadmap is to get people aligned on what's the work that we're planning to do, like what's in scope? And by definition, if it's not on the roadmap, then it's not in scope, right? So it's just, for me, it's a high level plan to get people aligned on what are we working on, in what order, you know, so that we know kind of the logical sequence of work that we plan to do.

  - Sure, and I mean, there's a couple of things I could unpack there. One, you said, people, who are those people?

  - That's a good poin, yeah. So certainly, you know, if I think about it, so within the product org itself, right? So if you're a PM on a product and you've got a roadmap, then it's helpful for other people in your management chain and your colleague PMs to also see in case there's things that they need to incorporate into their roadmaps. Obviously your listeners, some people may be the only PM at a startup, so it's just them, other people could be at a big company where they're in a big PM org where there's a lot of other product managers they should be coordinating with. Then there's obviously like the triad or the trio of the people on your team, like the designers and the developers. And not to exclude other people, could be QA, could be DevOps, could be, you know, data analytics people as well, right? So the cross-functional members of your scrum or product team or feature team basically, right? And then obviously kind of key stakeholders, everybody's favourite, right? I just saw a funny post on LinkedIn about a HIPPO, Highest Paid Person's Opinion, right? And it was like two pictures, one with data, one without data, it was very funny. But the stakeholders obviously are a key audience for the roadmap because roadmaps by definition should be high level, right? That's one of the things I'm sure we'll get into. Sometimes people make their roadmaps very, very detailed and tactical and it's meant to be a high level planning document. And that's where, you know, key stakeholders in other organisations like sales or marketing or within the business unit or business partners are gonna wanna know about it and be aligned with it as well. So there are multiple audiences, and that's all internal. And then obviously you can have external roadmaps too. Usually it's best not to have 'em be the same so that you haven't set these expectations outside the building with customers. But you know, your customers often wanna know what's coming down the pipe, what can they plan on seeing coming as well. And I guess going even further, if you're a big company, if you're a visionary, if you're a leader, you might decide to go beyond that and talk to analysts and the press and things like that, you know, to kind of foreshadow and show people what's coming down that you're a visionary, here's how we see it playing out. So there's both internal and external audiences at a high level.

  - Yeah, and so we've got this high level plan for these various audiences, but how do we decide what's going in the plan? Now that feels like a lean thing, right?

  - Yes, yes, and that's, you know, we're gonna get into stuff and peeves and you know, my background's kinda engineering, so I like things to be logical. You know, we wanna have a reason. You should be able to point to any box on your roadmap and be like, why is that there? And be able to, you know, concisely explain why that's there and why it's one, A, on the roadmap and B, why it's in the position that it's in. Why is it after this or before this other thing, right? So I do think a lot of thought goes into it just to contrast that it should not just be like, well, we asked everybody what they wanted, we got a huge list and we just kind of picked, randomly picked X items and threw 'em on the roadmap. And you know, we're both kind of smiling a little, but, and I don't think anybody's all the way at that extreme of the spectrum, but there are people that are closer to that side of the spectrum than to what I described at first, which is it's very deliberate, how data-driven is it? Things like that, right? So we want also, it's important for it to be a collaborative process. It's not like there's one person who's a roadmap czar who dictates what it is. It's a typical product thing where product is driving the creation and recommendation of a roadmap, but then they have to get, you know, they have to consult with other people, review it with other people, get buy-in from other people, right? So it's one of those typical things where it's like it's our job to drive it and come up with a recommendation, but we aren't necessarily the final approver of the whole thing, right? So lemme, if I sum it up, it's a collaborative process driven by product management that is hopefully based on evidence and data and logic and reasoning, right? More so than just randomness or opinion or gut.

  - Yeah, I mean funny if I do a talk called "Your Roadmap Sucks." And one of my key kind of problems with a roadmap is it's treated like one person's artefact as opposed to the team's artefact.

  - Yeah, and then you wonder, if you do that way you wonder, well, no one's following my roadmap, what's going on? Yeah, 'cause it's your roadmap, it's not their roadmap. Yeah, and that also gets into aspects of how you sharing and communicating it. Beyond the group of decision makers, there's other people that need to be informed. If you think about like a dacy or racy thing, it's like who else who needs to be informed or consulted? It's broader, right? But in general, it's better to err on the side of being broader than narrower as far as who's involved or who's informed.

  - Now, you talked about it being quite high level and I know you know that there's a common conversation in the product space around problem space, solution space. So, and you talked about people a minute ago, saying hopefully not taking that list of orders, which are typically solutions, but what are we putting on the roadmap? Is it problems, is it solutions, is it somewhere between?

  - That's right, this is funny. So usually the most common roadmap I see is, and let's just break it down on a high level. You've got your themes, hopefully you know, one of the best practises is you're organising your roadmap by themes, which tend to be horizontal swim lane, I mean, there's different visualisations, but most commonly you have horizontal swim lane is going from left to right, you know, as time goes left to right into the future, that you have swim lanes that are themes, and then you put boxes in those swim lanes, they put the boxes correspond that swim lane, right? The top thing I see is solutions in the boxes, which is okay, but then solutions for the themes, which in my mind is not okay, right? It's like the point, I like to basically make sure that the themes are more like goals or objectives. And when outside of a roadmap context, when I'm talking about how do you create a successful product or feature, and I talk about kind of the lean product process, the product-market fit pyramid, I make a big point about one of the top reasons products fail, we hear about, hey, over 80%, 90% new products fail, one of the top reasons in my mind is they were never clear on the customer problem they were trying to solve. They start with solutions, right? And I talk about the segue as an example. Like a lot of times people just get enamoured by the technology or you know, last night at my meetup, my lean product meetup, I just hosted an AI speaker and there's a lot of people running around. It's like AI, it's like a hammer looking for a nail. Just like I'm just gonna slap AI on this thing and you know, and they're never clear. So it's usually this like technology du jour, you know, this is not the first generation of chatbots. We did chatbots about whatever, eight, 10 years ago. It's like chatbots, we're gonna gonna, you know, or like blockchain, what are you doing for blockchain, right? So you just see a bunch of people chasing that solution as opposed to the problem. So certainly for your swim lanes and a roadmap, a customer problem is a solid theme, like we wanna, you know, streamline this process or this workflow for our customers, right? That would be great. We wanna improve the efficiency of this, we wanna help them grow their revenue or increase their ad effectiveness, whatever it is, right? That's a customer problem. The other category is perfectly fine too, is a business metric. We wanna optimise conversion of this, we wanna improve acquisition, we wanna improve retention, things like that, right? So for me, those are the two high level categories of things that are perfectly fine to be a swim lane, either a solidly defined customer problem or a clearly defined customer metric that we wanna grow. And usually it's a mix of those things, right? As opposed to, you know, security as the swim lane or integrations as the swim lane, right? Or some other solution thing. Now then what you put in the swim lane, this is where it's funny because for most people I would just say, okay, great, once you've got your swim lanes, go ahead and put your features in boxes, right? But for even more advanced teams, there's a version where the boxes in the swim lanes are also just more detailed problems or goals, right? And so it just depends on what level you're at. So if I'm talking to, you know, I try to, if I'm talking to a product org, and I can tell that their level of maturity isn't like super, super high and they're already, they're basically, I see that the roadmaps have solutions in the swim lanes and solutions in the boxes for the features, then I'm just gonna try to get them to change the swim lanes to problems and call it a day and say, "That's cool, plan out your solutions right." 'Cause I'm not gonna be able to move the needle a whole lot. But other people, and it is very, it's rare, I'd love to hear your thoughts on how many teams you see do this, but there are some teams like, you know what? We don't put any solutions in our roadmap. What we do is we just get really clear on the problems that we wanna solve. And if our swim lane problem is improve the conversion of this one flow or process, then our boxes within that swim lane are more detailed breakdowns of elements or components of that that we believe we're gonna do, right? So, and then if you get into a kind of a super, super, super, I guess advanced role, it's like why do we need anything besides swim lanes? Like you know, we've got these empowered teams that are doing experiments every week or two, we just give 'em a goal, we give 'em an OKR, we give 'em a target and we let them do it. So that's kind of the spectrum that I see, right? You got solution swim lanes, solution boxes, problems, problem swim lanes, solution boxes, that's perfectly fine. That's where most people you know, are aspiring to be. And then you've got problem swim lanes, problem boxes and you've got just, hey, we just have problem swim lanes and we don't need any boxes. I guess those are four kind of, you know, and it's very rare for a team to be so empowered and advanced that they're at that fourth step that I talked about, but every once in a while you kind of see that, especially when it's more of like an experimentation team, when they're doing more AB testing and stuff like that. It's not even worth at the beginning of the quarter listing the 40 experiments you plan to run or 50 because you don't know. You might know the first four or five you know that you're gonna do, but you dunno the other ones beyond that.

  - Yeah, I mean, I think some of that's contextual. Like, like in a B2C organisation, I absolutely agree, in a B2B we tend to have a better understanding of the problems quite a lot earlier. Now I'm a fan of maybe the increasing level of certainties we get closer to now. So for example, we have the problem and the solutions 'cause we've done the discovery in the now or plus term and then we've just got the problems in the next term and might just have the metric we wanna drive in the even further out, for example.

  - Yeah, I think it's funny, I think that sounds great. Again, that would be something a more advanced team could do. If you try to explain that and have a team that's not high on maturity to do that, they'd be like, "Wait a minute, you might need, the boxes are not all the same thing, "I'm totally confused, what do you mean," right? But I hear you for sure. And regardless, the point is, I think you brought up a great point, Phil, which is, hey, the closer it is to today, the more certain it is, one, that hopefully that we know the problem. I mean, there are plenty of orgs not doing much discovery at all that have roadmaps. So, but the other thing you can say is that's the thing that's most likely to get done 'cause that's what we're gonna work on next and we think it's gonna take this long. But even if it takes longer, because it's the first thing we're gonna work on, it's the least at risk. That thing that's like six features out at the end of the year or the end of the roadmap, that honestly could be speculation or you know, hopeful thinking, wishful thinking. So just, I think it's important to know that the likelihood of it getting done varies as a function of how far out from where we are, how much we understand what it really is and what we plan to build varies the further out you get, yeah.

  - I think when we had Rich Mironov on a while ago, he even sort of suggested, well, make the shapes fluffier or make them all more transparent the further out. So it kind of denotes that variation in certainty. You talked about left to right of time, in the research we've done through our channel and our road mapping workshops, we've kind of come up with a list of 12 different visuals and they're not all left or right ones, and for example, which kind of breaks some of the mental models. We've got some visual guides coming in the near future. We can actually, for the right type of roadmap list, like a strategic roadmap can have a very different presentation to say a more delivery oriented one.

  - I like it, but time is just a construct. You don't have to be constrained by it.

  - Absolutely, well yeah, I mean, I guess we've gotta get stuff done in a certain amount of time, but 'cause there are some business necessities as well, like if we don't shift certain amount of time or win certain deals, we might not be here next year.

  - Yes, no, yeah. Well also, I could totally see there's obviously multiple ways to do it. I could see how in the process of trying to identify a strategy, vision or roadmap, it would be great to not worry about time in some of the initial steps just to kind of get your head around more important things before you go try to lay it out on a timeline, right? And that's what sometimes people can rush too quickly and try to lay it out on a timeline. But you just brought up something to jump ahead a little bit. Like that kind of gets it is like the planning, you said we need to launch something by a certain day. And so it's just an interesting thing, you know, there's a funny saying, I think it might be Douglas Adams, he said like, "I love deadlines, I love the whooshing sound they make "as they rush by," or something, right, basically. And it kind of gets to a Myers-Briggs JP thing, judging versus perceiving thing, not to get too deep on that, but it's funny because I I kind of, you know, I didn't really know much, think about deadlines. I actually started my work, my career in a very waterfall design thing, which was building nuclear powered submarines, which you want to be waterfall, you don't wanna launch the V1 and have it sink and go, okay, let's iterate to V2, all those people died. So I worked there very much, you know, it's not like we had a, somebody had a formal gantry somewhere, it's not like we were slave to some formal gantry, but there was certainly a sequence to the process. And then I went to, you know, software, and then I just learned over time, I'm like, you know what? Sometimes there are deadlines that are real and sometimes there are just these fake deadlines. Like management's just saying do it on this day 'cause, and when you ask why, it's like, well, just 'cause we need it by then, right?

  - It's a forcing function. They're trying to ride you and whip you half the time.

  - One reason, no, sometimes, but sometimes not that. Yes, sometimes that is used and don't get me wrong, then later I do think deadlines can help a team rise to a challenge, and in the absence of any deadline, you don't wanna be super agile, like the whole, the agile mindset of like, we don't do deadlines, that's not agile. Like you know, I see both sides of it, but my point was just that I saw the deadlines being set and some were real like, hey, we need to be, or real, like had more of a case like, hey, we wanna be in stores before Labour Day and that, okay, cool, because historically we know there's gonna be labour day back to school sales and stuff like that, okay, cool. Or there's some big industry conference, we know we wanna be at TechCrunch, or we wanna be at, you know, whatever it is, okay, cool, right? But then there's all this other baloney, it's like, oh, we just gotta do it by March 1st 'cause you know? Or you know, the funny thing, I like that you mentioned B2B, I have a talk on Enterprise PM, I'm like, you know the magical dates of B2B software, right? The end of the quarter, March 31st, like June 30th, right? September 30th, what is it, why are these the dates? It's like, okay, it was just 'cause that's when the end of the quarter is. And so it's just like that's when we ship stuff. So I hate it when they're kind of arbitrary. I hate arbitrary deadlines because it kind of, and if you ask me why, it's like it takes away a lever that I have to try to optimise the value of delivery for the team and we have to just kind of do this thing. And the other thing is, very rarely are organisations good at scope estimation and plannings. So they think you can get this date but you know, it's like that's the other thing I hate about some roadmaps is like you put a bunch of stuff on a one pager for your roadmap, who actually checked that we could, what level of confidence do we have that we can get all this things done in the quarter, or the year, or the four quarters or whatever it is that we're doing, right? So it feels a lot like this and it feels like the head of product and engineering kind of just eyeballing and going, "Yeah, I think we can kind of get that done." And then when we slip things and we don't hit our roadmap and then management and the CEO's all upset, it's like, you know, it's just this bad dynamic that I see play over again and again.

  - There's always a reason why something can be and will be late. I don't think there's ever a reason why things get to be early, and so it's inevitable it's gonna end up to the right, but yet we have this over optimised optimism that it's going to be when we predict it will be. And we know humans can't predict.

  - Yeah, I mean, this and I think that this is the thing, 'cause you know, I've been doing this for a long, long time, so I work with a lot of different companies, and there are certain challenges that, depending on what phase you are in the journey of your product management evolution and agile evolution, UX evolution and analytics evolution, but I would say even the best companies, once they're like, okay cool, we're crushing agile, we have enough PMs, they're empowered, they have the skills they need, we have UX design, we have all the teams, right? We're cranking on our execution, the last mile problem I see even top tier companies struggle with is this kind of product planning muscle. And you know, I think that the cadence that people do it in is like quarterly, right? I mean, there are plenty of companies out there doing annual roadmaps and I'm not saying you shouldn't do that, but what I'm saying is, to your point, for the next quarter, let's really kind of bust sharpen our pencil and try to increase the confidence of the planning for the next quarter so that if we say that we're gonna get these 13 things done, we have a high degree of confidence. That's the problem that plagues even the best companies out there still. And I think it's because again, like, you know, it's funny because when you do sprint planning, you are using story points in your velocity and if you pay attention to it, you can get pretty good at it's like, oh geez, we got a really good handle on, yes, we can get those six stories in, we've done a good job estimating them and all the things and refining them and you can get pretty predictable at that level, right? Can we replicate that, a similar mindset and process at the quarterly high level product planning thing, right? And it's funny 'cause I've seen teams try to do this, I've even seen them try to use story points. It's like, okay, this one's 10,000 story points, I'm like, no story points is the wrong units to use at the quarterly level, but because they've built this muscle at the tactical sprint level, right? And so a couple things, one is like that's where you have to use like people time units. You've gotta use like people weeks or people months or something, right? And you've gotta estimate it and it's just high level math. Even if, you know, I think most companies don't just do the high level math of okay, we've got these 11 boxes in our roadmap for the next quarter, how many people months is each one? Let's add 'em up, let's see how many people months do we, we know the quarter's three months, how many people do we have, how many engineers do we have, right? And we can get certainly more nuanced about types of engineers, front end versus back end. But just as a first blush pass, like does the math add up on the people weeks that we have? And I think unfortunately, most roadmaps that I see, no one's even done that simple high level check that I'm talking about. And then the other thing is, okay, great, you had, let's take that you had 10 engineers, let's keep it simple, or a hundred engineers. Yeah, a hundred engineers. Did you put all a hundred on the feature work? Because remember we have tech debt and maintenance and issues and live site, right? So that's one other mistake in a resource allocation is did you budget about, you know, 10 to 15% of the pie for that so that, you know what I mean? And then you take that into account. And then you gotta be honest with yourself. Even organisations that have great, and you've probably seen this too, obviously, great roadmap, imagine you wave a magic wand and you have the world's perfect roadmap at the beginning of the quarter, you've done all the things that Dan and Phil say to do and it's like right size, you've taken into account tech debt, you know, everything's cool, what's the other problem that bites you? Then three weeks into the quarter, ChatGPT gets launched and your CEO goes, "What's our gen AI strategy?" And you have nothing on your roadmap that quarter for gen AI and all the stakeholders saying, "We gotta have some gen AI thing, jam it in there, cram it in there." And so now you try to cram this in and you had a perfectly balanced zero sum game. And I call these meteorites 'cause they come in and they just go pugh, and they blow up your roadmap. Now at least if you have a roadmap where you know what the effort is, now you can say, okay, cool, we can be adaptive. What do we wanna horse trade, what do we wanna swap this? The gen AI thing's gonna take 25 people weeks, great, let's go and displace 25 people weeks of something that we haven't started yet hopefully. And you can do that zero sum game kind of trading, right? So that's the other thing is a lot of times people treat their roadmaps as static. We did it at the beginning of the quarter, they act like nothing's gonna change and then the meteorites start coming, the changes start coming and then the whole thing's out the window at that point. Even if you started with it planned at the beginning, scoped properly at the beginning, which again, most people don't, so people don't start at scope properly at the beginning, it's aspirational at best, then the meteorites start coming and no one's making any trade-offs. And so then no one's saying, you know, there's no one's saying like, oh, you know, because of the lack of planning and the lack of, and the meteorites, these five things at the tail end are gonna slip. Nobody actually says that out loud 'cause they don't wanna be the messenger that gets shot. But what happens is things just slip a quarter, right?

  - There's so many market events that can happen. I mean, obviously a few years ago it was COVID that we would've used as that example. Now we've got gen AI. I mean, last year we had everyone had to cram in a Web3 something, yeah. And maybe go a few more years back, an augmented reality thing had to be on there somewhere.

  - Totally, VR, AR debate, yeah. There's always some solution de jour, some technology to de jour. And the stakeholder is in the shower, hears a podcast or on the drive in to work something, and then next thing you know that meteorite comes in.

  - We've got the customer meteorites as well.

  - Customer, yeah, for B2B especially. And that's the other thing, back to solutions and problems, you know, and I also talk about this, I'm sympathetic especially to B2B startups. When you're a startup and you're not cashflow positive yet, you need to get revenue. And so you've got these, if you're lucky enough to get the meeting with the big company, you know, and get them to listen to you, and then they go, "Great, I'm gonna give you a big bear hug, I'm gonna hug you in tight. I need you to build these five humongous features for me." Now it's like okay, you're gonna go do it, right? But they usually specify solutions, right, not problems. And it's sad because the number of times I've seen some big company, you know, kind of mandate to a startup, "Hey, we need you to build X for us," and the company says, "Yes, sir, yes, ma'am." And they go off and they build, the startup builds it and then the big company doesn't even use it 'cause they were not even clear on what their problems were, right, it's sad, but.

  - I do wonder sometimes if it's actually they just want to flex that power full muscle.

  - It could, yeah, it could be, it could be. I don't think it's done with any bad intent. I think that they don't have awareness of the problem themselves, right? And when you become aware of this problem space solution spacing, which again, so solutions are like a feature, if you say let's go build a feature, blockchain, gen AI, those are solutions or technologies. And instead if we say, well, the customer problem we wanna solve is we wanna give better answers to people's questions or you know, whatever, you know, we wanna help people do their taxes more quickly or whatever it is, it's getting clear on that problem that you're trying to solve. And so good product teams are able to, you know, you're not gonna tell the problem, sorry, to a customer, sorry, that's a solution, we're not gonna take that. You don't wanna do that. What you wanna do is, "Hey, Phil, I hear you asking for feature X, that's great. We probably should be able to build feature X. Just to make sure we build it in a way that meets your needs, can you help us understand what problem it's gonna solve for you?" Like, you know, just kind of pivot the conversation to start talking about it. And then you might realise, well, yeah, they're right, that is the best solution, but a lot of times that isn't the best solution or it's like more than you need or it's a partial solution. It's like well actually we can repurpose this other thing, right?

  - It's often why I like to put the problem or the job to be done on the roadmap because they rarely change. But as you do that discovery, you find the solution that's the best or the optimum solution instead of the one you were first asked for.

  - Totally agree, you bring up a great point, which I always bring up, which is when I show these problem-based solutions space maps of like, hey, here's the problem, here's the solutions, new technologies come and go, right? I talk about like say TurboTax, I used to work it into it like, you know, these days people are filing on, they're using a browser based app to do it. Before that they were using a CD ROM based app to do that. But before any computers, you know, the US government was getting their tax money, people just had to do it by hand, right? So, you know, the need to kind of file your taxes did not change as new technologies come and go. Another example I give a lot is like listening to music on the go. Right now we all just use our phones. Before that we used to use MP3 iPods. Before that we used, you know, non Apple MP3 players. Before that we used Walkman. Before that we used FM transistor radios. You know, back in the mediaeval days you'd have a minstrel or bard. So it's all the same goal of listening to music on the go, but new technologies come and go. So yeah, I like that too, the other benefit of focusing on problems 'cause when you also get clear on the problem, it opens up different solutions, like different solution space ideas that might be beneficial or superior.

  - Part of that that we've just talked about there is going into the discovery space and there's this kind of the live product, there's discovery in a live product, but there's also discovery leading us towards product-market fit. Now you mentioned earlier your product-market fit triangle. I'm sure that our audience would love to hear about that and maybe there's somewhere weaving that into what we might put on our roadmap.

  - Sure, yeah, yeah, yeah, yeah. The product-market fit pyramid is the main framework and it's a pyramid. It's got five layers basically. And the way to think about it is, and by the way it's called product-market fit pyramid. But if you're working on a new feature, it's the same thing. The way to think about it's the five hypotheses you need to get right enough in order for your feature or product to be successful. And the first and the idea, it's a pyramid, 'cause each layer depends on the layer beneath it, the foundation are our customer, right? That's the other thing too, right? So everything starts with whose customer problems or jobs to be done are we trying to solve? And that's one thing where you can cause misalignment. If you're going after one type of customer and I'm going after another one, then of course, you know, later on we're not agreeing about what features and the priorities of the features, that also is a way to get people aligned, right? Which also brings up an interesting question on your roadmap, but if you've got different customer segments or different types, how do you handle that in a roadmap?

  - Yeah, I love, for example, to put the customer on there. Like, I might be solving this problem, but 10 customers have the same problem. Who am I solving for today?

  - Right, right. Totally right, yeah. And that's where like especially in B2B, you wanna pattern match. You don't wanna just, you know, build something for one company and then realise, oh gosh, the way that their problem or the way they solve this problem is an anomaly, the way they think about it, and it's not relevant to the rest of the market. So, and then the next layer up from that is underserved needs. So that's really about problem space. Getting clear on the customer problems before we pursue any solution ideas, just to make sure so that we've got this tight mapping. Once we agreed that this is an important problem to be solved, then we can say, great, well, now let's brainstorm some solution ideas for how we mention it, right? So the message is not, hey, don't ever think about solutions. It's just make sure you're clear on the problems before you start going down the solution path. And then the other word in that layer is underserved. So when you do the discovery and you brainstorm, what I call exploring the problem space, what are all the different problems we could solve within this market opportunity? The next question becomes great, which of these are the best opportunities for us to pursue? And that's where I like to imply the importance versus satisfaction framework where you take into account how important is each of these needs to the target customer. Everything's a function of the target customer. Like this kind of this target customer is gonna have one set of importance values, this other customer's gonna have another set. And then also the satisfaction and the long story short is you wanna find problems for a certain market segment that are high importance, that they say these are really important to me, and that they have relatively low satisfaction with. And that's where the biggest opportunities lie. And you know, I sum up back to this thing of we've all heard 80 or 90% of new products fail. The top two things you can do to mitigate is one, don't start with a solution, make sure you start with a problem, and two, run the importance and satisfaction analysis and make sure that you are able to find a problem that's in that upper left opportunity quadrant. If you just do those two things, your odds of success go up significantly. And now it's just a matter of okay, you know, design and coding, execution stuff. So, and then the next layer up, that's the market, the customers and their problems are the market. And then the product layers of the product market procurement are your value proposition, which are, which benefits are actually gonna promise to customers. You know, what are you actually promising your products gonna deliver on? And then how's it gonna do so in a way that's better than the competition? That's where product strategy and differentiation lives, at that layer. That's still in the problem space. And then the next layer up is feature set or functionality. Now we're finally getting to the solution space. So step four is solution space, after we've got this solid foundation in. Who's our customer, what's the key problem to solve, how are we gonna solve that in a way that's better than the competition? Now we can brainstorm features and then the next layer up is your user experience basically where you bring it to life with a UI and UX. And then step six of the process is just, then we take that prototype and we test to see how we're doing on product-market fit and we iterate from there.

  - Yeah, and I love the fact that that's applicable throughout the life cycle of the product at the feature level and the product level. Heck, even the portfolio level. We've talked a lot about what's on the roadmap, who it's for, these sorts of things. What are the biggest mistakes you see when people are road mapping?

  - The funniest thing is when I, and it doesn't happen as much now as it used to, but it still happens once in a while, I'll be like, Hey, do you have a roadmap? Oh, yeah, Dan, yeah, we have a roadmap. Lemme show you a roadmap. And they pull up an Excel spreadsheet and it's literally a list of things in an Excel spreadsheet and you know, maybe it's go all the multi weight columns on the right or whatever, right? But the point is it's a spreadsheet and I'm like, okay, that's not a roadmap. Or they'll be like, yeah, we have, yeah, we have a roadmap and they'll pull up their Jira backlog. And I'm like, no, that's a backlog. There's a reason we have a different word for backlog than roadmap, right? So there's missing the fact that it's meant to be a high level visual document. Again, you know, it's not just a list any, and I would just say in general, if it's a list, if it's a list representation, whether it's in Excel or Jira or whatever, then it's not about that, it's not right. The other one I already covered is people, you know, either not having swim lanes or putting solutions as the swim lanes as opposed to customer problems or metrics. The other thing is obviously this happens, people planning way too far out, here's our 10 year roadmap, here's our five year roadmap. It's like, why are you even spending time, you know? And theoretically look, there might be some space you're in that's so slow moving that, yes, that's relevant. But one of the first things you need to do when you're about to create a roadmap is say, what's the right timeframe? Should it be two quarters, one quarter, three quarters, four quarters, six quarters, right? And again, there may be industries like maybe biotech or something where you need to plan two or three years out, five years out. But I think for most SaaS software kind of things, you know, you're just kind of fooling yourself, 'cause back to your point, the farther out it is, the more fantasy it is, the more ethereal it is. Who really knows, like things are gonna change, right? So those are some things that I see. And then also people just like, it goes, even if it's a visual representation, they're trying to cram so much information into that one page, right? They've got all these little notes and details and all this stuff. It basically is like a list crammed into a one page kind of PowerPoint. You know, they're trying to make it fit on one page, but they're jamming all stuff in, which gets back to the point of it's not a high level document. For all those reasons, the issue is you're still in the weeds. Like you gotta get out of the weeds. Like the weeds are important every sprint, yes, go execute in the weeds, you know, every sprint, great. But when we're doing this high level planning, you gotta pull back to the 10,000, 30,000 foot view, you know, take a survey of the landscape and here's what we're trying to do. So those are some of the mistakes that I see.

  - I mean, I totally agree with that kind of high level need. I mean, too many times corporate documents are these slideuments that are just full of text as opposed to that visual artefact that tells the story of the direction of travelling of the road of the products. I've gotta admit that like the longer term roadmaps have been quite common in my previous life. I was in automotive for example, we're working on five, seven year life cycles. But also I think at a strategic level that there can be a value to it. Like we mentioned gen AI earlier. Well, I could eventually guarantee on a strategic level roadmap three years out AI was there for most organisations. It just came a little earlier.

  - Yeah, pulled in, yeah, definitely.

  - And I guess the benefit of that would be people might already be thinking about how do I build the capabilities a little bit 'cause it's already on there, which might have helped.

  - Maybe a little bit, but if it's so far out as a little placeholder then you know, the short term tends to trump. But I hear you, no, I hear you. I think that's, yeah, that would be kind of, that high level thinking would be most relevant to like product leadership, senior leadership, things like that. You know, I might not even, yeah, investors board, things like that. I wouldn't even probably show it to some line level product manager, 'cause like they're like, "What do I do with it? "Like, you know, what do I do?" But yeah, no, I hear you on high level strokes. But again, there's tonnes of uncertainty the further, and automotive totally makes sense. Heck, submarines, you know, are even longer. It takes 12 years to design and build a submarine. So we had definitely had long roadmaps there, right? So that's why I said I don't want to be, it's easy to kind of be dogmatic, so you should never have a roadmap that's more than five years. I'm not saying that, it might be relevant to your space for whatever you're doing, but just be honest and mindful. Like you can plan further out, what's the downside? You're just wasting time and resources, okay, you can do it. You know, you can go a little further out but then it's all gonna change. And that's the thing is as hopefully over time, just like we talked about a sprint retrospective feedback process and a product planning, hopefully there's some roadmap feedback process, right? That's the other thing I'm advocating with my clients too is hey, whatever, however you do your roadmap today, that's fine. At the end of the quarter, dust off the roadmap you start at the beginning of the quarter, have like one meeting, even if it's just an hour, hour and a half, go through the roadmap and say, what actually did we say we were gonna build and ship actually built and shipped? If you wanna get into what shipped on time versus not and why, that's great. It's not a blame game, it's just to learn. It's like a better retrospective, right? And then let's identify all the meteorites that came in and you know, catalogue 'em and just, you just have like a retro at the quarterly level. I think that's very powerful and useful. And that's how you improve that muscle over time of, gosh, we thought we were gonna do 13 things, we only did eight, why is that? Here's why, we underestimated this, these meteorites came in, yada, yada, yada, great. Now we're doing the next roadmap. Are we gonna act like, you know, are we gonna be naive and act like we're just as smart as we were at the beginning of last quarter? Or are we gonna try to incorporate some of these lessons learned from what we just did? You know what I mean? So that's the other thing. I don't see a lot of that retrospective happening. We just keep doing roadmaps the same way. They keep failing to completely meet people's needs and yet we keep doing 'em the same way, right, so.

  - I love that, the idea of a roadmap retro. And I guess that would kind of come into next thing I was gonna ask you of maybe some best practise. I guess it would be new best practise, that particular one, but what else would you think of as best practise?

  - Well, I like to, you know, I like, it's funny 'cause I wrote like a little, for lack of anything better, a PRD, but it's like bullet points. If I had to explain to a brand new product manager, like it's easy to say this isn't a roadmap, that isn't a roadmap, backlog's not, Excel's not, what is, like what are the requirements? I'd just be like, okay, it's gotta fit on one page, right? That's the other thing, sometimes you see people, here's our three page roadmap, it's like, no. You gotta be able to summarise it on one page. It's just a simple constraint, right? It's kinda like a tweet. Like you only have so many characters. Like you only have so much that you, so it forces you to be high level. I think it needs to be a visual representation, a visual summary, not a list view, right? So those just off the bat. I personally like to, you know, I just, to give people construction guidelines, I just like, I go with the traditional left to right, timeline left to right, first thing you need to do, identify your timeframe, how many quarters out are we going? Your quarter, you know, quarters are a good unit. If you're some early stage startup, maybe it's months, maybe it's weeks, who knows, right? Whatever the right quanta of time that makes sense for you. For most companies of a certain scale and larger, quarters is usually pretty good. And then it's like, is it two quarters, three, four, five, six quarters? How many quarters out are we going? And then what should our themes be? What should our swim lanes be? Identify those, right? And then for each swim lane, once you've brainstormed the boxes that are gonna go in there, whether they're solutions or detailed problems, then you kind of lay 'em out. So that's kinda how you construct one, right? The mechanics of constructing one, that's kind of a to-do guy, like a playbook for how to do it. Then you know, couple things that are missing from that is do we have scoping for the boxes or not, right? So you know, in an ideal world, kind of like the size, the width of the box is somewhat proportional to the effort. You know what I mean? So if the box is this narrow, it's let's get two week, two people week thing if it's this wide, you know? You can get a little more if you wanna like have graph paper and make all the units make sense, that's cool if you wanna do that, right? Or you can just eyeball it. The other question related to that is do you put dates on it or not? Like do you put hard dates on when these boxes are gonna be done, within the quarters, do you draw month lines, you know, to kind of give a sense of where we're at? And I think it's okay to have a sense, I personally don't feel the need to have hard deadlines. You know, again, the point is if we've got this, let's just say we've got the roadmap for the next quarter with month lines in there and we've got 12 things on there, you know, the last thing is the one that's most at risk for not getting done. Everybody should understand that, right? The thing that's all the way to the right. And then the last thing to do, the other thing to do is, you know, just look at your roadmap and see and just like take a vertical line and go sweep across and be like, what is that saying how many things you're gonna be working on concurrently at the same time, and is that realistic? 'Cause I've had people in my workshops, they do a roadmap and they jam like five things in the Q1 or six things in the Q1. And I'm like, can you realistically, can your team digest and work on those five or six things at the same time? If not, you need to scoot some things out. You need to kind of just, even if you're not really sharp, don't have a sharpened pencil on resources, you know that we only have four teams that can do concurrent major feature work. So let's make sure at any point in time we don't have more than four major thing. You know what I mean? So you first, you construct it and then you kind of rightsize it and move things, scoot things to the right as a result.

  - Yeah, I think the extra bit I'd lay on there is as I scan across, what story does this tell, how does this align with value to the customer?

  - True, true, true, that would be great. And if you have swim lanes that are problems, hopefully that's a little more self-evident. Unfortunately, especially in B2B, there is no story, it's just, here's the things we need to do, right? And if you're lucky there's some themes, and we've drawn some arbitrary cut lines on each theme and it's kind of whoever yelled the loudest, that's how further it is on the left of the roadmap, unfortunately, right, but I hear you, yeah, it'd be great. That in my mind it's almost like, that could be a separate slide, right? The slide before or after the roadmap that says, here's the roadmap, so you see the nuts and bolts, and then here's the story kind of of why this makes sense and why this roadmap and why these, you know, why these initiatives that we're doing.

  - And then maybe we'll have a page after that that's got just the release plan of those really short term, that's where the fixed date is maybe coming, but not on the roadmap.

  - Perhaps, yeah, I mean, yeah, I mean, yeah, yeah, yeah. I mean, you know, by definition if you've got the quarterly month lines, then it's kind of implicit. Again, that's why it's like those magical dates at the end of the quarter.

  - If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?

  - I mean, let's see if I can get it down to one or two sentences. But basically like, you know, it kind of was kind of what we started with and what we covered throughout this interview, which is, you know, a roadmap should be a high level one page visual representation of, you know, what customer problems and or business metrics we're trying to address in the timeframe that the roadmap covers that's created in a collaborative process, so everybody can be on the same page about what we're trying to accomplish and why.

  - What should I have asked you about roadmapping that I haven't?

  - I mean, one thing we didn't talk about is in larger organisations. Okay, so you know, again, imagine you're a five person startup and you've got one product person, you have one roadmap, right? You have one, it's very simple. And then as you grow and you grow and you grow, and now it's like, well you have multiple product lines and maybe multiple businesses, right? But let's just go to the multiple product line thing. We're still kind of one business, but now we've got multiple products. The question then becomes, okay, each product team has their roadmap that we've got four to six different product teams, what do we do, do we need an Uber roadmap? Should we have an Uber roadmap, right? And so that's where you get, and you don't need to, again, I'm not dogmatic, you shouldn't create one for the sake of creating one, but there probably should be some process, the product leader, some other group, organisational group, leadership group that looks across them to make sure that they make sense, right? And it also gets to this product planning thing I was talking about and I'm glad you brought this up 'cause I think it is good talking about, which is, you know, say you're in a multi feature team, multi-product situation, which most people are, and each team is doing a bottoms up roadmap for their area, which is great. How do you kind of decide on what the reconciled global roadmap is for those six to 10 teams or whatever, right? And that's where the default tends to be, resources stay static. Like that team, the AI team has five devs, the reg team or the, you know, the payments team has four devs and you know, this feature team has three devs, and it's kind of like there's inertia and unless there's a strong reason to move, you know, if somebody quits you gotta deal with it or whatever, but basically assuming nobody quits, like inertia, that is the size of the teams, how do you know that for the next quarter that's the right allocation of resources are not, right? And so what I've seen done really well, again, in very few companies, but I've seen it done well, is leadership will take all the roadmaps from the teams, will put it on a single kind of spreadsheet, will put in the kind of people hours required for each in a view, like a tops down stack view rank order. And then we'll look across the teams and see if like, the thing right below the cut line for team one, do we agree that's lower value than the thing right above the cut line for team three? And if not, then we'll, you know what I mean? We'll redraw the cut lines across the six to 10 teams and we'll reallocate resources accordingly. So that's a more advanced thing. But right, that's where you can use the roadmaps to really fine tune the investment you're making and resource allocation as opposed to just assuming we're going with the same resource allocation that we did before. And again, that's something that obviously takes a lot of skill and estimation, but I've seen it done well where with the prioritised roadmaps, the team provide estimates of, and they know better, right? They know the team kind of knows best. Like, hey, we think that's gonna take three developer weeks, this one's gonna take 10 developer weeks, whatever it is, you can at least do that high level thing to kind of reconcile it. And again, back to your point, now the story makes sense. We're like, you know, we're working on the things that make the most sense for that quarter. So it's more of a cross team roadmap, resource allocation process that I've seen that can work really well when it's done.

  - And I could see the same process resulting in a customer shareable, unified roadmap as well from that product.

  - Yes, yes, exactly. Yeah, yeah, yeah, yeah. And we didn't talk about internal versus external roadmaps, but the main thing there is just, you probably want it to be a little different. You probably want the one that's external to not have as much detail, not promise as much, so that you're not setting up expectations that you're gonna disappoint. So, you know, and the number of times I've heard a PM say, "Yeah, sales kept bugging me for the roadmap, so I gave it to them, next thing I know they published it, they shared it with a customer and now we're on the hook, so I'm not gonna do that again." You know, then they learned that we need two versions of the truth.

  - And I usually find sales publish it after making it prettier, which usually means to move everything three months to the right, left.

  - Make sure it's non-editable whenever you're making it a PDF, whenever you share. That's a good tip, if you share a roadmap, make sure it's something you're comfortable. You know, the basic thing is like PR training. If you're gonna say something publicly, make sure it's something you wouldn't mind being on the covers of the "New York Times." If you're gonna share a roadmap, share it in a non-editable format like PDF and make sure it's something you wouldn't mind if it got out the door because it might just get out the door.

  - Dan, it's been absolutely awesome having you today. Maybe you could give people some information about how they can get in touch, how they can find you, how you can help them.

  - Yeah, Phil, thanks a lot. It's been great talking with you about this. Yeah, so my main website is dan-olsen.com, O-L-S-E-N. Yeah, you can go there and you can see talks that I've got. One thing I didn't mention is actually for almost 10 years now, I've been running a product community called Lean Product Meetup. We just had our last one of the year last night on gen AI of all topics, and we've got over 12,000 members. So each month I host a top product speaker. Before COVID, we were in person, during COVID, we went to 100% virtual. Now we're hybrid 'cause we built up a really good base. So you can go to, again, there's pointers from my website, dan-olson.com, or you can go to meetup.com/lean-product. I also have a YouTube channel, youtube.com/DanOlsen that has my talks, but also all the talks of the people from the meetup. So we have over 18,000 subscribers, a lot, one of the top product channels out there, what else? LinkedIn obviously, and then if you wanna check out, you know, my talks, I have a lot of talks that cover a lot of the material for my book. You can check it out, a lot of the frameworks that we talked about, also the book's available on Amazon. And yeah, I think those are the main ways. And as far as how I help people, the main thing I do these days is I do private training workshops, right? Incorporating teaching the lessons we talk today, actually sometimes, you know, depending on what they wanna do, each workshop is tailored. So if somebody says, "Hey, we want to actually work on our actual roadmaps," then we will actually work on their actual roadmaps during the workshop. But I always tailor it depending on what they want. But private training workshops, the other thing that's super exciting as product management has just exploded over the last few years, more and more companies are like hiring more PMs and they're starting to say, "Gosh, our PMs are so busy, we never get together to talk about how we do PM." And so more companies are doing their first ever kind of internal product conferences. So I'm excited, I get to speak at a lot of those. They bring in external speakers. So those are some opportunities where I could help people within their companies that that might be relevant.

  - I've watched a few of the videos from your Lean community. My favourite is where you had some of the founders or one of the founders from Tesla, you know, from the pre Elon days and kind of that first articulation of why they made it an electric vehicle over a hydrogen vehicle, et cetera. And all the research that went into that, I loved it.

  - Yeah, Marc Tarpenning is awesome. And you know, you just kind of figured, you know, whatever, as an external observer, you're like, okay, they just kind of said, let's go do an electric sports car. But no, you realise the amount of thought that went into it and the iteration that they did and how they came up with that. You know, they we're not gonna build a car from scratch, we're gonna take a Lotus and how do we MVP this thing, you know, versus having to build a car from scratch, having worked in automotive, I bet you could appreciate it more too, right? So that was super cool. And it's funny because people are like, "Yeah, Elon Musk was one of the original co-founders." Like no, he actually wasn't, it was Marc and this other person did it. So yeah, that's a really good talk. I enjoy that one too.

  - Dan, it's been awesome having you on the channel today. Looking forward to keeping in touch.

  - Yeah, Phil, thanks a lot, I had a lot of fun. Thank you very much.