Should you groom your strategy? | Nacho Bassino

In episode 34 of Talking Roadmaps, Nacho Bassino and Phi Hornby discuss the crucial role of strategic grooming in product management. He elaborates on connecting high-level strategies to actionable roadmaps and OKRs, emphasizing the importance of aligning strategic goals with execution. Nacho shares insights from his book "Product Direction" and offers practical advice on maintaining strategic alignment within product teams.

Nacho led product teams for over 15 years in different companies and industries, holding leadership positions such as CPO at Bestday, Director at XING, and Head of Product at Despegar.

As a coach and trainer, he created Product Management programs and classes in different institutes and universities. He participated in Marty Cagan's exclusive coach training program and was a mentor in various institutes (Endeavor, ProductLeague, Hero Camp). He currently offers courses, workshops, and coaching at productdirection.co.

In addition, he is the Regional Coordinator for Product Tank in Europe, writes articles, and publishes the 100 Product Strategies podcast. As an international speaker, he participated in the most recognized product conferences, such as MTPCon (San Francisco) and Product Management Festival (Zurich).

In 2021 he released Product Direction, a book about how to practically create product strategies and align their execution through strategic roadmaps and OKRs.

Many companies don’t do strategic grooming or build their Roadmap based on the strategy.
— Nacho Bassino

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 Rob Phaal, Director of Research at University of Cambridge. So watch out for Season 1 - Episode 35!

  • - Welcome to Talking Roadmaps, the channel where we talk about all the good, the bad, and the ugly of Roadmapping. Today, I am joined by Nacho Bassino. Nacho, introduce yourself.

    - Hey, I'm Nacho. I've been working as a product leader for many, many years. Now I'm in the transition phase into a coaching role, coaching consultant role, and last year I wrote a book called, "Product Direction," which talk about how you create strategy and connect it to Roadmaps and OKRs for execution. So really excited to be here today to actually explore that in a bit longer.

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

    - I mean, I actually use this in my book and the way I'm using it as a product leader nowadays is to connect the strategy to the actions. So to me, it's the intermediate piece that would say these high level strategic drivers that you want to connect, how they will actually be seen in reality. So you basically have these high level ideas that you want to pursue in your strategy, or high level, as I said, drivers. And then you will have quarterly execution and there is a gap in between that actually is your longer term-ish planning that you will try to fill with Roadmaps and that's basically how I'm using them today. So the connection between the strategy and the execution that you're having on a quarterly basis.

    - Love it, yeah, I love that. In my terminology, I might call that the operational gap thing 'cause you've got kind of the tactical execution level, you've got the kind of the strategic thing and kind of what are we doing operationally in the middle, maybe. So, interesting, and I think it reflects very similarly on when I was interviewed, we did a sketch note of it and the sketch note drew a bridge between strategy and execution. So I think, totally on the same page we did there. But you're talking about kind of on those quarterly objectives and kind of that bridge that between things. Who's looking at it? Who's the audience?

    - It's a good question and I think that one thing that I made maybe super simple or simplifying the answer is that the devil is in the details and the problem with Roadmaps is the flight level or the granularity level you use on them. So, maybe to expand a bit longer on that answer before jumping to the audience, what you are trying to do is to keep at the big strategic opportunities that you will plot on your Roadmap to explain in more detail how your strategy will be realised into the execution. What that means is that you don't need to go into the solution level, which may be some kind of how we gonna get gunshots. So just to use an extreme example, you want to keep these high level opportunities that are still saying, "This is my strategic driver." Strategic driver means that I need to cover this and this and this problem or this and this and this opportunity. This is the right sequence because this is how we first address one problem that will be on top of that one with the second problem. And on top of that one with third problem. And you are expressing this problems in terms of what you're trying to achieve. So, also needs to be reflective into, from your strategic drivers, you will drive these smaller goals that you're trying to achieve. So in that sense, I always say that the kind of the product leader is the one driving this conversation. And the audience is, of course, twofold. You have on one hand, your group of stakeholders, kind of peers from other departments in the company and things like that, that you need to align with. And this is a kind of very, very strong piece because on a strategy, I would say it's a bit easier to align because since you are talking about something a bit more high level, for sure, there were building trials and trade-offs, but people might interpret things a bit on their side, so to speak. So they may be agreeing on the strategy, but when you see the Roadmap, you are seeing the truth. So that's where kind of these conflicts might get into lower levels. So the trade-offs are more clear, you will have more discussions. So, it's a big piece of the alignment puzzle. And on the other hand, of course, so we're saying this is the connection to execution. So, it's a very big conversation started with the teams. And if you are doing this kind of, as I say, granularity level right, the conversations with the teams say, "Hey, these are the problems we are trying to solve and we need you to take this down a bit, kind of further down the road and break it down into what are the initiatives or potential solutions that we may pursue to achieve this potential problems. And do your discovery to understand if this is a relevant problem and how it's the best way to solve it." So, kind of these two side of the table are kind of showing together in the Roadmap conversation.

    - Okay, there's an interesting omission there. Customers, what's your perspective on customers and Roadmaps then?

    - A long part of my working life, I was in the consumer side and so, for example, travel. So, let's think about Expedia or Booking or you can think about, for example, Emsing, and in there, there is no much or we don't need to reveal our Roadmaps to the customers. On the B2B side, that can be different. But my take is that those are two different elements. So for sure, you are using, I mean, you want to base what you show to your customers to have a Roadmap, especially if you're trying to do sales on based on that, which is a tricky business. You are trying to display some information in a certain way that will make sense to your customers, which is quite different from this low level internal alignment that you need to have that I was saying before. For example, we'll have the business outcomes you're trying to achieve. And for sure that's not something you'll kind of be sharing with your customers. Maybe, this may be quite long, but in what I'm saying is, the Roadmap I'm talking about is the, what I call internal, let's call it, Internal Roadmap. And if you need an artefact to display to your customers, that will probably be quite different. And for sure, we'll use the same terminology or the same name, Roadmap. But I will argue that there's a different artefact with a different purpose and needs to be think about differently.

    - Yeah, I mean, I think I talk about them in different reviews of the same information. So it's the same Roadmap, but different views on it. Some for audience, some for an external audience, some for an internal audience. So, I guess that results in potentially different artefacts that are those different views. So then, who owns the Roadmap and maybe who maintains it as well?

    - I always feel, "Owns," is a very strong word like the product owner and then comes to the CEO of the product and those sort questions. So I don't really like to use that terminology, but to be fair, I think that what I usually say is that, the product leader is responsible to make sure that the Roadmap is out there, fulfilling its purpose, which doesn't necessarily mean that the product leader owns the Roadmap, but he has a responsibility to facilitate the conversation, to have the Roadmap standing up to date and aligned with everyone in there. One thing I didn't mention is that, the kind of the organisation can be very different in size and complexity. So, there may be different levels of leaders in there. So you may have have product managers and then we have a, you know, head of product or some sort of product leader, that we have a VP of product, and that can drive having different levels of Roadmaps. So, kind of whole company Roadmap or kind of business unit Roadmap or, you know, try Roadmap depending on the organisation. So, this will also mean that this different, so the Roadmaps hopefully will be aligned and will be kind of based on the same information, but you will have different views. That's what I said before, that will try to serve the purpose at different levels. So different product leaders may kind of owning that view of the Roadmap, which as I say is based on the same information, but the views are the ones that triggers conversation at different levels because, for example, the VP may be having a conversation about resource allocation on a business unit level of basis. And in the business unit, you may be arguing, you know, trade-off, trade offs or, you know, go to market strategies and then that will have a different view, different details than the high level one. So, based on that, my short answer was product leader, that is a bit more complex when you start to unpack it.

    - Now, if I remember, the book is very much broken down into three areas of strategy, Roadmap and OKRs are objectives. So how does a Roadmap link, kind of vision strategy objectives or how does it relate to them?

    - To me, one fundamental piece of work that is not usually done at many companies is what I call, strategic grooming. And why I call it strategic grooming. It's because I think it's quite or related to what we do when we do backlog grooming, which is a very well understood practise in which you get these bigger pieces that we're gonna say, "Hey, it's a high level epic, for example, and you break it down and you have kind of lower level APs and you have user stories and things like that." Why I call this step linking the strategy to the Roadmap strategic grooming, because I feel we have kind of a same type of mindset coming from these big strategic drivers that maybe, "Hey, I want to play or solve this new customer need or focus on this differentiation or target this new market, whatever." And that's what we need from a strategy, kind of high level direction, but then we say what we need to do in action to actually win that path that we are selecting. And that's where what I call a strategic grooming, which you're saying, okay, for example, one tool I use for that can be the, "Opportunity Solution Tree," by Teresa Torres, that I usually say, we are still, since we're having this discussion of opportunity level, we will stick in the opportunity space of this tree, but we will break down this high level opportunity into lower level opportunities. Another way to say it is with, for example, a user journey map saying, "Okay, if we are thinking about tackling this new market, let's map it out and let's see where are the pains and things that we need to address." And so, you again come from this high level, hey, we need to tackle this new market and say, "Okay, what's the journey for this market and what are the pain points?" And those pain points are your opportunities that can be going into the Roadmap. So that's kind of part one, how you link the strategy to the Roadmap. And then with those Roadmap items, how you link it back to OKS. One comment before jumping to that is that, of course, the Roadmap has different platform, so you're trying to create a Roadmap that will have you or will give you some strategic planning at a different horizons, can be 12 months, like three months. This company can be six months even. But you're trying to have this higher level view. When you're discussing OKRs, you are focusing in the first quarter, for sure, which in your Roadmap should have much more position than the quarters coming farther away. So, when you're doing this strategic grooming, you are focusing on this, let's say when you're doing the grooming, as when you do backlog grooming. For the opportunities you'll take in now, you will have a more level of detail, more granularity, you will kind of breaking them into more detail. And the ones that are further away, it's fine to, let's say, "Hey, I have this six month block with a pretty big opportunity that I have no idea, but it's kind of coming in 12 months so we can leave it in the Roadmap axis because I mean, it's no need to, yeah, do further down planning at this moment. Then when you go to OKRs, this is kind of what strikes me also as crazy is that most companies are having this super stressful period for two to four weeks in which they're doing OKR planning and it's super messy and they're trying collect information that signals a lack of strategy and the lacks of the connection of the strategy to the OKRs. So to me, it's quite simple when you have a Roadmap that you have said, "Hey, this is the opportunity I will tackle in the next three months and this is the driver I'm trying to achieve and this is the success criteria, which I will measure this opportunity." Then coming up with the OKR, it's quite easy, scaling, it's almost as translating as kind of grabbing the run of item and putting in the OKR. For sure, there are kind of more nuances like, for example, having different teams and different teams might collaborate on the same opportunity in the Roadmap. So, you need to do some kind of granularity there or fine tuning, but at the end of the day, it's kind of taking the opportunities you put in the Roadmap for the next quarter and translating them into the key results that each team need to hit. And as I said, should be less stressful than it's currently done in many companies.

    - Well, I think that's just 'cause OKRs are done quite badly in many companies, right? So, they're seen as a silver bullet to solve all problems when actually, you need the right culture behind it, as you just described, essentially. That was kind of a way of working, which kind of is a symptom of the culture that then leads to relatively straightforward OKRs and planning. But I think, you've kind of hinted at one other kind of related artefact as well to the Roadmap. Earlier, you talked about a Gantt chart, maybe a plan. Are there any other things that kinda link into a Roadmap or relate to a Roadmap?

    - Maybe making this jump from kind of Roadmap to execution. As I was saying before, you will start creating artefacts that will help you drill down your strategy into those opportunities. So, the Roadmap is an artefact, say, for communication, alignment, towards kind of the status sheet and what you're trying to execute. But when you are actually creating that Roadmap, and then later executing on that Roadmap, you will have artefacts that will make those breach happens. So, for example, as I said before, "Opportunity Solution Tree," or customer journey map can be tools that you will use from the status sheet to create a Roadmap and then later on to execute. Because, for example, going back to the opportunity solution tree example, if you're having your high level opportunity coming from the status sheet, you will break that down into lower level opportunities in the Roadmap. Then you will probably, because the teams will break that down into solutions. And actually, maybe I can make a brief note there because I mentioned it before. But for sure, in all these stages coming from the strategy down to the OKRs and down to the team execution, you will have this connection between a top down, what we are trying to achieve and bottom up, what we are seeing in the market and the users and our results that will inform that. So you'll have these discussions that will have have other Roadmap level. As I said before, when we discussing the audience, when you kind of discuss with the Roadmap is not something that the product leader will sit down a room and create and then hand over something that, as I was saying, we are facilitating that work, which requires a big connection to the teams. So maybe, why I'm saying that is because when you're thinking about the tools that the teams will use, for sure, I would say, "Hey, the logical connection is, let's connect the Roadmap to the backlog." But those, again, are the high level artefacts. If you see the, let's call it the artefacts or maybe the tools that happen in between to make those connections, you have tonnes of things. So, maybe going to other examples just to complete the picture when you're thinking about, how I connect the Roadmap to the OKRs, you will probably have KPI tree. And KPI tree is something I suggest the teams are using because that informs opportunities that they may find by exploring some KPIs and seeing, okay, how is this KPI performing at a lower level? And then you can have this, I mean, not only the tree, but you can have this slice and dice and say, "Okay, yes, for this, I know traffic channel, we are having this performance or for this user segment, we have this performance." So you start having your levels and you kind of slice and die levels. So I'm not sure if you're asking for that, but maybe yes, there are some other tools that will help this support from these different tools that you will use from as maybe using your terminology from operational to tactical. There are many things there that will help you make those translations.

    - Sure. I mean, I love that actually in that show that unpacking of, I guess, it's that kind of old Dwight Eisenhower phrase of a plan is useless, but planning is invaluable. And the different activities that you go through to. To actually synthesise and understand the challenges that have been set, the problems that are out there, the opportunities that are there to then be able to build back up to a Roadmap and set the measures of success. I think, actually, that's a really sort of powerful way of expressing it that we've got a lot of tools in our tool bag to do that.

    - Actually, one thing that maybe we didn't talk about, but when I think about, we think about the Roadmap, you see this is the timeline and kind of boxes with titles. But to me, what's quite interesting is something that happens sort of behind the scenes, which is you are creating your opportunity space and from your opportunity space, you selecting opportunities that you will see reflecting on the Roadmap. But each of those opportunities is not a title, is opportunity described somehow. So that's one. I mean, I don't want to go into templates or fill in the blanks exercise, but I usually say, "Hey, we need to have an opportunity card." That's what we call it. In which it's the same as having instead a Roadmap title, a Roadmap card, which any tool will give you that. And you start describing that opportunity. And, I mean, part of this connection from one to the other is that, okay, we start with some opportunity that is kind of a hypothesis, a problem identified, a trend identified, and we start doing some discovery and we start doing some data analysis and we will gather more information for an opportunity card. And that's big chunk of the work and it's not actually plot in the Roadmap to work, the work is actually coming up with the insights for the opportunities to make sure that you are going in the right direction. So, coming up with more evidence that can be either through discovery experiments or through gathering more information like secondary research or analysing your own data. So this opportunity card, I think that's also something that we tend to skip and it's probably, I mean, when we think about the Roadmap, thinking about the item, not a single title, but this kind of very well informed opportunity, that's something also some companies tend to ignore and it's a kind of a big loss from this connection of different stages.

    - Yeah, I mean, too often there's one line, like three words on the Roadmap and then everyone assumes it means something different. So I love that kind of breaking it down into more detail so it's clear what we actually mean by this thing. I mean, just to pick up a thought there though, you said that all of this is before it goes on the Roadmap. What about capturing your discovery, the things where you're actually figuring out which opportunities are right on the Roadmap as well?

    - Yeah, that's where I say that this opportunity space kind of lives in the background because if you think about it, what you are trying to do all the time is, or the role of the product management is make sure that what we're building is valuable and valuable and this is basically choosing the right opportunities to build. So, this opportunity space lives in the background of everything you're doing. If you are thinking about the strategy, you say, "Hey, we are having this opportunity space and we are betting, and, of course, hopefully this bet is important, but we are seeing this opportunity space." And we're saying, "Hey, these are the biggest chunks, this is how we can differentiate, this is how we can make a sustainable business in the future." So we are having this level of selection level when you're going to Roadmap and say, "Hey, we have this opportunity space and we choose this path." So say, "Hey, we will pick these opportunities that we are thinking of the most valuable to plot in our Roadmap." When you're doing discovery, you say, "Hey, I have this big level opportunity or even I already have an opportunity space, some lower level opportunities that will try to validate for implementation." Or if I don't know much about this opportunity, I will do some research that will create this lower level opportunities. So, all the time, you have this opportunity space behind the scenes that it's informing these different levels of artefacts. And basically the moment in which you are building this opportunity space is when you're doing discovery because, again, at different stages, because we might be more on exploratory research or understanding the problem versus validating solutions. So this will have different levels of information for your opportunity space. But at the end of the day, when you are doing discovery, you are adding more pieces to the puzzle. And if you think about, I mean, we'll say that product is not linear and we have this tendency to say, "Hey, do attract." Or this terminology say, "Hey, discovery and then delivery." But if you think about discovery, discovery is happening all the time and it happen at different levels. So when, for example, many companies when they are doing a strategy, I will say, "Hey, you cannot expect to go to a strategy workshop, today's offsite, and then come up with a strategy." Because what you will identify during that workshop is that you need much more information to site and then come what may be called a discovery for the strategy, which is kind of finding this secondary research, informing some opportunities, even running some experiments to validate high level hypothesis. So, this discovery phase that we usually think about, okay, let's come up with kind of from a problem to validate solution. We also are doing it at different levels and we'll keep informing this behind the scenes opportunities space that you're building.

    - Yeah, I mean, the way I often think about it is, the things towards the right on my Roadmap are probably in discovery right now, whereas the things towards the left are probably in delivery 'cause I'm figuring it out to get ready to deliver it later.

    - But I think that's something that is not quite solved in how we operationalize this into kind of execution. Because if you think about it, you also have teams that are focused on the opportunities you are kind of trying to solve now. So, what you need to make sure is, how am I or who is running the discovery for those opportunities that are coming along the way? And that's the thing that's a tricky balance that the teams need to kind of keep evolving. Say, "Hey, I'm not a hundred percent focused on the opportunity. I kind of doing delivery in the next months. I also need to think about my longer term." And actually that's something that the Roadmaps may help us.

    - Otherwise, you end up in a feast on famine position. It's like, "All right, I'm doing tonnes of this delivery now and now tonnes of discovery." And alternating as opposed to that nice clean dual track, which obviously has its tension between it. What are the key elements that we put on our Roadmap? You know, what's on there? You've mentioned timeline, but what else is on there?

    - I also do solution tree, so we have the timeline, we have the swim lines and we have the items. So that's maybe pretty obvious. So maybe going back to some topics I discussed in the book. In terms of the timeline, that's also interesting because it has evolved from kind of this very structured more Gantt chart monthly Roadmaps. We went kind of to the other extreme to the now next future Roadmap. And there are things in between. I usually tend to like the one that is kind of expanding timelines. So you have next quarter, then next semester, then next year. And this also gives the level of uncertainty you're having about the things that the items you're putting in that Roadmap. But that's something that is interesting and then quite interesting also on the streamlines, you can have kind of all sorts of things there. I usually try to push for strategic drivers as kind of our things that we're put in as soon so. Everything we are doing to hit this, for example, this new market that we are trying to address or this lead that we're trying to address, will put in the same streamline that will also be tied to a strategic goal. So you will have a very nice mapping and this is also going back to the lineman, who is the audience. You will explain very clearly, "Okay, if we are trying to achieve this goal, these are the things we need to do and this is all the things that we've selected to do in order to achieve this goal." But also, to be frank, I have seen this also kind of breakdown by teams, business unit, or group of teams. I think that's also a very common way of doing it and it's a bit more easy on the lower funnel. So trying to explain the teams, what actually we're expecting from them, that's nice way to play it out. And finally on the items, we already discussed that, but it's kind of this title, I usually also say, "Hey, the title should be written as an opportunity turn to test." So not a solution. I'm not super dogmatic about it, but just kind of giving the right mindset and trying to address what you are trying to achieve with this opportunity. So it can be as easy as adding the curiosity that you're trying to hit with that opportunity. I always try to attest for that. But then if you have, for example, a Roadmapping tool or even if you don't have a mapping tool, even if you're using, hey, let's say, "I have my Excel and then I have Jira, but then on Jira, you'll have something titled with the same title in which you will have a much longer explanation of what you're trying to achieve." Just because of what you said, kind of in terms of this alignment we are trying to build, avoid having everyone interpreting something different about this kind of title that you have in there.

    - Now I wonder that. Kind of different use of swimlanes that you had there. Do they better suit different audiences? For example, the strategic drivers, does that suit more the execs versus the teams, et cetera, that suit more the execution of development team? Just a hypothesis there.

    - I think they fulfil different purposes and I have seen it maybe aligned to the culture or what the audience is trying to see because I have seen many executives interested in, okay, what are the teams doing? Not in terms of micromanagement, but trying to figure out, "Okay, this is this investment we're doing, what actually are they focusing on?" Which is a good discussion also, if you keep it at opportunity level, it's a good discussion. And you are having, so these executives will also prefer the swimlines divided by this sort of teams team level or group of teams level. Instead, if you are saying, "Hey, we need to discuss." For example, in the early strategic discussions, when you are going from your initial strategy to, "Okay, now that we agree on the strategy, we're trying to show what are the focus areas, that's where everyone will benefit from a strategic driver discussion." Because even the teams need to align, okay, what's actually we're trying to do to achieve those opportunities. And also, the executives will actually like to see, "Okay, how you're trying to break these drivers down into opportunities you want to pursue." So I think that they will, different audiences necessarily, but different moments or different things that you are trying to look into that may inform what you need to show. And actually, I mean, going back to the tools, and I'm trying to promote any tool by the way, but if you have a tool behind the scenes, you will be able to switch these views and use them them properly whenever you need them. So that's also a benefit.

    - So that's actually my preference for why I would have a tool. It's a single source of truth but I can get my different views out of it without having to work hard. But you said you don't wanna promote a particular, I was about to ask you, do you have a preferred tool?

    - No, I don't. I don't. So I have used, I'm not sure if it's--

    - Okay.

    - To say names, but I use Aha! I use Productboard, I use ProdPad. Those are three I used so far. I don't have a preference. I think that, I mean, if you are looking into the specific purpose of displaying a Roadmap, probably all of them will give you what you need, depends on the complexity of the organisation and also how you're using them to connect them later to execution to other tools like Jira, things like that will get into more the selection of tool part of things.

    - Totally agree. I mean, and yeah, I'm relatively tool agnostic as well. My co-host is ex of Aha! But he also play around with all the different tools and Jana was one of the first people on the channel, so, ProdPad also. A friend of the channel and one of the previous practitioners we had on was a big fan of Productboard. So, you know, we like to expose people to what's out there. And I think you're right, there are many tools and different ones will fit different organisations based on the rest of their tool set up. But also, as you talked about earlier, their culture and the way they use Roadmaps and how they want us to see things. You know, some tools only do Gantt chart styles. Some do those kind of time boxed or timeframe oriented ones and don't do anything else and some do whatever you want. So, it's all about what you're trying to achieve and how you want to present it, I guess.

    - What I will say is that, so every time I use these tools, I went from no tool to a tool and everyone appreciated it. So that's I just wanna say, so as I was saying, not trying to promote digital tool and to be honest, I mean, if you are, for example, in a startup, I'm not sure if this is appropriate, but you may not even need a Roadmap. So, you can easily jump from strategy, short term strategy because you're a startup, you're trying to find a market fit. So, kind of jump from, "Okay, this is the direction we're going to, to the OKRs." But I work in enterprises with kind of complex organisations and trying to, as you said, organise the information. Either it's a very big and painful effort or just because of the effort, no one does it, and the stakeholders has no view. So whenever we introduce these tools, it's usually appreciated by both sides of the table.

    - I was going through that journey as I left my last corporate role introducing it to the team for those exact efficiencies and just saving our sanity of 15 different copies in PowerPoint that were all not quite the same. You've probably already told me this a bit already, but what do you consider to be best practise when it comes to roadmapping?

    - Yeah, so I am trying to see if I will repeat myself too much, but essentially is having this Roadmap that is at the opportunity level, focus on the outcomes you're trying to achieve and that will be a breakdown of your strategy into more kind of, I'm not saying granular level opportunities, but more concrete opportunities and problems you're trying to solve to address or to fulfil that path that you are selecting on your strategy. So to me, that's the standard I'm trying to push and as I said before, also being conscious of your context. And again, if you are needing a Roadmap to discuss the breakdown strategy, then maybe, for example, the swimlanes can be strategy driven. If you are in a kind of super short-term fine market fit startup, then maybe you can say, "Hey, the Roadmap will postpone it until we have these more stable things to discuss." Because at the end of the day, the Roadmap is trying to, we're saying in the beginning, align you in terms of the things you're trying to achieve with different piece of organisation. And if you don't have something to align on yet, then it doesn't make much sense to do the effort.

    - Yeah, although the interesting thing I've come across is that investors can often like having a Roadmap so they can see where their money is going. So sometimes, there's another reason for having one even in that startup context.

    - Yeah, the problem is that, I mean, we'll get into this kind of more tricky part is, if you are doing this just for kind of showing something up, probably, it lacks the backing you need when you have a roadmap that is based on solid strategy just because you, I mean, you're running yet, so that's kind of fine to acknowledge and at the end of the day, this Roadmap will, we all know will change a lot. So, I mean, if you need to do exercise, do the exercise, but my suggestion would be, don't invest heavily on it because at the end of the day, it will change. And then if something that, you know you are doing it for kind of this check mark of, "Yes, I show my Roadmap." But then, do not be so restrictive on your execution based on a Roadmap that you know is not super well. Yeah, solid on facts.

    - Okay, so we've got best practise. What about the biggest mistakes or anti-patterns that you see on a Roadmap?

    - Super obvious by going to solutions and the tricky part is that we can easily channel into solutions either kind of from a problem perspective or stakeholders pushing you to, "Okay, what's actually in there?" So, it's easy to fall into that pressure, the bias and summarising solutions. And the second one is, as I was saying, to me, the part of the puzzle that is missing in many companies is, playing this strategic grooming, call it however you want, but actually building your Roadmap based on the strategy. And that's, I mean, since many companies don't even have a strategy, another problem is, "Hey, I'm trying to invent a Roadmap, seeing the opportunities I have kind of here and there just kind of pulling from all places." And that's something you want to avoid. If you are finding yourself in that spot, stop doing the Roadmap, go to the strategy and then come back and build a Roadmap that it's aligned with the strategy.

    - I mean, like obviously, you talked about anti-practices, bad mistakes, but is there one thing you really, really hate and a pet hit on a Roadmap?

    - I hate months or any sort of date. So I actually say, kind of first quarter, I think it's fine. But then, when you see the these months, it's I something I hate. And then maybe also another problem is when we are trying to give it on opportunity level, and this is not hate, but just to give another example that things that I don't like to see. When you give it an opportunity level, but it's not tied to what actually you're trying to achieve. So, kind of having this outcome in mind. So I would say, opportunity level, but also outcome oriented because it can be auto-curated but with solutions, it's not good. Opportunity level without outcomes, not good as well. So, need to make sure that you're having, at the opportunity level, but clearly reflecting the outcome you're trying to achieve because if not, again, the execution will kind of disconnect from that outcome.

    - We've heard lots of advice from yourself. Whose advice do you listen to on Roadmapping?

    - Yeah, and I would say that I have many, many peers over the last years in which I kind of debated Roadmaps and we came to these conclusions and then, yes, probably thought leaders and you can go from Marticanon, saying kind of conversion opinions for Roadmaps, all the way back to kind of the, you know, the out firsts of the book of Roadmaps or launch, which is a very nice read. And Shanna Basto, for example. And also, I guess that she has been talking a lot about that. So that's how I kind of form my own opinions as I'm saying. Then in the practise, I kind of solidify the concept I put in the book.

    - Your book is a great resource for them to all have, but are there any other resources that you would recommend people to check out around Roadmapping?

    - Yeah, so I was saying, probably, "Roadmaps For Lunch," and I hope I'm saying the same very name. It's also a great source 'cause examples and it's a very, very easy read, kind of easy to grasp. And then I will recommend all of these tools that we were discussing, like Aha! And all of them will have these very interesting blocks in which they explain some of these practises. So those are also nice and they have webinars and whatnot. So this is also a good source of information if you're trying to, maybe that's what we say is, going more into the details of how to build a Roadmap. That's where probably it's a good resource to follow.

    - If you had to distil your philosophy on Roadmapping down to one or two sentences.

    - The Roadmap is an alignment tool that must be based on your strategy.

    - Is there anything I should have asked you about Roadmapping that I haven't?

    - No. To me, we covered the most important part, so I will just say it one more time to this strategic grooming. So it's all about, I mean, how you, considering that you created a strategy sheet, how you distil it into a Roadmap, kind of digesting those strategic drivers into more concrete opportunities. And why I'm saying this because, whenever I go into a company and try to, I mean, I kind of coaching and consulting about the strategy, I usually see that this is a kind of a missing piece. And they're having either with Roadmaps that as I said, are all over the place or they are missing this way to dissect the strategy into the computer opportunities.

    - In fact, I've started asking an extra question at the end recently. What's your biggest Roadmapping nightmare? What's gone wrong or the worst thing you've ever put on a Roadmap?

    - Probably will give you a very repeated answer, but I started with my gunshots as a Roadmaps, right? So in my early days as a PM, I will have this monthly thing and kind of to be honest, I mean, I started in product management 15 years ago, which it was much more project management on steroids than it is today. So I did this project management, actually I even did, I don't want to admit it to Lovely, but I did it in my PM, project management courses, back in the day. PMO, whatever is what it's called.

    - Me too.

    - Yeah, exactly. Many of us on there from the early days. So, yeah, so to me, that the worst mistake was kind of having this solution oriented, data driven product.

    - So naturally, it's been wonderful having you on the channel today. Natural. Last few minutes, give us the pitch for yourself, how people can get in touch, how you can help them.

    - Yeah, so I'm all about strategy as you know. So the first thing I would say is that I have a podcast as well, if you like to consume this type of content, it's called, "100 Product Strategies." You can find it in Spotify or Apple. I have my book up there, which we just discussed and you can also find a lot more of content and even workshops and what I do in coaching and consulting at productdirection.co. There, you can also subscribe for a newsletter like, yeah, I send content regularly. So, yeah, that's probably the best way to find me. Also, you can reach out in LinkedIn.

    - Thanks, Nacho, it's been great talking today. Some great insights.

    - Really appreciate it, thank you.

Phil Hornby

Co-host of Talking Roadmaps

Passionate product professional. Helping entrepreneurial product teams to be successful. Coach. Trainer. Facilitator.

https://www.linkedin.com/in/philhornby/
Previous
Previous

What do Hardware and Software Roadmaps have in common? | Rob Phaal

Next
Next

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