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

In episode 35 of Talking Roadmaps, Phil Hornby interviews Dr. Rob Phaal from the University of Cambridge. They delve into the commonalities between hardware and software roadmaps, discussing the importance of strategic technology management, the role of visual methods in innovation, and the practical applications of roadmapping in various sectors. Rob shares insights from his extensive experience in mechanical engineering and industrial consulting, emphasizing the evolution and efficiency of roadmapping tools.

Rob is a Director of Research in the Department of Engineering at the University of Cambridge, where he conducts research in strategic technology and innovation management. Interests focus on industrial emergence and the development of practical management tools and visual methods for supporting technology intensive innovation.

A particular focus over the past 20 years has been the roadmapping approach, exploring the generalisation and efficient application of this and related techniques in many sectors and contexts. Rob has a mechanical engineering background, with a PhD in computational mechanics, and industrial experience in technical consulting, contract research and software development.

“Some of the best roadmaps are on the wall all the time where people naturally gravitate when they have a strategic discussion”

— Rob Phaal

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

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

Phil Hornby and Rob Phaal

In the next episode we are talking to Itamar Gilad, Author and Product Management Coach So watch out for Season 1 - Episode 36!

• Transcript

  - [Phil] Welcome to Talking Roadmaps. The channel where we talk about everything roadmapping. The good, the bad, and the ugly. Today, I'm joined by Rob Phaal. Rob, can you introduce yourself.

  - I'm Rob Phaal. For the last 25 years I've been working at the University of Cambridge in the Department of Engineering. With an interest in management tools. From an engineering perspective, working mostly with technology-intensive companies and roadmapping is a particular tool of interest.

  - Yeah, and I know I've come across your courses and your books. So it's interesting to find a different school of thought. Different perspective to kind of share with our audience. If you're enjoying the channel, subscribe. Hit the bell, and give us a like. What's the purpose of a roadmap?

  - Well, in one word, alignment around strategy, really. The way I like to think of it now as an analogy is it's the picture on the jigsaw puzzle box, you know. So everyone's got a piece of the jigsaw and they all know their piece well. Maybe not be aware of other pieces. They probably overinflate the size of their piece. But it's pretty hard to put the jigsaw puzzle together if you don't have that picture on the box. And that's really its role. So alignment of all stakeholders around your strategic purpose. So they can understand how their contribution fits into the whole.

  - So if we're aligning people. Who's the audience that's looking at, then? Who are we aligning?

  - Well, that's a really important issue. Because I think often if there's confusion about the purpose of a particular roadmap. It starts to get muddied. Because one master roadmap, the complete picture, if you like will have many different audiences. But they'll be emphasising different aspects. So for example, the roadmaps I most commonly work with come in manufacturing sector. And they're pretty complex, because you have to be organised around that complex engineered product. To develop the strategy but also to implement it. But I've seen many failures where that roadmap is taken to the board, you know. It's the wrong format, you know. They wanna show the big picture and show them the money, for example. So you need to think very carefully of all the stakeholders involved. But then what is the purpose and the audience for a particular roadmap visual? It could be for suppliers. It could be for the technical community, product managers, marketing. The way I think of that often, is it's a bit like design for X, but the X is before the word roadmap. So if it's a technology roadmap the focus is technology in the wider system. If it's a product, the same, could be supply chain or whatever. And it's very flexible technique but you need to be pretty clear about that. Otherwise you'll tend to have a sort of a vanilla roadmap that doesn't quite meet anyone's needs.

  - Totally agree. Yeah, it's so true. And you know, it's interesting hearing very much the same thoughts as I hear from product management people coming from this other community there. So it's, maybe we've all come to the same point through different paths.

  - I'm sure. The origins of roadmapping go way back. Actually to the the earliest ones we've spotted are from the 1960s. Lockheed Martin, NASA. Basically very complex engineered products such as aerospace, semiconductors, energy systems. And it was originally focused on the product but such complex technologies that they would've a heavy emphasis on both product and technology. In Agile software, because moving so fast often roadmaps focus really on the product and the feature set. And then people, the commercial or the technical people will be able to take that away and work on their parts. But in the manufacturing world, often they combine all of those components into one holistic view of the whole strategy. And so I think the general needs are the same, but what you see in hardware environments is often a much more complex picture than you would typically see in a Agile software system. So the architecture that is embedded in the product is visible in the roadmap. I haven't really seen that in Agile. They're looking at the really, the outputs, if you like. You know, what you can promise to the customers. And that's fine, that's the prime integrator. Everyone can take that away. But I've never seen really, apart from Enterprise architecture, maybe applications. These very complex systems, lots of legacy issues. There you see much more explicit architecture in the roadmap structures. So that's perhaps the key difference. But in the end, everyone's trying to get alignment around a strategic purpose.

  - And yeah, I think you started hinting at some of the visuals that I've seen in some of your literature. Of kind of, almost three swim lanes, three layers of those different audience. Of technology, product and service and business and markets. Can you maybe tell me a bit more about that?

  - Yeah, so one of the puzzles we had when we spotted roadmapping in industry, was we thought there's a lot more power in the technique. And what we could do is look at that variety and find new applications. And through that, we've established what we think is the generic form, a universal framework. And that does have three broad perspectives, often represented as layers. And so the focal system is in the middle but typically above that, you'd have the demand side on the system. And below that, the supply side. And that's really handy if you want to really integrate your entire business. From your resources to your end purpose. The product is a stepping stone. But why is it important and how are you gonna develop that? That's typically what you see, in that we always relate those three level layers to knowledge types. Why, at the top, why do we need to act? What's driving us, what's motivating us? What do you seek as outputs? What is the product and service their functionality, performance features? And then, how is technology, often different disciplines and then, are there resources? And then, set against that, is when? The timeline. So four of the six fundamental members of knowledge are baked into the structure of those roadmaps. The other two questions are the 'who' and the 'where', are not as explicitly represented. But absolutely critical because, you know in the end, the roadmap has to have ownership. The different layers and perspectives linked to different functions in the business. The objects on the roadmap need ownership, you know. Who's managing that project, who's responsible. The whole roadmap, by the way, is you need ownership from the very top. And the most interesting objects on the roadmaps which aren't that visual, often are the connections and linkages and dependencies. I remember Motorola was very influential in the 1980s and 90s, in roadmapping. They did have some software, and they, I was talking to somebody in the Chicago research labs. And they said that if I was in managing a technology programme and I wanted to link to a product development programme I would try to create the link in the software. But the link can't be made, until the other side accepts that we have a dependency. And then I know who to call, you know. So the best way to think of a roadmap is not as a data artefact but as a social contract, if you like. The common aspirations and commitments. And some of those links can be social contracts or real contracts to suppliers and so on. And so I think that the most important layer the social perspective on roadmapping is the most critical one. And often people don't see it 'cause they just see the object, the artefact produced. And then they file it away. They need to actively use it all the time and to, you know support conversations and insights amongst the stakeholders that those objects represent.

  - And so, that kind of contract the almost kind of ecosystem between the different kind of elements on the roadmap that give inputs and outputs to each other. Love it. And you started to hint at ownership. So you said ownership at the top. Is there different ownership at some of those different layers, different levels? You know, who owns this thing? Who, kind of maintains it?

  - Well the, often in any substantial initiatives somebody will be delegated with the operational aspects of maintaining it, running around. That's a delegated responsibility. That person normally doesn't own the content of the roadmap. But it does need some care and attention to get the process working. But in terms of the, what the roadmap represents then the ownership goes straight to people with responsibilities, and where budgets lie. And if you don't get that, it's just an interesting thing to look at. But when you get those people's fingerprints on it and they're committed to those actions that are represented on the roadmap, then you have something's phenomenally powerful. Some of the best ones I've seen don't look great but they're on the wall all the time. Very confidential, of course. And so, if you get to the point where people naturally gravitate to that visual object, when they have a strategic discussion. Then you're really flying, I think. And that's what you'd see in a scrum or in the sort of manufacturing. There's something I've seen in Scandinavia called lean innovation. Which is pretty much the same. Came out of factories though. You know, and if you go into a factory you'll see visual management boards. The principle is, if you can't see it, you can't manage it. And I've seen people take those principles out into the programme management. Basically product and management area and they'll have a room dedicated to having these conversations on different clock speeds. And maybe the roadmap will be pulled out every month or two, if you like. And they're just focusing on those conversations. They don't really- When I've seen one operate in Stockholm, they were really anti having any complex technology in that room. And software in particular. They were really worried that it would suppress the conversations. So they had whiteboards post-it notes, magnets. Then they did have a couple of bits of sophisticated technology in the room. They had an atomic clock on the wall because they were very disciplined, about time. And they had a high definition video conferencing system to connect up to other sites around the world. Which was about 50,000 people. So a very simple visual management room, can scale. And I'd like to see more of that kind of approach. There's a great tendency to get it in the software and it's a bit 'out of sight, out of mind'. People might type and not talk, and that's kind of heading in a suboptimal direction, I think.

  - Yeah. Funnily enough, I was talking to a senior product person I coached, the other day and suggesting that they create a design wall. And of all the different design artefacts and kind of, things like user journeys, and so on. And kind of get it physically on the wall. Because sadly, if it's, I love tools like Mural. I can't just walk past them, and kind of let that information soak in, and kind of almost be informed by just being in its presence.

  - Interestingly, since I've seen those systems operate at scale, and very effectively. I've always mentioned it to people as a potential route for deployment. And usually the response is, 'we don't have any space'. So I always say, well, you know, is your strategy worth less than paint. Because you seem to have a lot of walls. But it's meeting rooms, right? They're always under huge demand. I think in the future, you know touch screens and displays are getting cheap enough that you'll get to turn on your digital walls in your meeting room. And then have it as a multipurpose and that'll solve that problem. Because even things like Mural, you could have a massive screen, and still get the social interaction around it, rather than paper. A system which is pretty crude. On the other hand, there's no learning curve. Everyone knows how to use post-it notes. And the worst that can happen is a post-it note falls on the floor. In fact, this system I saw. It's called a pulse room, it's every week. they had a perspex box in the middle. 'Cause it was on the main route into their programme office. And post-it notes would fall down and they'd pop it in the perspex box and sort it back out every time.

  - Yeah, so I'm always using stickies to kind of think, even just on my own here. And I mean I have a large whiteboard in my own home office because that analogue just works. But yeah, it's an interesting thing, of kind of maybe in the future, having that digital sharing of in the physical environment.

  - I mean it's remarkable technology, post-it notes for having conversations. You know, if you empower people to contribute to ideas with post-it notes, in a liked process. Organising the conversation around a structured template it's amazing how effective it can be. And quite often people have reported that there's a lot of conflict in these conversations, inherently. Sort of, information asymmetries that cause conflict. And you're always having conversations across these boundaries in these workshops and processes. But I've never really seen conflict because it's purely a communication problem that manifests as conflict. And people don't want to. You get technical groups and product groups not talking to each other or they have separate roadmaps, you know. The 'why, what, how' integrated views bringing it all together. And that has to be owned by the person who's responsible for that part of the business. And they have the power to mediate those conversations and get people in the room. And if they have a good experience I find then, the appetite is massive, you know, to continue. It builds trust and mutual understanding and appreciation of the other perspectives.

  - And I think of the root, in part of what you said. That there is an understanding that conflict doesn't have to be a negative thing in reality. So you're not seeing the conflict 'cause you're seeing the discussion that gets to good outcomes. And that's, I guess you could term it as positive conflict. It's disagreeing to get good, to get somewhere. As opposed to fighting between people.

  - Yeah, there's always trade offs and compromises but that needs to be had in an adult sort of conversation. And which is really facilitated by these techniques. So you don't often get sucked down different rabbit holes. You know, everyone's in their own, because they have an important perspective. And these techniques can help them have equal airtime, if you like. Without personalities dominating conversation in my experience.

  - So we've talked about it being owned by some fairly senior people. 'Cause they own the budgets, this sort of thing. That suggests it might have a link into things like vision and strategy and objectives. How do we relate these things together?

  - Absolutely. I mean it depends on what part of the system you're focusing on, on the roadmap. So whatever the boundaries of that initiative is, that's the whole system you're looking at. It'll have dependencies out to other systems and so on. But it's a very scalable technique. So for any roadmap, at any level in the organisation. Could be a corporate roadmap or sector level roadmap at the top. business unit, product family, down to components and so on. Each one will have its own vision. And that's a problem I see in many firms. The company has a vision, but people can't relate to their perspective. The systems' thinking behind roadmapping allows the high level vision to be constructed. So if I'm in charge of, say materials technology. What's the materials technology vision? It must be a sub-component of the corporate vision. But that's often not well articulated and the roadmapping helps that organisation of information. So the right hand side of the roadmap, the direction of travel is a fundamental building block. Because without that it's all, well how do you know what you're doing today makes sense without some anchor point in the future. Are we heading in the right rough direction? And that's really the purpose of the vision I think, is direction setting. It may be aspirational. It's beyond the timeframe of the roadmap, often. Maybe like zero carbon, might be a good vision. But in the timeframe of the roadmap, say in five or 10 years, maybe you can reduce carbon by 50%. That would be the objective. So that pair of data points on the right hand side I always think of as the key to the strategy. Because as soon as you get those nailed down it becomes a more convergent process. You know, so in workshops which may have two hours for a group to develop a roadmap. They may take half the time to establish that multifunctional group. And then I would always relax, because then they can just fill in all the bits and get there. So the right hand side, it's system thinking I guess you need to know the initial and final conditions. But we always start on the right unless it's very incremental. And then with that right hand side, and down a bit. At the various layers and perspectives then you can say, well where are we now? And how good is it? You know, strengths and weaknesses with relation to that vision. And then the core components of the roadmap is the pathway. Which may have branches and so on, that connects today to that vision. So those two boundary points in time, more fundamental. I mean, time is an interesting thing. You pick up a strategy book and you find time in it. It's really odd, that it's got fundamental dimension but most strategy models are static. Roadmapping has inherently got time. It brings time to the party. And things like swot, most widely used and abused strategy tool. Where's the time dimension? Well, it's implicit. When you look at another tool like that overlaid on the roadmap structure. It becomes very clear that the response time in the system your ability to respond to signals is delayed. If you've got a product in the warehouse it might be a day. If you've gotta develop a new graphene battery it'll be 15 years, right. The slope of the line. And, and Swot has basically got a slope because it's current strengths and weaknesses, with some understanding of your ability to respond to an external threat or opportunity.

  - Love it. Yeah, so I've always kind of if anything's in a paste or a swot I typically add on an extra layer of immediacy. When is it and impact that sort of thing. But yeah, I love that kind of concept of the timeliness. I've not phrased it that way.

  - That's how you can add time to all other tools and frameworks. In my experience, is that you insert the components of that tool or framework into the structure of the roadmap, time. So the two benefits of that is you get the dynamic nature. So it's swot over time. And then also the broader system context. So most other tools focus on particular part of the system. Like if you've got a competitive issue, you know portals 5 forces as a tool, that's one layer of this holistic roadmap. And yeah, I've never seen any incompatibility with any other tool. In fact, the function roadmapping contributes to a toolkit is the knowledge integrator. Because it's designed to be very holistic. It's got the whole system including the supply and demand side. it's got all the time, even the past. Very good learning tool. Every other tool focuses on removing question marks from that roadmap. In fact, the first iteration I always say, you know, is an Agile approach. Really a trade fast learning process. You'll learn very quickly what you know and what you don't know. If somebody comes into, shows you a nice glossy strategy document. Get a pair of scissors, cut it up, stick it on the roadmap and you'll find all the holes. So it's that, it's quite a dumb tool, you know it's not analytically powerful, but it's very good at communication as a visual method. And superb at integration of knowledge because it's got the systems thinking behind it. And that's the function it brings. But no other tool can do the integration because there's no other tool that just has those dimensions.

  - I knew there was a good reason we were talking, Rob. That's like a, that's gold dust. So we've kind of talked about some elements of it. Some kind of content, some visuals. But maybe you can unpack that a little bit more. What's visually, what are we looking at on a roadmap?

  - Well, the most common practise is generally poor. Actually you know, as a visual tool it's surprising that people often fail at that very last hurdle. They may have great content, but the human brain is really a visual processing system, right. And it really struggles to see through a bad visual to the good content and structure. And many people who create roadmaps don't even have any basic training on visual design. And you don't need much. But I think everyone should up-skill a little bit because when you look at visuals it's pretty poor on average. From a visual perspective, I think the way to approach it. The sort of multi-layered, time-based view is not a very exciting visual. But it's very organised for information and it's very suitable for developing strategy and implementing strategy. So communities, say technical communities, programme managers really like that format. And even those ones can be made pretty and readable because if it's an ugly object, people won't engage with it. So it'll be well organised and a sort of interesting visual. But then what people usually forget to do is to say, well, people outside of that community they need a more communication oriented roadmap. You know, the absolute critical messages. That take all the noise and detail out. It's really around the core pathway and the motivation. And so I think I would always encourage roadmaps and pairs of visuals, at least. One is the detail, which serves those communities needs. But then start thinking about well look at the outside stakeholders. Say, the board needs a roadmap. So you'd use all the detail from the structured roadmap. And then create a visual that's tailored for that community. It may depend on the very individuals or that if it's a finance director they wanna see the money emphasised. So that extra step is often not done. And I've seen great roadmaps fail at that point. So I just say whenever you're communicating outward to different stakeholders, you need to think carefully about the visual form. And it may not be a visual even, maybe it's a spreadsheet you know, for certain communities and so on. But that extra step is hardly ever done. And it should be, 'cause all that hard work can fail at that last point. If people can't engage with the strategic narrative. So I see these more complicated roadmap forms which are very useful, and then these very simplified forms. If you only work at the simplified level, it's superficial. So you have to get your hands dirty in the detail and then come up to the surface, and then think about the pitch, if you like, the simple message. And those people who receive that sort of door opening with those simplified graphics will be very pleased to know there's detail. And if you want to respond to any query they have it'll be in the detailed version. So working at those two levels you may have many multiple versions of the simplified ones. But that's a very good practise, but hardly ever done. So I'd encourage that. Maybe in software it's not such a big deal. Because it often, the core roadmap is often, you know about the core integrating the product reset and visual they're not too complex. It's that style of roadmap that should be taken to the board, if you like.

  - We've got, kind of, the different layers of detail there. Can you maybe spell out a little bit more about what sort of detail? What are the elements that are in here?

  - Well if you think about, say a corporate roadmap. You know, they could have the whole corporate strategy on one page. Then what the system's thinking allows you to do is to have a family, a hierarchical family of roadmaps to manage that complexity. And so if you think about what each business unit will have their own roadmap and they'll have one line in the corporate roadmap. And then within that business unit they'll have probably organise around product families, products. Because that's what generates the revenue and have a series of product roadmaps. And ideally that family roadmap will work together. So the information flows vertically in the organisation as well. So you know, you need to integrate, align horizontally. For example, if a product is the marketing and technical groups on the same page. That's horizontal alignment in the organisation. But vertical alignment or integration is a big problem too. I see a lot of problems of, you know, bottom up. It doesn't actually get into the corporate thinking. Corporate thinking doesn't flow down. The roadmap, the system's architecture allows that all to happen. And then ultimately you need to align and integrate at the right time, synchronisation. So, you know, sitting behind all the roadmaps are those three fundamental dimensions. Vertical communication in the system, horizontal and in time, because that's the ultimate scarce resource. I think I've forgotten what your question was but that's my answer.

  - And so you've mentioned using stickies. You've also mentioned using Excel. Do you have a preferred tool in terms of both creating but also managing and visualising?

  - Well I think the most common tools I see, and we use are really simple office tools, to start with anyway. So I always, my advice generally is don't reach for software in the first instance. You know, start the conversation going with paper and post-it notes, to get a feeling for the method and how it'll work for you. And what the value is and how to customise it. It'll stabilise after few iterations and you'll be in a much better position to decide what software support and digital support you need. And you can have a use case that you could then go and test out different solutions. Because there are a lot out there now. A lot of them are, you know, subscription services. So you might get a months free trial. But dashing to software straight off can be a big mistake, I think. So a really simple, really widely available tools are the best ones. I've seen people in terms of visuals they tend to often reach for Visio or other graphic packages that are better than PowerPoint. Where, when one comes to dedicated software systems. I have seen some social media systems adapted. But I guess there's two strands. There's some software systems that have been around for a while, that come out of the hardware world, Decades. There's one from Sopheon. They tend to often end up in product management systems. That the one, Accolade, it's called in their system. It's got all the architectural support. That's the key thing that many software systems won't have. So complex roadmaps, multiple roadmaps in a complex corporation. That has it's origins in Motorola, 20 or 30 years ago. It's gone through multiple ownerships. SharpCloud is one that came out 15 years ago. Fujitsu services working with external vendor SharpCloud, in the Futures Group needed that sort of system. And then more recently, Itonics in Germany. And there's only those three that are really fit for corporate deployment, if you like. In this hardware environment. But then, last five plus years a whole host of Agile roadmapping systems have appeared. Many, many pages of Google, I think quite fast moving. Some of them I think can support the architectural thinking. The system's thinking. Many of them probably not. A lot of them look very slick, you know, but I tend not to work with the software assistance. Because we're always helping organisations get going. So it's before the moment when they probably are in a fit state to work out what IT support and software will work for them.

  - Fair enough. And so that sounds like the sticky is the preferred tool at the starting point.

  - Absolutely. And what, you know one of the benefits of Covid, maybe the only one, was everyone was forced into experimenting with digital tools. So we got quite a bit of experience with digital whiteboards. And they're a fair imagisation of the technique. It does allow distribution in a remote collaboration. But some things are better face to face. So my thinking there, is it's pretty good but maybe if you had full design control. In other words, you could get people together if you want to. Which is very expensive and logistically complex. Maybe in the new normal, you could reduce the requirement to do that by 75%, no problem. A lot of wasted time there. People have travelled around and you do probably things in workshops that aren't really value adding. So if you really think about when it's critical to get face-to-face meetings. Maybe to kick off to build trust. I think that conversation could be had very well in a continuous basis, digitally on whiteboards or other systems. And then maybe at particular points you get together again. So I think that's still, people are trying to work out what the best solution. The mix, hybrid mix. What I don't tend to encourage is doing both at the same time. You know, that's a recipe for disaster. So far. Maybe in the future when we have really high fidelity. VR, maybe there'll be other options.

  - So coming off from tools then, Rob. What about best practise, on road mapping? If you had to kind of choose one or two things.

  - I'm a bit allergic to the concept 'best'. Which means there's only one, but good practise you know, and effective practise, many things. I do think, I mean, going back to the original Motorola paper, that described a method. Between '88, I think '87. I think they recognised the need to have consultative, consensual consensus building process. I think that's an absolute must. You've gotta get people's fingerprints on it. It's a useful tool to get your own thinking in order and I use it myself, you know, but that serves my purpose. But, you know, in complex situation when multiple people have to be involved. If you don't get them all involved the roadmap will have little traction. Now, you can do that in many ways, you know. Interviews, but then you don't get the conversation. So at certain points getting people together and it's a very effective way of having strategic conversations. and I'd always encourage people to actually use the structure and empower people. And you can have conversations on the canvas. And it's really helpful for everyone because they understand, you know, where this point sits in the bigger picture. It's just very effective and it cuts through a lot of the conflict, and so on. So I think that's all. I would always encourage people to take that people oriented process. There can be lots of modelling and simulation and good data from that source as well. But in the end, it's those people who have to act. You know, and getting there, they have an ownership of the process if they're involved in it. So that's the top one, I guess. Keep it simple. Its great temptation especially amongst technologists to put everything in there. Because they kind of like to see the detail. I think you should suppress, I've never enforced it but you should have a kind of a bit, budget if you like. You know, no more than 20 post-it notes, for any roadmap. For example, I don't know if it's 30 or 20. I've never been harsh about that but that's a auto-scaling thing, right. So if you think about the history of the universe. You can tell that, in 20 or 30 big chapters. How you made breakfast, 20 or 30 small steps. So, you know, you need to basically reduce the content. Because it becomes a burden to update and it hides the core message. Put the detail elsewhere. The roadmap should be the highest level navigational tool. I remember, General Motors in, I don't know, 20 years ago had a corporate decluttering process. I think all organisations accrue bureaucracy. And every now and again you need to slash and burn it. And they had a really ruthless process of getting rid of everything. Probably have it back by now, in spades. But their roadmaps were beautifully simple. The five things nobody must ever forget, you know. So I think that discipline of keeping it high level. Having this navigational aid, there's a great temptation and the opposite of best practise or good practise is to mistake the roadmap for your strategy. It's a window onto your strategy. And then if you mistake it's an easy mistake to make. Because it looks like your strategy, because that's a depiction of it. But then people will start saying, well roadmapping is hard. When actually, it's a wonderfully simple technique to help you with a hard problem. Which is your strategic planning and dilemmas and so on.

  - Perfect. And you answered my next question already. So let's take you to, I think you mentioned someone before we started. Whose advice on roadmapping do you listen to?

  - Well, the first advice I would always learn listen to, is people who've done it, in industry. And I think roadmapping and most other good things in management, don't come from academics. They come from people solving problems. And that's where roadmap came from. It wasn't dreamt up by academics. It was people in tough strategic situations finding a way to do it. So I would always really respect people who've kind of walked the talk, really. And that's where we learned working with companies as well, to then take that learning. What we can add is time to reflect. Look at variety and so on. So that's the first group, where roadmapping came from. And companies are very keen on learning from each other. You know, nobody's interested in the content of their roadmap, but how do they organise. So there's no barriers. Even competitors will often talk about these things. They just won't show you the actual roadmap. In terms of experts, I think the two, well they're not academics exactly, they're systems experts. One comes from the semiconductor world, Dr. Gerd Mueller from Eindhoven. Although he's teaching systems in Kongsberg, in Norway. He worked with the embedded systems institute. Einthoven ex Phillipstown, really steeped in semiconductors and systems thinking. That's one of the roots of roadmapping, came from complex semiconductors. And you know, Moore's law has been sustained through the whole industry. Collectively developing a sector level roadmap. And so they really understand systems, you know. And Gerd is their 'go to' guy. He's got a great website called Gaudi. I've asked him why, but I think it's because it's never finished, like the Cathedral Barcelona. But it's a lot of resources there. So if you search on Mueller, Gaudi, you'll find that. The other sector where roadmapping came from and you know, people really understand systems is aerospace. And so there, I'd point to Professor Oli de Weck, at MIT. Who's spent two years at Airbus, working in the CT office on their roadmapping systems. So he doesn't just think about it, he does it. And when he went back to MIT he's got courses there now and a new book. Oli de Weck has got some courses on technology, roadmapping and a new book. So if you want this sort of hardcore technology analysis side of technology roadmapping that's the main resource available now. So those two. And then I think also there's other experts around academics, who are more applied focus that are interesting to talk to. And places like Fraunhofer, Dr Sven Schimpf, in Stuttgart. You know, they do a lot of very applied research and a lot of expertise in roadmapping.

  - I've employed a number of people from ex Fraunhofer Institutes over the years.

  - It's a great bit of infrastructure that's been persistently supported for 75 plus years. I wish we could have something like that in the UK.

  - I've also spent a lot of time at ASML.

  - Yeah. Oh yeah. Well, what a remarkable company. So Gerd Mueller used to work at ASML, you know

  - Interesting.

  - And so work on their road mapping there.

  - So Rob, coming towards the end of the conversation. If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?

  - It's actually a quote from Gerd Mueller, once said. That stuck in my mind, is 'think big, act small'. You know, people often fall in the trap. They can see the power of road mapping, say to synchronise the whole organisation. Well that's downstream, right. Take the first step. In an hour, two hours, a day, you can do a lot and you're on a journey. And so, you know, often if you employ a consultant. It'll be all problems are big problems because you're selling hours. They may say it's gonna take six months. I always advise people, give them a day, you know. There's plenty of time to demonstrate the benefit of the technique and then iteration and Agile approach. Scaling up as you build confidence. So that general Agile approach is always good for complex and uncertain projects. And the other one is really the power of integration. You know, that's uniquely a benefit of roadmapping. And it's missing. The strangest thing about road mapping, it's been around for 60 plus years. And it's been entirely ignored by business schools through that entire period. You won't find it in any strategy book. I've never seen it, a couple do have modules on it. Not researched, so many people who need to know about it, don't. And so that's, I guess my biggest plea is we need to somehow solve that problem and get awareness better. Because when people are interested in technique. Where do they find credible information? You know, the metaphor travels much faster than the discipline. And so, you know you can easily struggle or if they don't spend enough time, just working out what is this thing and how best to use it. You can get many different views and so on. So I think I'd encourage people to do a little bit of due diligence. Always to just inform themselves, experiment. Don't commit until, you know, it's no risk. Because if it's only a day or so, what's the downside of having a go? But, but to do a little bit of Google research first to try to spot what the actual discipline of roadmapping is, as opposed to all the other stuff you find. The background to that was, I think that in 2003, the Roadmap for Peace in the Middle East was published. And immediately I saw the word just exploded across newspapers. I've seen it in novels and people love the idea. Metaphor, strong metaphor. Sounds like you know where you're going. But you know, the actual good content behind it is a little bit obscure. Because it's not in the mainstream business teaching and research programme.

  - Is there anything about roadmapping that I should have asked you, that I didn't?

  - Don't really think so. I think we've covered most aspects, nothing comes to mind.

  - Rob, it's been wonderful having you today. Always like to give people just a last chance to give that pitch. So fire away.

  - Our main mission is to, well develop useful things that have impact but to disseminate. And so I guess from a dissemination point of view we put quite a bit of effort in. I've got a website of my own which is designed for that purpose, Cambridgeroadmapping.net. So if anyone wants to find out a bit more and lots of templates there and pointers to different resources. And there I'm trying to build something, as one place to go. We do other training and so on. And sometimes the best way is to learn by doing. So we have a knowledge transfer company embedded in our division of engineering. Owned by the university, set up to support dissemination of research. And so that's available as well for very direct hands-on support, from professional consultants. And their model's not a normal consulting one. Because their purpose is to transfer. So often, the most effective transfer is when the company does a lot of the work. And so, you know you can minimise hours and cost to maximise transfer. So that we do quite a lot of that sort of work. but it's not there for the normal commercial purpose of consulting, although it does generate resources for research. It's there to make an impact from the research. So that's my pitch, I guess, is spread the word and we'll try to help.

  - As always, just a little reminder. Please do like, subscribe, hit the bell icon. And if you'd like to join us on the channel. Please do. Either get in touch via the comments below or email us at info@talkingroadmaps.com. We'd love to have you here. Rob, it's been a pleasure having you here.

  - Great, thanks very much of having me.