Is the roadmap a discovery tool? | Raphael Weiner

In episode 52 of Talking Roadmaps, Raphael Weiner, co-founder of Orbital, discusses the multifaceted nature of roadmaps and their role as discovery tools for product teams with Phil Hornby. Raphael shares insights from his extensive experience with startups, emphasizing the importance of adaptability and continuous discovery in product management. The conversation delves into practical strategies for effective roadmap utilization and the common pitfalls teams encounter.

Raphael is the co-founder of Orbital, helping product teams build better products. He has nearly two decades of experience working with startups in roles spanning product management, software engineering, and venture capital. He's also a partner at New Forge, investing in young technology companies. While he'd like to think he spends his free time reading, exercising, and exploring – the majority is currently spent picking up children's toys.

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 Bob Moesta, he is an Author and JTBD Expert. So watch out for Season 1 - Episode 53!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about everything roadmapping, the good, the bad, and the ugly. Today I'm joined by Raphael. Raphael, tell us about yourself.

  - So my name is Raphael Weiner. I'm the Co-Founder of Orbital, where we build product discovery tooling for product managers and product teams. And I've spent the last 15 years in and around both early and growth stage startups, mostly in product management, but also with students in software development and venture investing.

  - Awesome, and I'm sure we're gonna hear some of that unique positioning or unique point of view on how discovery links into things and links into the roadmap as we go along. If you're enjoying the channel, subscribe, hit the bell and give us a like. What's the purpose of a roadmap?

  - I guess I feel I need to provide an advisory warning for the conversation because I've worked with teams, both big and small, in both advisory and operational roles. And something I can say with certainty, you know, is that a roadmap is not a roadmap, is not a roadmap, or to quote a famous Belgian, roadmap. Not sure if you're a fan of the surrealists or not. But all that to say is that, you know, I believe that talking about roadmaps without context is a dangerous thing, right? Or at least trying to make sense of what someone has said about a roadmap without context is dangerous. So for the sake of this conversation, I guess I will frame my responses to a place where I feel I have sufficient experience to speak from, which is B2B enterprise SaaS at a scale up. And so I think outside of that context, my advice or my learnings probably are not wonderfully applicable. So that's the advisory warning I guess that I would offer.

  - So then, okay, in that B2B enterprise SaaS environment, what's the purpose of roadmap?

  - But I don't really believe that there is a single roadmap, even within that narrow context. And that's because, you know, the central purpose of a roadmap should be to drive alignment. But every single person in your organisation has had some past experience with this idea called a roadmap and some expectations from it that others have set, that they have, you know, personal experience with. And the same is true for your customers as well, right? And so if we think about it from that lens, like there are many, many things which are referred to as the roadmap because I don't think it matters what the product leader says, hey, this is the roadmap, right? The audience, and as they interpret the roadmap, that is the important thing. So I'll give you a couple of examples to make that kind of concrete. There is the contract that a CEO and executive team expect from the product org. And I know that contract is a strong term, but I did say expect. And if it is not that, and I can assure you that it will not be a contract, it's on you, the product leader, to correctly reset expectations. Another form that the roadmap takes is like the sales instrument that product uses to help close deals. That's a roadmap. Another is the internal kind of delivery-focused roadmap to align multiple teams within the organisation. Then there's kind of the glue between support and success and requests coming in. And then the feedback loop, right, from the roadmap, from that internal short-term roadmap. And there's roadmap as it pertains to, let's see, enablement and marketing, right? Which could be a very different roadmap than the one that you're presenting to customers, and the one that you're utilising internally to help drive alignment and get teams on the same page. And then finally, like there is the answer to the question which we all get, is it on the roadmap? In my experience, like a roadmap generates an amazing level of frustration and confusion in product orgs generally because it is misunderstood, and everybody thinks they know what the roadmap is. And the only real, I would say, canonical definition of the roadmap is what is in the mind of that individual in the audience. And there's not a single audience just said like, there is a massive audience both internally and externally.

  - Love it. And in fact, my next question is gonna be who is the audience of the roadmap? But before we go there, I just have to challenge, push back a little bit. Surely there can only be one roadmap 'cause there's only one direction of travel. Maybe it's different views on it.

  - Only one direction of travel. Yes, in that sense, that is true. If we think about a roadmap being what the team, where the team is going to invest their time, right, then at least my image is like you have concentric circles of reducing certainty, right? So you have the short-term roadmap, right, which where you have solutions that are already defined, that teams are actively working on, and you have the next concentric area, which is maybe opportunities that you are looking to solve, but you have not yet investigated the solution space. And then you have, right, the outer edges where you're getting closer and closer to the strategy, right? Which is more diffused, less understood, and less likely to actually be something that you're gonna work on within a reasonable timeframe, let's say. So I think you're right, there is only a single roadmap in the sense that there is only one direction of travel. But I think that's looking at it from the perspective of the product leader, and the point I was trying to make, which I think is equally valid, which is that the consumers of the roadmap or the audience, as you put it, is equally as important in the understanding of the roadmap.

  - And so I totally agree, I think an individual rendering or view for me of the roadmap is for that audience to communicate what they need to know, how, what we need to tell them effectively. But it should all come from some sort of common point, or at least one would hope.

  - Yeah, so yes, and maybe that's what I've referred to in my career as like these strategic roadmap, which the rest kind of follows from. But I think there's also not one right way to do road mapping. And I think it needs to adapt based on the needs. In the early days, I don't think you need a roadmap. In my current context, early stage startup, four people, we know what we're doing for the next couple of weeks. Beyond that, I would say there's not a roadmap. We have a strategy, but we do not need a roadmap because of the stage that we're in. In a, you know, later growth stage company of three or 400 people, right, you need a very extensive roadmap, and you also need many roadmap artefacts as well, depending on the audience. And a lot of supporting enablement, let's say, around those things as well.

  - I mean, actually as you described those different concentric circles, that's an, we actually have a set of visuals that we're working on at the moment. And one of those is a radial of those different layers that's essentially, as you described them, so great to hear it. Sometimes we need different visuals to communicate differently to those different audiences. And maybe break that left to right timeline view, which is so pervasive.

  - Slide decks, right? Slide decks only go one way. That's, I think core to the challenge that a lot of product people stumble into, right? It is, yeah, the linear nature of what we use to present things. And I think with, you know, the abundance of collaborative whiteboarding and newer design solutions, like the canvas has expanded the ways that we can communicate things visually, which could be really powerful for things like roadmapping.

  - And so you started to hint at the audiences and them having different needs. So who are those audiences?

  - Yeah, sure. So in short, everyone. There are both internal and external audiences, and I think there are plenty of people who would like to think that your customers are not an audience for the roadmap, or rather because the inherent nature of the roadmap, which is one of like very high uncertainty, kind of innately so, feel that you should not put anything in front of a customer to say, hey, this is our roadmap, this is what we were doing beyond like your nose, right? And but I disagree with that. I personally believe that customers are an incredibly important audience for the roadmap, because as you touched on or hinted at earlier on, we are working on a product discovery tool. And that is where my head is these days. And it is there because in the past, I have used tools like roadmap and seen my team, my team of product managers use it to facilitate some of the most important conversations we've had with customers. And so I think to not leverage it in that way is a massively missed opportunity. You're nodding, I guess you agree to some extent.

  - Totally, in particular in that enterprise B2B space. Like you've got two ships moving at slow speed, and you want to know which direction they're going in. Are they going in the same direction as each other and therefore helping each other, or are they gonna crash or are they gonna separate? And the roadmap allows that conversation to take place.

  - Absolutely. 'Cause any buyer of software in an enterprise context is thinking about that renewal date, and thinking about how well does this tool fit our organisation? As you said, like two ships, the users or the buyers of your software are evolving, so their needs are gonna be changing over time. When they bought your software one, two years ago, they're in a different place now, as is your product, as is the market. So the, you know, world of options they have to choose from. And so, you know, you do owe it to your customers to help them understand where you will be so that they can make the right decision for them. And sometimes that can go against your own personal interest or professional interest, which is, hey, let's keep them as a customer, let's promise them the moon so that they renew, right? But you want them to make the best choice for them as well because you know that if you have customers that are not within your ICP, you are gonna be in a world of pain, right? And so I think it is just as important to, I don't like the term, fire customers, but like to, let's say, evolve, right, and lose some customers that are no longer within your target audience because you know you will disappoint them. And the level of friction that will be created both in the success org and like around you, will just be tremendously high and it is not worth it. And I think that that's one thing about roadmaps, and we'll probably touch on this later, but with roadmaps, it is very easy, I have found, to fall victim of the like, you know, pay the price later, or deferring the cost, right, or the pain of something. And so it is so easy to say, yes dear customer, or yes dear CEO, or yes dear sales leader, this is what we're doing and we have high certainty, right? Bet the house on it, because you can say that today and buy yourself another six, nine, 12 months until the, you know, the bill becomes due. But obviously down the road, there will be, you will have to pay for that decision that you made to project certainty when it might not be there.

  - I love that kind of metaphor of saying yes to putting it on the roadmap, but essentially what you're doing is getting paid today for something you then have a liability to deliver down the line. In fact, so much so I remember an organisation that was in the past, in the early days of Sarbanes-Oxley, where if we showed it on the roadmap, we couldn't recognise a dollar of revenue until we shipped it. And so because there'd been so many organisations taking the money up front and then not delivering, we took the most conservative model possible, which meant there was millions sitting in the bank unrecognised, even though the clients had paid us. And in some cases the clients paid us and then never implemented the tool, and we couldn't recognise the money 'cause we couldn't show that we delivered to them. It was an interesting challenge at times.

  - I've seen a lot of shenanigans around putting features or promises into contracts. Should or should not be there and will at some point become due in the future. And your future self looks back and is just shaking their head at you. Why, oh why?

  - It's cheap for your current self, it's expensive for your future self. And who knows, you might not be in the job by then.

  - That is also a good point. Yeah, the time horizons you're talking about generally with this stuff are such that the likelihood is not zero that you might not be there or things will have changed to the point where it might not matter, right?

  - But I still think we should aim for some level of honesty.

  - Absolutely. As I said before, I think that it is of utmost importance for the product team to always convey the level of uncertainty that is inherent to a roadmap. Think we'll talk about this later, but anti-patterns or pet peeves, I've seen a lot of roadmaps with mockups in them or products that have really yet to be discovered, right? This is an activity done six, 12 months before work or discovery even will commence on this thing. And I think that's a obviously a recipe for disaster because it's easy to tell yourself, you know, hey, I said we're not committing to this, right? But you've just put a high fidelity mockup in a customer or even internally facing, you know, presentation, they're gonna walk away with hearing something different than you thought you said. And that's tying it back to the audience where I think, again, roadmap, is just everybody has their own view of what the roadmap is, and that's of utmost importance that we remember what that is and we think about that all the time.

  - Interesting you should start to talk about discovery because normally my next question is about how does the roadmap link to vision, strategy, and objectives? But I was specifically gonna extend that to yourself. How does it also extend to linking to discoveries? 'Cause I think there's almost like three points of a star there. Like the really big picture, the figuring it out, and the roadmap that kind of can go together. What are your thoughts?

  - I would say that the connection between these three things is that the roadmap is the discovery tool. Let's put it that way. At least in the B2B enterprise context, it can be very, very difficult for product managers, product designers, product teams to get in touch with customers, right? And of course in the enterprise context, right, we know we've got, you know, EBs, champions, admins, users, so there's a lot of different classes and roles of people who come in touch with your software. But it can be extremely, extremely difficult to just get kind of direct feedback from those folks and get those calls set up. It is easy generally to get the champion in a call. They have a very good relationship, hopefully with your organisation. But that's oftentimes not the person who you need to be speaking to as a part of your discovery. And so that's why I think about a roadmap in this context as being a tool in your tool belt for a discovery, because it is an invitation, it is very easy to get people into a call, as you say, hey, we're gonna present our roadmap. And the best product managers that I've worked with have been able to turn a roadmap presentation into a wildly effective discovery session. And it transforms over time because you're picking up, right, where their interest is and you're slowly narrowing in. And like rarely do you get through an entire roadmap presentation if you're doing it right, I would argue, right? You're skipping slides, you're digging down. It might turn into multiple sessions. But yeah, so the roadmap is a discovery tool. That's how it connects to roadmap. And I think strategy is self-evident in that it sits above both of these things and shouldn't be changing often.

  - So if we're looking at this thing on the screen, what's on it?

  - You tell me. I still haven't found a good answer to that. I think the obvious answer of what it is not, it is not a set of solutions, you know, anchored in time, right? That is what it, I think most of us clearly understand it should not be. I think what it should be is, again, if you think of the roadmap, at least customer facing and then we can talk about internally as well, 'cause I think we're gravitating towards one artefacts of the roadmap or one use of the roadmap. If you think of it as a discovery tool, it should be whatever you need to have in there to spark enough, let's say recall or context such that you can dive into deeper questions, right? You spark interest, you're able to identify it, and then you're able to dive in. From the discovery lens, I think that's what it should be. If you look at the roadmap with maybe another definition, the short term roadmap, which I often hear called, which is like when you have solutions and the team is actively building them, and like we know software takes time, right? So like you can have, even in very agile environments, you can have like a solution which is pretty well understood and finalised, right, that takes months and months and months, right, to build. Hopefully these things are happening at the same time, right, and converging, but yeah. And so for a short term roadmap, that is gonna look immensely different of course. And I don't know, I'm referring to both of these as like the roadmap right, in trying to convey that idea from before, which is like, it's the audience that matters and there's a lot of different ways that this thing materialises. What do you call like the short term bit of it? I would be curious.

  - Yeah, interesting. So, well let's imagine we've got some sort of timing on our roadmap, and I would, I tend to sort of lean towards the Now, Next, and Later style format. So kind of timeframes as opposed to dates. And perhaps in my Now column, I do have solutions. Perhaps in my Next column, I have user outcomes or problems to solve. And in my Later, I have the maybe just the high level goals of things that we're exploring. The problem is that takes a lot of maturity for people to understand that kind of varying content, which is why perhaps different views become quite useful, of maybe your roadmap is always problems, always user outcomes or jobs to be done, as I quite like to put on them. And then maybe we have a separate artefact or a separate page in the same document that is that shorter term view, which I would typically call a release plan, 'cause it's date and delivery oriented and solution oriented. And it's like, okay, we have understood these problems, we're gonna solve them in these ways on these dates. And we've got a high degree of certainty. But ultimately the language, the semantic side of it can start to become actually half the battle. We're fighting about what we call something, let's focus on the message we're communicating.

  - Release plan. Yeah, I think that's definitely true. And I think especially even from a release perspective, once you have a solution, it's easy to say, oh, we've got a solution, we're building it, and this is when it's gonna be done, right? What is done, right? Done is delivering to customers? Okay, is it all customers in GA, are you having an early access or beta programme? Hopefully. Are you, you know, perfectly ready to throw away that product if it doesn't do what you were hoping it would do? If it's not having the impact that you were hoping it would. So even once it is in that, you know, Now column and you have solutions, are you sure it's gonna be there, right, in that state for customers? I think if we're honest with ourself, the answer is hopefully not, 'cause that means we're practising product the right way. But we do need to have some sense of certainty, otherwise chaos reigns. And so like, again, conveying the level of uncertainty, but saying what is our best guess? And the struggle around roadmapping I think is so important. And that's not what I'm trying to say, to be clear, that roadmap is like not important because like how much pain and struggle it creates, but like it is the activity of roadmapping which creates the value, and it is what it communicates as you said.

  - Yeah, and I think my cohost, Justin and I, would be absolutely aligned with you there. It's like roadmapping is a process in our mind. The roadmap artefact is a minor part of it that we kind of capture our current thinking in, having spent a lot of time thinking and collaborating and working out that direction of travel and aligning with people on whether it's the right direction of travel. And then we use it to support the communication out with those different audiences once we've kind of got to that somewhat cohesive plan. In fact, I hate using the word plan that I just used there, but that somewhat cohesive direction.

  - Yeah, no, I think, and plan is just as riddled as roadmap for that reason, right?

  - But I mean, and some people suggest, let's throw away roadmaps, or let's throw away the word roadmap and rename them. And I look at that, it's like, well it's already out there. Any new term we come up with will just be as overloaded in about five seconds anyway. We're, it's a losing battle. Let's just educate and improve as opposed to trying to be too smart.

  - The last larger environment I worked in, which was a scale up, we were about 300 people when we sold the company. I led product there, I had about 20 product managers and product designers in my org. And what we did was something interesting, which was rather than giving initiatives names that would be easy to understand, we gave them all code names, right? Something that would make no sense at all, right? And this would be, the team could decide. So for example, Feisty Baboon is one name that comes to mind. But the idea is that, you know, if you give an initiative a name, you are helping people fall into the trap of starting to talk about it and understand it in a way without them having taken the time to understand it. So if we give them these crazy names, right? Someone's gonna hear Feisty Baboon and say, well what the hell is that, right? And then they will have to go to the artefacts, right? Look at the, you know, outcomes of the discovery, everything that's been documented about this thing and form some opinion instead of saying, oh, it is the new alerting feature, right? Because if I say that, and then all of my teammates and everybody around me says that, you're gonna imagine something different.

  - Interesting, 'cause code names have this love-hate relationship out there. Some people love them, some people hate them. That abstraction is useful. I always used to use like Greek gods or things like that where there was some slight correlation with what it related to. So Chiron was my geofencing feature many years ago. 'cause he rows you across the river stick, so he crosses a barrier. So there was some kinda link to it, but most people wouldn't get it unless they were, you know, steeped in mythology and things like that. But yeah, I personally have used code names quite a lot and found them useful at times. As you say, they create almost a barrier to communication that forces better communication.

  - Yes, yes. And so on the face of it, they make no sense, right? And so all the haters, and like there are plenty within at least the example I provided who hated the code names, right? But as you said, it creates a necessary friction, and sometimes you have to do that for each other, right, to do a service to the people who are consuming it, because otherwise something is gonna be communicated that you did not intend to be communicated. And that's the same thing with a roadmap. Again, like there are oftentimes several hops between people, like when they access roadmap data. And so you have secondhand, you have third hand mentions of what is happening, when it's planned, what level of commitment or certainty do we have? And that's why it's so important, I would say, like that the supporting or enablement around the artefacts, as you put it, of the roadmap are almost, if not more important than the content of that roadmap, if that makes sense.

  - I mean it's that kind of friction is similar to the one around the radial roadmap that I mentioned earlier, kind of that was very much as you described, because it breaks the left to right timeline. People have to stop and think just for that extra 10 seconds and that extra thoughts helps get another layer of insight into what it's actually telling you instead of just saying, oh, it goes left or right, and that's over there.

  - Yeah, absolutely. Even after you create that, once you look back at it, you're like, whoa, this is, wait, what is this? Wait, no time only goes in one direction. Like this used to be a Gantt chart, you know, 10 years ago. What, how do I?

  - Okay, let's switch gears a little bit, Raphael. What do you consider to be best practise when it comes to roadmapping?

  - I think there are several elements of best practise. One is around that notion of certainty and uncertainty. So I think that needs to be so central to a roadmap and the understanding of the roadmap from the audience, right? And so if everyone who consumes that roadmap does not understand the level of uncertainty that is in it, you're in trouble, right? So that's one element of the best practise, I would say. Another element of the best practise would probably also be, as I mentioned, the kind of supporting or the enablement around it. Again, if you are not doing that, if you're just putting out artefacts into the ether and letting the consumers come as they will, whether it's a technical account manager, manager, a CSM, a customer, right? Oftentimes you're on a call with a customer and they're like, hey, could you send me the roadmap, right? Unless like, I think usually you shouldn't, right? Because usually you have not created a document that was meant to be like, not meant to be accompanied by some talk track, right, or by some additional clarification. Let's keep it at those two. I think there's a million best practises. Those are the two that I would offer to the conversation.

  - I love that second one in particular. One of my sort of comments I've made a lot in the past is that salespeople are professional communicators. And if you don't tell them what to communicate, they are going to figure out for themselves. So they've got a page with 10 words on, 100 words, whatever it is, they're gonna turn that into a thousand words. And if you've not told them what those thousand words should be, are you keeping them on message, they're gonna go off on a different direction and they're gonna make stuff up that sounds plausible, sounds great, makes the customers really happy, but is nothing like what you are actually planning.

  - Absolutely. And I've said enablement a few times here, it's such a central part of the role of a product person, specifically product manager, right, in the enterprise B2B context. And I don't know about you, but I have not read a tonne out there about enablement. And I think you often see it fall under the product marketing org, which is an okay place for it to be, but like it is and it should be a massive part of your job for the exact reason you just gave.

  - I think I've seen a trend in the last few years of product managers ending up too much in the technology organisation and not recognising their role as business people. For me, I was always in sales calls, supporting sales discussions, helping prepare collateral, making sure that we were on message, and okay, if you're in a big B2C environment where there's a million customers, you're not in a tonne of those. But if you're in a B2B enterprise environment, heck, I think there were only 20 customers globally in my last business, really, you know, predominantly. You're gonna go and be having those conversations. If not, you are wasting that opportunity as well.

  - And I think one thing that rings true that every product manager will understand, is that like your role and how you can best contribute at any given point in time is adaptive to the organisation, right? And so I think that's something that's rather unique about the role, right? It is like if there are gaps on the delivery, on the technical, like you might lean in there and you might over-index, then that may happen. And if there are gaps on the other side and you try to pick up too much or don't think others are, you know, conveying what you would like to convey, again, you're gonna go over here, and that's, it's gonna change as the people who you work with and around you change. But yeah, that's part of the joy and also kind of like the quandary that we're in as product managers when we talk about best practises is like every single organisation, even within a single product team, like to provide, to deliver the most amount of value and have the most leverage, you're gonna have to be a very different type of product manager in that context.

  - Yeah, and that's why I think often generalists farewell, people who've done roles in other teams as well because they can come in and quite quick really relate to those other teams, those other functions, and flex into the different space where the gaps are.

  - Absolutely. Yeah, absolutely. There is a fine line between exposing those gaps and talking to leadership about it, so that can be filled over time, and trying to, I would say like duct tape, or find some, become the temporary solution such that 80% of your time is suddenly doing this role, which is not where most leverage, right, should be coming from you. I find that PMs spread themselves really thin because they are in the centre of many, many things, right? And many of them are generalists, and you know, at some point they realise, holy shit, I'm not doing a very good job at any of this and I just worked 90 hours this week. Is this what it is to be a product manager? And I think, you know, the answer is, well, yes, right? But like for short periods, as things are being filled out, that's yeah.

  - The question I like to ask is, where is the highest leverage point I can be working right now?

  - Exactly, yeah. And like the answer to that question, as we just discussed, is like highly dependent on who are the folks around you, and the receptiveness of leadership or the people who can bring people in or out to backfill, right? To be able to move you back to the type of leverage you should be creating, because there's the should based on the now, and then there's the should based on what good looks like, right, and what a like healthy whole team should be doing.

  - And you mentioned it earlier, Raphael, anti-patterns. Come on, give me your top two anti-patterns as well then.

  - I think I hinted on it earlier. I would say putting high fidelity mockups in a roadmap, anti-pattern, right? I've seen it very often, and like I have been, I've done it myself in the past. Most of what I know not to do is because I've screwed it up, right, in the past. When I started in product management 15 years ago, there was not a lot of literature out there. You know this as well, at least specifically around product management in a software context. Dates, right, that's one I'm sure everybody says when you ask them, don't put dates, right? You can do the Now, Next Later, you can do quarters, right? So like a broader bucket of dates, right? So you're working with a histogram in instead of a timeline. No, those are, I think those are the two main ones, or I mean I guess I said it before, right? But again, it's like the lack of supporting artefacts, training enablement to accompany the roadmap, right? If all somebody receives is an artefact, I can be pretty sure that they will understand something differently than you had intended to communicate.

  - Yeah, I'm definitely, I'm starting to lean into instead of providing the artefact, provide a recording of me presenting the artefact that they can watch when they want to watch, when they need that information. Heck, they can even present it to the customer if it's a customer facing version of it. But it's on message, it's aligned, it is really hard for them to edit. Like salespeople have this habit of moving dates when they've got an editable version. Just enable, ensures that they've got what they need. And with tools like Loom and stuff around, it's really easy to do.

  - It is, it is. I would say the one case where that's not easy to do, roadmaps are a roll up generally, right? So there is both the process of top down planning the roadmap. Planning, again, I fell into that trap, right, as well as like the bottoms up in forming of, first of all that top down, but then also like negotiation that happens, right? That like healthy struggle or friction. And so oftentimes what I've found is that a single person might not be able to present the entire roadmap with any amount of like detail or the necessary amount of detail, right? And so if we look at this from the lens of like a larger organisation where you have like five or more product areas with this really distinct, you know, problem or opportunity spaces, like it's gonna be hard for a single individual, save the product leader, to make that presentation. And sometimes even the product leader can't get into the nitty gritty, right? And so I'm a fan of the recording, and I have done that in the past. But coming back to like the discovery lens, again, that's a missed opportunity as well in that sense. If you're just sending out that recording, like what problem are you solving? Clearly not the discovery problem of inviting somebody into a conversation and using that to extract insights and inform decisions, but definitely better than sending over an artefact, I would agree.

  - Yeah, really good thought there about missing the opportunity. I guess the problem I saw myself as solving was keeping the sales team up to date on how the plan was changing on a regular cadence, say monthly, that then allows them to see, ah, that's the thing that I want to know more about. Let's go and have a chat with Phil, instead of, we have to organise this all hands meeting where everyone turns up, and it's just a pain to schedule in the first place.

  - Yeah, okay. I'm with you, I'm with you. I have solved that in the past in like, in smaller teams, so like context of like 300 people. So calls of like maybe 50 people who are interested in the roadmap and what's changing with biweekly calls. But like then it's still not massive, right? If you go that scale, I think.

  - We're kind of coming towards the end of the session, but there's a few questions I always like to ask at the end. Before we go there though, Raphael, whose advice on roadmapping do you listen to?

  - I'm embarrassed to say it, but like I can't attribute my current understanding around roadmaps to specific individuals, right? I don't know if I've ever read a book specifically about roadmapping. I know there is one or two out there that get recommended often. I should probably read them, I haven't yet. Mea Culpa. And this is funny to say, for someone who's been like in and around product for like 15 years, right? But most of the knowledge that we consume these days, at least in the product sphere is online, right? Or from blog posts or from webinars, or from recordings or from podcasts like this. And so I do not have a good answer to that question in that like, I know I've learned from so many others. If there's a couple of folks whose influence has been greater, I'm not sure. I would say my own failures probably have have informed my understanding more than anything else around roadmapping specifically.

  - Which, you know what, is often the best teacher. If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Embrace and socialise the uncertainty. It is that the roadmap is only what its audience believes it is, right? And so what I said earlier about like, roadmap, this is not a roadmap, I don't know if you're familiar with like the Magritte painting of a pipe, which the surrealists were making a pretty big statement around what is real and what is known. Weird reference for our product podcast, I probably shouldn't have made it. But yeah, it's really embracing and socialising the uncertainty. I think it is like, it is up to us to communicate what we know and what we don't know and the likelihood of things. And humans are really bad with this. So you won't get it right, but you better try. And again, thinking about the roadmap from the view of all those disparate people in the audience, right? What's a better term for people in the audience?

  - Just audience or audiences.

  - Audiences, right? Like is there individuals who have some mental model of what is a roadmap that they've learned from the past that is probably not what a roadmap is in the current context, right, that is trying to be proffered from the product org, and just understanding that and making sure that the artefact in a message are in fact catered to the individual who's receiving it. That was a lot more than one or two sentences. Maybe you can cut off one or two of the sentences.

  - You just unpacked a few of the sentences, Raphael, it was awesome. And I didn't, yeah, I didn't recognise that you were saying something in French. It's like I don't recognise that word. Always like to finish with a final question, Raphael. Is there anything else about roadmapping that I should have asked you that I haven't?

  - The best way to end any conversation. I think we talked about the utility of a roadmap in the context of product discovery, but I think if there's one idea that I'd like to be emphasised or offered to others is the importance and the opportunity of using it to do just that. And it can be a very uncomfortable thing to do, presenting something which is unknown and uncertain and inviting a conversation, and to run your discovery. But I think it's such a missed opportunity to not do that because that can often be, and I've spoken to hundreds and hundreds of product managers and product designers, even in the last six months about discovery because of what we're building at Orbital. And this can be one of the most underutilised tools in the B2B enterprise or even the B2B at large context I would imagine.

  - Talking of Orbital, fire away, tell us about Orbital, tell us about how you can help, how people can get in touch.

  - Absolutely. So Orbital helps product teams recruit and schedule customer interviews so that you wake up on Mondays with your calendar full, so that you're talking to the right people at the right cadence so that you're making better product decisions as a product person. You know, we think it should be as easy as saying, I wanna speak to three people every week within segment X, and you snap your fingers and Orbital does the rest. So that's what we're building at Orbital. You can check us out at useorbital.com. And you can find me, I'm mostly active on LinkedIn. You can find me there. Happy to chat, talk about discovery, talk about what it is to be a recovering product leader. I should have used that in the intro. I like to refer to myself as recovering product leader, 'cause it is a very, very difficult but fulfilling job.

  - Raphael, it's been an absolute pleasure having you here today. Thanks very much.

  - Thank you for having me, Phil. Really appreciate it.