Roadmap or Roadmapping, what's important? | JJ Rorie

In episode 31 of Talking Roadmaps, Phil Hornby interviews JJ Rorie. They discuss the nuances of effective roadmapping, the challenges product managers face, and the importance of adaptability in product management. JJ emphasizes the value of listening to industry experts like Janna Bastow and Rich Mironov, and highlights strategies for aligning roadmaps with business objectives.

JJ is Faculty at Johns Hopkins University Whiting School of Engineering, teaching graduate level product management courses. She is also the CEO of Great Product Management. She is the author of the book IMMUTABLE: 5 Truths of Great Product Managers.  

She has spent over fifteen years as a product manager, product leader, and product management advisor and trainer, working with some of the world's largest companies including Riot Games, FedEx, Verizon, T-Mobile, Fiserv, American Hospital Association, Kaiser Permanente, RBC, and many others.

JJ also hosts the Product Voices podcast where she interviews experts on important product management and business topics.

“It’s not the roadmap that matters. It’s the work that went into it.”

— JJ Rorie

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 Teresa Torres, Author, Speaker and Product Discovery Coach at Product Talk. So watch out for Season 1 - Episode 32!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about the good, the bad, the ugly of roadmapping. We're here talking to practitioners, experts, thought leaders, and educators. Today, I'm really pleased to be joined by JJ Rorie, the author of "Immutable." JJ, can you introduce yourself?

  - You bet. Hi, Phil. Great to be here with you. So I'm JJ Rorie. I wrote a book called "Immutable: 5 Truths of Great Product Managers." I also teach product management at Johns Hopkins University in the United States. I work with corporate clients through my advisory firm, Great Product Management, and I also host a podcast called Product Voices. Love to be here with you today.

  - Perfect. Thanks, JJ. And as is obviously mandatory on the channel, please do like, subscribe, hit that bell icon. We'd love it if you shared it with your friends. And if you'd like to be here where JJ is, do get in touch either in the comments below or through info@talkingroadmaps.com. JJ, let's start with a softball easy question. What's the purpose of a roadmap?

  - Oh, wow. You know, it's interesting that should be more of a softball question than it is 'cause, I think we, you know, ask 10 people in product management, you'll get 10, maybe 9 and a half answers, right? You know, to me the purpose of a roadmap is to show kind of illustration, if you will, a depiction of the general direction of where we wanna take our product or portfolio, whatever the purview of the roadmap is. And, you know, I'm a big believer in kind of the short-term to the long-term and that progression and however you depict that, you know, Janna Bastow's Now-Next-Later, you know, however it is. If you're a date culture, you may have to have some dates on there. But just showing what we're doing now and why, what we're gonna do, you know, after that and why, and then what's our kind of longer term vision. And that's what the purpose of a roadmap is is so that we can use it as a communication vehicle to show the work and the thought process of like our vision, right? And, you know, I just a little bit more on that, I have what I call a product playbook, which is basically everything that we do in product. Our rituals and our artefacts and all this stuff that we do that takes so much of our time so often we're just going through the motion of doing it, and it's not really tying back to the decisions we need to make and the goals we're trying to reach. Same thing with a roadmap. it's just a vehicle, it's just an artefact that should be a communication vehicle to show all of the work that we're doing, right? So the why behind where we're going and the, you know, some of the detail of where we're going, it's not that the roadmap is the end all be all. It's the work that went into the roadmap that's supposed to actually be, you know, the benefit. So again, short version, it's should be a depiction of where we're going. It should be a living document. It can change over time. It shouldn't be, you know, written in concrete. It is just a view of where we want to take the product.

  - Now I just do wonder, you know, does that map to any of these five truths of great product management? I'm wondering if we can put a spin on there from "Immutable."

  - Well, I mean it, I tell you the five truths of great product managers and just very briefly, it's customer intelligence, relationship building, communication, judgement , or decision making, and prioritisation. And those are those five truths that, in my research, in my experience, they form this kind of like interwoven foundation to everything we do in product management. And so it's not that there's a, you know, be great at product roadmapping is one of the great... One of the truths, certainly the way it ties in is, you know, you can't build a great roadmap without having a high level of customer intelligence 'cause otherwise you're just throwing stuff at the wall, right? You should be, you know, gathering great customer and market intelligence and letting that drive your vision. So that's one kind of tie to it. But then, I mean, really, again, as I mentioned before, it's just an artefact. It's just a vehicle to communicate what we wanna do to various audiences, right? And so certainly one of the things we talk about in the book is adapting what you're communicating, the level of which you're communicating to your various audiences, and that being a connection ability and that great communicators do. Well, same thing with roadmaps. Like, you know, you may have a roadmap and different viewpoints or a drill down version. And so you're talking to the executive committee and they don't wanna, you know, a list of your projects. They want to see your vision and have a conversation around that. So you're talking to them about the why. And then you may have another, you know, group of stakeholders that you drill down into the how of at least parts of your roadmap. You kind of use this vehicle, this roadmap to have those varying conversations with your stakeholders who wanna go on that spectrum of they just wanna know low detail why, or some folks wanna know the high detail, how are we actually gonna do it? And so I think it ties into using that customer intelligence to build your roadmap in the first place and then using it as a communication vehicle.

  - Sure, and probably a communication vehicle for that prioritisation that was lit from the list as well.

  - And roadmap is a prioritisation. It's a loose prioritisation, but that's what it is. We're prioritising this right now. We're gonna do this next and we're working towards this in the future. I mean, it is a prioritisation vehicle. So I have to say I don't know that I had a, you know, really pinpointed all of the connections of the five truths to road roadmapping but this conversation has been great, 'cause it does, right? I mean, and that's probably one of the reasons why, again, as I mentioned, they kind of all feed together those five truths and build this foundation. They're so important to so many things we do. Roadmapping being one of the examples of what we do and how they all tie together.

  - I mean, and I have to admit, I only discovered the book when we got in touch for talking about roadmapping today. So it's sitting on my Amazon basket ready to buy to kind of read through and to make those links. I'm looking forward, I always love another book on product approaches and product thinking and how we do our craft better. So I'm looking forward to making those joins. So I had to find a way to ask a question early to find out what they were.

  - So there you go. Those are the five truths. Customer intelligence, relationship building, communication, judgement , decision making, and prioritisation. And as you said, you can already kind of start to make some of those connections to the roadmap.

  - Yeah, I can also see it mapping to like a product management assessment framework that I'm working on and things like that so sounds perfect. So you started hinting at, you know, different people wanting different versions. So I think you gave me two examples so far, execs and kind of probably the development organisation. Are they the only audiences or are there other audiences?

  - Great question. I mean, lots of audiences. So let's just look at the internal audience first or the internal audience base. So you've got management and leadership and depending on if you're a product manager, product leader, what have you, you're talking to your peers, you're talking to executives, and again that they wanna know where you're taking the product and how it ties to the ultimate corporate vision. And how, you know, what you're doing with your product is gonna help beat and progress bigger corporate strategic goals. So that's kind of their purview. And then again, the other end of the spectrum is the detail, the development team, the engineering team, et cetera, who are, okay, how can I think about my work going forward and how should I prioritise? And in addition, they're not just, you know, task masters, of course our engineers are our creative partners as well. So they can start to think about how we could solve some problems, right? So I'm a big believer in roadmaps not being project lists, but being kind of a visual of what problems we tend to believe that we wanna solve now and in the future. Again, as I say believe because markets change and our ideas change of where we wanna go. And so even though it's in the detail, those folks can start to think about some of the problems that they want to, or will be asked to help solve. And then in the middle, you've got like sales, you've got marketing, you've got finance, customer success, all of these other, you know, folks that are in the ecosystem that care and need to know where we're going. You know, how do they think about, you know, marketing campaigns or positioning or how we're talking about our overall product portfolio. So there are all these stakeholders internally and they fall, you know, on the spectrum. Some need just the high level. Some need the detail and some need kind of in the middle. And so it's not that you want different versions or like, you know, 50 different, you know, roadmap documents, but you do need to tailor it to maybe be a drill down for some of your audiences and just be the high level for others or somewhere in between. But that's the internal and that's where I, you know, 90% of your communication and work with your roadmap is. But some companies also have an externally shared roadmap for their customer. Some, you know, it depends on your culture of your organisation. Some, you know, don't want to share anything externally and they keep everything close. Fine, more power to 'em. But for some businesses, it's actually beneficial to show customers where you're going. It's beneficial for the sales process, the account relationship to get feedback on that and make sure that, you know, we're validating that the market thinks we're going in the right direction. And that version, an external version needs to be very... You need to be careful with that because you don't wanna give too many details. You don't wanna set the wrong expectations of timing. You don't want to share too much competitive data because while you hope it's not shared, it could be. So the external version of a roadmap can be very scaled back but can be very beneficial to share with customers, sometimes even prospects, And then depending on the industry, even maybe market analysts or something like that.

  - Yeah, I mean I think I have three external views I think of these days. Customers, prospects, and partners, which I guess analysts might fit into. Different levels of trust but yeah, it's interesting 'cause we want to potentially use it to win business, but then do we trust them? I tend to have this simple philosophy if I've shown it to anyone outside the building, I assume my competition has seen it at this point.

  - And that's what you have to decide as an organisation. I know just as many organisations who choose not to share anything externally. Maybe they'll do some verbal conversations, but they won't share an actual document externally as those who feel comfortable doing it. And so it's really just a choice and a, you know, a decision based on, you know, what the organisation feels comfortable with. But if you are going to share an actual document externally, make it as high level as possible. Make it as vague as possible while still getting some point across for customers. Because to your point, you know, I mean, nothing stays secret around here very often for very long, right?

  - And I remember in the early days of Sarbanes-Oxley, kind of rev rec rules kicking, it's like, yeah, we can't recognise the revenue on anything until we've delivered everything on the roadmap that you've shown to that customer. Okay, so we basically can't tell them anything about the future and give them anything that might help them decide,

  - Yeah, I had forgotten about socks. Oh gosh, what a nightmare. Yeah, a good intention maybe but, ooh.

  - Yeah, the organisation I was in at the time had the most conservative kind of approach to it that you possibly could have. Like, literally there were millions of dollars sat in the bank, paid by the customer that we couldn't recognise. Some of them from deals where we'd actually delivered, but the customer had never implemented it and therefore they never kind of signed off the, you know, the benefits plan and all these sorts of things kicked in. It was quite funny in some respects. So I think you've already hinted this as well. You talked about it depends on who you are. I think you mentioned product leader and product manager. So are they the people who own and maintain the roadmap?

  - I strongly believe product management owns it. So as opposed to engineering for example, because again, in my view, a roadmap shouldn't be a project list or a list of technology we're building. It should be a view of the future, the present and the future. Be visionary, right, and be somewhat high level to these are the problems we wanna solve. These are the directions we wanna go. And that is product management's job. I mean, if we have one job, it is to determine what the market needs and what we should build and what we should do about it, right? What problems we're solving, what problems we choose to solve for whom, and then, you know, how we intend to do that. And so that's product management. So I'm a big believer that product management owns a roadmap. We certainly collaborate and we have, you know, internal partners that help us build that. But we own it. And so within the product management function, does a product leader own it? Does a product manager own it? Which product manager owns it, right? That depends on the organisation. Typically it's a product manager will have a roadmap for their product or, you know, whatever's under their purview. Another product manager will have hopefully a similar format roadmap of their product. And then ultimately those roll up into like a product leader level, right? Or portfolio view of where we're going, right? So I would say the product manager owns the product roadmap for their whatever they own in the company, right? Their product, and that goes for however many product managers you have. And then ultimately there's a roll up at the product leader level that says, "These are all of our products and this is where we're going and how they tie together." You know, what are the dependencies? We're building something here that's going to benefit that. And so that bigger view is typically owned by the CPO or VP of product or whatever the head of product is in an organisation.

  - Totally agree. And that corralling everything together in a format, say consistent format can be a challenge, but we'll hold our firearm formats and come back to that in a minute. Well, maybe let's just kind of think about one other point or a couple of points before that. Things like vision, strategy, objectives, how did they link into a roadmap then?

  - Yeah, so, well there's kind of, if you think about it, there's the corporate vision strategy and objectives and then there that kind of each product line or product family or business unit or however an organisation is organised. And so you've gotta tie to all of those. And I like a roadmap that visually depicts how, you know, how we're tying to it. So for example, if you've got three strategic pillars within your, you know, let's just use the corporate strategic pillars to literally colour code or somehow depict on a roadmap that, you know, we are doing this and this is directly aligned to progressing this strategic pillar. And so, you know, again, I'm a real big believer in keeping things as simple as possible, and visually communicating as much as possible. And so something is simple as, you know, colour coding based on which strategic pillar it ties to, it aligns with and it progresses is a good way to do that. And the truth is, when you're building your roadmap and when you're communicating it and kind of the process of creating a roadmap, some of the analysis should be, do the things we intend to do tie to those strategic pillars or those goals. And if not, if we are having a hard time connecting it or communicating it and people are like, "Eh, I don't see the connection there," guess what? That's an indicator that maybe we're doing something that's not as strategic, that's not as aligned, you know, as it should be. And so we should use that as feedback into our process and potentially move that off and deprioritize that. So I think you can't really do a roadmap or at least you're not really doing it right if you are, you know, not aligning what you intend to do now and in the future with how it's helping you progress and achieve those goals.

  - Totally agree, And that visual connection, That kind of visual hierarchy is something I'm a big fan of as well. I'm a visual thinker. It's like if I'm not by a whiteboard, I'm kind of lost some days and therefore it just yeah, can be... You get so much more information in a snapshot. I've generated roadmaps to very much that visual style in the past with kind of visual... Even just simple like symbols 'cause there were multiple objectives it was driving to show the colour correlation and then people have sent it back. It's like, "Oh no, I'm writing it all out in longhand." It's like, "Oh, I have to read now." What about other artefacts then maybe that are linking into a roadmap though, JJ? Are there anything else that you can think of that kind of connects to it? 'Cause we've talked about some high level things feeding in.

  - Well, I mean, you know, one of the things that I tend to do or like to see in roadmaps if I'm the receiver of, you know, the head of product and I'm receiving something from my, you know, products and review product managers and reviewing it that way, I like to be able to drill down into more data. So again, I believe that a roadmap should be high level. It should not be documented with 50 projects on it and all this, you know, data on it. I think that completely takes away the visual communication part. So you need something high level, but that also means you need the data behind it, right? Or at least some of the audiences need the data behind it. And so whether it's an actual, you know, software programme where you click and drill into documents or however you do it, I mean, there's a tonne of different ways, but to have the ability to say, "Okay, this is what we're doing. We're going to, you know, improve our battery life, you know, that's the technology or that's the problem we're solving." Well, if you can click into that, whatever that means, double click digitally or manually into that. And you can find artefacts like the customer research and the customer validation that showed, that's why, you know, why are we doing this? Because our customers are complaining. The market is going to, you know, longer battery life kind of discovery document or a design document or something that shows that the work done that ultimately got that project or that problem on our roadmap, like what led us there? So I believe any artefact that shows why behind that's on there the first place is really important. And then for some things, depending kind of early or the... I typically do left side of a roadmap, if you will, if you're looking at it left side is the now or the, you know, short-term and then further out. So if you're on that left side, you know, short-term view, you know, you may even have some sort of requirements, user story documents, something that's you're actually working on this, you're actively estimating it, you're working on it and that sort of thing. And there's nothing wrong with having that behind the scenes if somebody needs that, right? Somebody needs to understand what's going on with the work. So, you know, those are some of the artefacts that I like to see most importantly, the why behind why is it on there in the first place? And then, you know, ultimately depending on if it's kind of a short-term view or a current view, is there work going on? And some folks would need that. Now do you have to have that? No. But usually, if you're gonna use a product roadmap as a communication vehicle for various audiences, it's nice to be able to use it in kind of one fell swoop to get all of the different questions answered.

  - Sure. Makes lots of sense. And in fact, reminds me of a conversation with a product leader I was having only earlier in the week saying they're not good enough at bringing that kind of evidence and why this thing is on the roadmap out and that's actually what they want some help with in the near future, so absolutely resonates.

  - Well see, I don't think we do a good enough job in product management, again, general statement, but I don't think we do a good enough job of tying our activities and rituals and ultimately the byproduct of that, which is the artefact to the decisions that we make, right? So we do all this stuff in product management. We have all these activities and we have these rituals we adhere to and we're, you know, married to and we have these documents that we create but none of that matters if we're not making the decision based off of it or better decisions based on it or making, you know, meeting our goals. And so we tend to have all the stuff around, right? Without having the story and the connections of, you know, how did I use this information and then, you know, document it in this artefact and then how did that actually tie to something getting on the roadmap? And that communication slash alignment is missing in a lot. And so roadmaps, they get good, you know, some people love 'em, some people hate 'em, but it can be a vehicle for that. It can be a good vehicle for telling the story of why we're doing certain things.

  - And I think that kinda links back to kind of that Netflix mantra of lead with context over control. It's like we share that bigger picture. We're not demanding you deliver roadmap. We're saying this is what we believe is gonna deliver on this context and we want you to understand why.

  - Exactly. Exactly. And it's such an important part of what we do and it really touches everything that we do. If we want our stakeholders to buy into what we believe is the, you know, market need and problem and where we should go. If you're not able to tell the story of that why, why would they buy into it, right? And so again, the roadmap tends to be thought of as this artefact, this detailed artefact, but it can be a very powerful communication vehicle.

  - Let's think about design. We've talked about a few design elements, but let's kind of zoom in on it a little bit. What do you believe are the key elements on any given roadmap, you know, the kind of content of it?

  - Yeah, so again, I tend to be very simple. The horizon, the time horizon. And again, that can be quarters, it can be years. It can be Now-Next-Later, it can be future. It can be whatever, right? Very general. But some horizon of where we're going. what is now and what is the future? The bulk of what I want to know is the problem I'm solving. So I don't personally want a project name, you know, or something like that. I get that there are some internal partners that may want it and so we may have to have that on there as well, but I wanna know the problem we're solving and in the context of, you know, the market or the customer or what have you, right? So to me, that's what should be on there. This is the problem we're solving. And then if there's an attached project or unit of work that makes sense to people, you can say project X underneath it, that's fine. But just project X means nothing to me. It's gotta have the verbiage of what the problem is that we're solving in the first place. Again, I mentioned kind of colour coding or somehow visually depicting alignment to some goal or some strategic pillar. Depending on, you know, the future part of things, you're probably not gonna have this, but some of the more current state, you might have a little bit of data on who's involved size of project, right? You can depict that visually or you can just put it on there. You know, this is a very high value, low value 'cause we should be, you know, having a mix in our portfolio. And I don't mean low value, but I just mean low, you know, this isn't gonna, yeah, this isn't gonna take us a year to build and, you know, recreate the market. Still valuable to do some indication of value, effort, that sort of thing but again, not in a detailed way. Just some sort of depiction of that if you can do it. And that's really it as far as I'm concerned. I really wanna know where we're going, how it ties together, the why behind it, meaning the problem we're solving. And then again, depending on kind of what's being worked on now, you can put some element of, you know, sizing or effort or that sort of thing. But, you know, to me that's it. Everything else should be a drill down, should be a, you know, an optional for the audience. I think it should be as simple as possible of a quick picture of where we're going and why.

  - And so visually that sounds like kind of so simple colour coding, any other kind of visuals or styling elements you like to use or include?

  - I mean, I actually, and I know there's a tonne of different tools out there that do some amazing things. And so I'm agnostic to all of that. You know, I've used some tools, something as simple as a Trello board. I've used PowerPoint or Google Slides. I mean, you know, it's just really... And I don't mean to be simple about that, but it just doesn't matter to me what tool or how we build it or how it looks. As long as it's clean, styled, you know, again, I am a kind of visual kind of stylist if you will. So I like to use our colour scheme of our business and you know, so it's not just some random like PowerPoint template. I mean, to me it's a communication vehicle and I think it should be styled and look good. You don't have to be a marketing genius to do this stuff, but I mean, you know, just use simple tools, but to put a good picture together, right? So I mean honestly, I have used Google Slides and then with links to the artefacts underneath it. I mean, things like that are just as simple to me. There's lots of really great tools out there. Productboard and Aha! and all these kinds of awesome tools that do a lot more that actually pull in data and help you build it. So, you know, those are awesome. But in terms of the actual product roadmap, the kind of one page viewpoint, it can be as simple as possible. And, you know, I do suggest making it look good 'cause it's, you know, the first impression. I think that's important. Everybody has their own creative juices, but I would make it look good, make it simple and you know, whatever tool you wanna use with it to build it, I think go for it. Whatever your company uses.

  - I also said when my co-host interviewed me, I like it to look good as well. It's like just, I consider myself to be selling to the organisation constantly. And therefore that's part of that communication, that alignment, that getting stakeholders on board. Best practise in roadmapping? What is it?

  - To me, it's making sure that when you're, if you handed this to someone and you only had, you know, you allowed them to read it without you having any verbal conversation around it, would they get the path forward? Would they understand where the product is going and some level of why. They may need some more context to the why, but would they understand the problems that you're trying to solve, and would they see some sort of natural progression of where you're going? And it didn't seem as disjointed as, you know, a few projects here and how did they actually connect together. So best practise is making sure that you could hand this document or send this document to someone really, no matter who they were, they would be able to get the gist of why you're taking your product a certain way and ultimately what that path is. So I think that's best practise. Make it as simple as possible to show the where you're going and the why you're going there.

  - What's the biggest mistake or anti-pattern that you see on a roadmap?

  - Yeah, there's a few of these. One is putting very specific dates because what's the point? I mean, I understand I've worked in cultures where, you know, you tell me when you're delivering this to the, you know, to the week. I mean, that's just not how work happens anymore. And I don't mean that we shouldn't hold ourselves accountable for quick, efficient, good work, but you know, that is not really the point of a roadmap. I mean, if you need a project list, if you need a resource plan, there are documents for that, let's do it, so don't put these like artificial dates out there or at least assign them to these, you know, units of work, so that's number one. And number two is just getting too detailed. I mean, I think it's, you know, it's all about the project. It's about the work, it's about these, you know, this is what we're doing and these are the people involved and here's the hours of work we're gonna do, and you know, all of this kind of stuff. And I could read it and know that Joe and engineering's gonna work the project but not have a clue what the project is, right? I mean, that serves no purpose for a roadmap. And so that's it, kind of getting too granular on the details and getting too overly committed to dates and timings.

  - What about a pet hate? Something you just really don't like to see on a roadmap?

  - Probably the same is a project list, right? Like, these are the things we're gonna do and we're definitely gonna do this project in four months when we get time to do it. Come on, first of all, that's not a roadmap, that's a project list. Again, perfectly fine to have, you know, a resource allocation view, but that's not a product roadmap. And two, who the hell knows what we're gonna do in four months, right? Or, or whatever, right? It may change. And if we are so static that, you know, we have been saying that this was second in queue for over a year now and so dang it, we're doing it. You know, that's not how we should be working. At least for some, most of us out there, right? There are some companies out there that have products that take years of development and I get that. So sometimes there's a little bit more concrete there, but you know, that's another kind of pet peeve or pet hate. I like that. It's more dramatic, pet hate. That I think is more like this is exactly what we're going to do in the next step. I mean, that's not the point of a roadmap and that's also setting ourselves up for some heartache.

  - I forget who's quoted this. It's like, "We're either gonna deliver in six months what we've said we're gonna do. You're gonna be disappointed 'cause it's no longer what you need. Or we're not gonna deliver it and we're gonna let you down 'cause we promised something."

  - Right? By the way, why do we even do this job? 'Cause it's so hard. But it's fun, isn't it?

  - Yeah, hard. I can't actually think of a better job. I really love what we do in product. Whose advice do you listen to about roadmapping?

  - I think I mentioned Janna Bastow earlier when I said Now-Next-Later. I believe she was the kind of creator of that idea. So a big fan of Janna Bastow. Rich Mironov has great ideas always 'cause, you know, he just ties it back to what matters in my opinion, I think that's great. Andrea Saiz is another one. and I think she works at Trent now, but she's on medium and social media. She doesn't just talk about roadmaps, I guess none of these do, but she's got these really great insights on kind of how it ties back and how it matters, and some of the big picture strategy of a roadmap. But she also sometimes gets into the details of how to actually do it, and I think that's important, right? And so those are some folks that I've personally learned from and, you know, read some of their stuff, and even used some of their stuff. I mean, I think those few come to mind, but I love the question just because I think there's... Product management is one of those things, no matter how long we've been doing it, no matter if we teach people how to do it, there are so many people that we can learn from. And so I'm constantly trying to find folks that do it a little better or do something a little differently that really sticks with folks. And so yeah, I love the question. And those are a few that that come to mind for me.

  - And that's the whole reason we're doing the channel is so we can learning the open from people and, yeah, so Janna was episode number four. Rich was I think episode number six, and Andrea is in the bag already recorded. So watch this space, she'll be hitting the channel soon. Are there any particular resources beyond people that you go to around roadmapping?

  - Well, I mean, honestly I love some of the communities out there. I mean, I'm always kind of keeping in touch with ProductTanks, Product Camps, Product Collective, Mind the Product, which is part of ProductTank or vice versa, you know, so all of those communities just, and then of course they're not specific on roadmap, but I always keep an eye out on their content. And then some of the products that serve product management, Productboard, Amplitude, you know, some of those folks put tonnes of great content out. Like, I understand it's part of their content marketing strategy and part of their, you know, marketing and sales strategy. But the truth is a lot of it's just really good content for the product world. And so I love to just, you know, kind of look at, you know, and just keep a finger on the pulse of the content that's coming out. I do content, but I can't... Like, I wrote a book and I do podcasts, but if someone were to tell me I have to write blog posts every week or a weekly newsletter, like I would just not... I'd lose it. I couldn't do it. So I love the fact that there are so many people out there that like to write and create content on a quick clip because, you know, we can glean insights from them. I just love to keep in touch with the product community. Even Twitter. I mean, I follow the... I mean it's the #prodmgmt, right? Product management. And I mean, there's so many good thought leaders out there that are in practise every day doing it. And they're like, you know, sharing insights on, "Hey, this happened today, how did you all, you know, how would you deal with it?" And that sort of thing. And just kind of reading all of that is really... It's awesome. It's therapeutic in a way. And it's also, you know, a learning experience.

  - Product Twitter, it can be, I find hit and miss sometimes. You get some really great insights and you get some real drops, and it's like, it's finding the signal for the noise.

  - Yeah, absolutely. And I definitely have had to do that. There's too many folks out there who, you know, their entire mission is to gain followers and you know, to do that, and so the threads and the, you know, 90% of the people don't know how to do this. Here, let me give you 10 steps, how to do it. You know, and all that kind of stuff. I see that all the time. It's like, what is happening? Some of it's good though, so keep looking because, you know, some of those folks just put some amazing content.

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

  - Our number one job in product management is to determine what problems need to be solved in the markets in which we do business and which ones we choose to try to solve. And then how, you know, find some creative solutions. That's it, like, if we don't do that, find the problems to solve and then work with our cross-functional teams to figure out cool solutions to solve those, we're not doing our job. And so, because that's our number one job, roadmaps are the communication vehicle of how, you know, how we can distil that down very succinctly for our folks, right? Like, our internal stakeholders. So a roadmap gets a really bad rep because it's misused so often but our number one job is to figure out what problems to solve, and how to go about solving them, you know, in a progression. That's what a roadmap is. Like, what problems are we solving and what kind of order, if you will, big picture. And so that's it, right? It should be a visual depiction of our vision of how we wanna take our product.

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

  - You know, I guess one of the things that I work with clients with and myself, you know, have had issues with is it's not always agreed upon in the organisation what a roadmap should be. So not everyone in the organisation agrees with me that it should be this, or you, 'cause we seem to be aligned on this, that it should be this high level visual depiction, you know, no dates, no projects, you know, just kind of, you know, this is where we're going and why. Well, not everybody thinks that's what a roadmap is. And so a lot of times they're looking for that project list or they're looking for something more detailed. And so the question that I get asked is how do I... Well, the first question usually is how do I get people to agree with me, right? That it should be this. But really the question is how do we get everyone to agree to what it should be in our organisation? And if we have to make some concessions on putting a little more detail on it just to get it going and to get the, you know, roadmap artefact and the idea behind a roadmap as part of the corporate DNA, then fine, let's make some concessions and maybe get better over time. But to me the question is, you know, would be something like how do I get my stakeholders onboard so that we all agree what a roadmap should be in our organisation, and it's just collaboration. You know, again, the product folks should take the lead on that. We should be saying to engineering and others, this is best practise of a roadmap and this is what we should, you know, aspire to do. You know, even if it takes us several iterations to get there and then, you know, eventually, you know, get everybody's buy-in to agree upon what a product roadmap means in that organisation.

  - It like you were in the coaching call I was on earlier today where I'm helping the coachee develop a roadmap. It's the first one in the organisation. She's the first product manager in the organisation, and it's like they want more detail and I already can't quite grasp the link to themes. So we're kind of showing them all these are themes that are further out, but if we were to work on them today, these are the ideas of solutions that we'd have that we might implement. We're not saying these are prescriptive, we're not saying these are what we'll do, but we wanna work on that theme and we'll help you understand what that could mean by showing that bit more detail.

  - Exactly. Exactly, yep. I mean, and it happens in so many organisations, right? And so that's one of the things that is incumbent upon the whole, you know, collaborative partnership. But the product team to lead that conversation and say, "We can have project lists, we can have resource allocation artefacts, but let's also have a true product roadmap," which is just, you know, the vision of the path forward.

  - So JJ, it's been wonderful talking today. I'd just like to give you an opportunity to make your pitch to the those out there. Anyone would like to get in touch, how they get in touch, how you can help them.

  - Awesome, awesome. Well, thank you. Thanks for having me. This was lovely and fun, I enjoyed it. So you can find me at my company at greatproductmanagement.com. You can also connect with me on all of the social media. You can find me at JJRorie.com/connect. Then you can find all of my social. You can also find information on either of those about the podcast, but it also has a website, productvoices.com. So that's the podcast productvoices.com. Greatproductmanagement.com is the advisory firm. And then I have my own just little connection website, JJRorie.com so feel free to go to any of those and learn about me, learn about my work, learn about the book, et cetera. So awesome, again, Phil, to be here. Thank you for the invitation.

  - Been great having you here, JJ. And we'll make sure some Amazon links down below for the buck as well because I'm sure that people will be now inspired to get out there, get a copy, and give it a read. I hope they are 'cause I am.

  - And if you do read it, I would love for you to reach out to me in some way, let me know what you thought.

  - So everyone out there, please do remember to like, subscribe, hit that bell icon, share it with your friends, and if you'd like to be here, like JJ is, reach out through info@talkingroadmaps.com or hell, just hit up talkingroadmaps.com and you'll find the signup links and contact details and so on. JJ, it's been a pleasure.

  - It's been great. Thanks, Phil.