Should a roadmap be a commitment? | Randy Silver

In episode 21 of Talking Roadmaps, Justin Woods interviews product consultant and coach Randy Silver about whether roadmaps should be commitments. Randy shares his extensive experience in product management across various sectors, offering insights on balancing flexibility and commitment in roadmaps. Key takeaways include practical strategies for creating adaptive roadmaps and the importance of stakeholder communication.

Randy is a product consultant and coach who has been working as an interactive producer and product manager across the US and UK for 20 years. A recovering music journalist and editor, he launched Amazon’s music stores in the US and UK; he’s also worked across sectors including museums and arts groups, online education, media and entertainment, retail, and financial services.

He has held Head of Product roles at HSBC and Sainsbury’s, where he also directed their 100+-person product community. Randy’s book, What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19 is out now, with all profits going to charity.  He’s the founder & co-host of The Product Experience podcast and founder/host of Product in the {A}ether, a virtual lean coffee meetup. Find out more at outofowls.com

“Maybe we should call them ‘a statement of intent’”

— Randy Silver

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

Next up we have Luke Hohmann, Chief Innovation Officer of Applied Frameworks, a boutique consulting firm helping companies create more profitable software-enabled solutions. He’s also one of the OGs of roadmapping so there is a ton of wisdom to come. So watch out for Episode 22!

• Transcript

  - Hello and welcome to the Talking Roadmaps Channel. My name's Justin Woods, and I'm one of the co-hosts here. Really excited for you to join us today. This is the channel where we talk about everything to do with roadmaps, from the good, the bad, the ugly, some expert practitioners, some tools and tips as well. So if you're interested in roadmaps, this is the place to be. If there's anything that we say on today's chat that's, that resonates with you, please do send us a like, maybe subscribe to the channel if you think there's lasting value there, and drop a comment down below. We love to hear things that have resonated with you guys, or whether you think there's something that I, and my amazing guest, Randy Silver, are saying that's a bit controversial and you don't agree with. If you wanna get in touch to take part, please do use our email address on the Talking Roadmaps website. Or again, just drop a comment down, we'll get in contact with you, and we'd love to have you in the hot seat where Randy is today. So without further ado, Randy Silver, welcome to the channel, thanks for joining us.

  - I've been looking forward to it. Thank you so much.

  - Absolutely. So, Randy, for some of our listeners, you won't need an introduction. You've got a rich tapestry of experience in the product world, an expert speaker, a host of a podcast, or co-host of a podcast as well, and of course a director of your own product management and training and consulting company. But in case I've done you an injustice, maybe you could just take a moment just to introduce yourself.

  - No, that's pretty much it. If my voice sounds familiar, it's because I co-host "The Product Experience" podcast with Lily Smith, the podcast "From Line to Product". I've done talks at lots of conferences, I wrote a book, I've been at head of product roles at a few places, but for the last few years I've been mostly consulting and coaching.

  - Fantastic. And a really enjoyable thing for us to do as well. I find quite a few people in product management kind of feel like we're cut from the same cloth, a little bit of extraversion in there and being able to kind of communicate with people. So Randy, I know we're gonna have a great session today. Maybe without further ado, maybe we kind of go in and talk a little bit about that then and kind of get straight into the meat of today, which is, from your perspective, what do you think the purpose of a roadmap is? Or what has your experience of a roadmap been?

  - Oh, those are two very, very different things. I think there's a real problem with roadmaps actually, in that the theory of them is fantastic, but the actual use is, it's pretty awful most of the time. You know, we talk about them like they're this thing that's going to solve problems, and really they create more problems than they solve half the time. We treat them as a dogma, you know, as we, they're almost a religious or holy text, this thing that the product manager goes away and comes back with and presents and nobody pays any attention to it, or everyone interprets it differently. It's just like religious texts for them, for that matter. So yeah, the theory of it is fantastic. And I'm a big fan of tools that do a job, but most tools and roadmaps are just another tool. Don't do the job that they're actually designed for.

  - You're absolutely right. You know, the interpretation of those is a massive factor. We've talked about some controversial things recently on the channel, like MVP, you know, MVP is something that is well-meaning, but often bandied around or misunderstood and sales will have a different view of it to product. And I tell you, I've been there before. I've created some of my first roadmaps and it has caused me more pain than they've been worth, and they've given me enough, you know, more rope to hang myself as well, right?

  - Can I tell you my favourite MVP story? It's a really short one. It was a, I forget who was, but it was a consultant who convinced a client to create a minimum shoddy product. And they went through the entire thing and at the end, the client came back and said, "I don't understand what is the difference between this and an MVP?" And they said, "Well, if we called it an MVP, you wouldn't have let us do this janky half done thing to prove the point, you would've done a version one. But because we called it shoddy, you actually let us do what an MVP is supposed to be."

  - Perfect. And probably sales and marketing weren't all over it as if it was that new next shiny. So it sounds like, you know, roadmaps have been a challenge. It's a plan that often will trip us up as well. So, kind of, have you had some, seen some bad experiences of roadmaps and experienced some yourself?

  - In general, actually the experiences haven't been too bad. I mean, I try to treat them well. I try and do what I can with them when I've created them. I try and get other people to create them. And I still, for all the badmouthing I'm doing, I still, when I'm managing product managers or I'm coaching someone and I wanna see what they're planning and have the structured conversation, I still wanna see their roadmap. Because it's a communication vehicle, it helps me understand what they're thinking, what they're planning, what their priority is. The difference is, I don't treat it as an actual project plan, it's a statement of intent. And maybe we shouldn't call them roadmaps. Maybe that's what we should call them, is this is a statement of intents. This is what we are thinking right now. There is an actual definitive need for your partners in the company to know what you're doing, but that's not your roadmap. Your roadmap is a little woolier and higher level, and I like to have a second document. I'm really bad at creating that second document. I should never own it. This is why delivery managers exist, and I love delivery managers. You should also have a release plan or a project plan that is much shorter term that says, "This is what's coming. This is what we have a high degree of confidence in. This is stuff that we all need to commit actual dedicated resources and block out specific time for, rather than theoretical budgeting and potential stuff that we're doing in the roadmap."

  - You mentioned something there that really resonated with me, which again is some really great language, a statement of intent. It says, "This is where we think we want to go. It's our intent to go there. We're not guaranteeing that we're going there." I really like that. And also wanted to share with you something that we spoke on a former episode with, with a gentleman called Simon Wikis, which he said is that the roadmap forms part of corporate record. And I actually like that, which is, yes, our roadmaps will be forward looking, but by capturing what we've also delivered can help as a corporate record, if we have new leadership come in that suddenly decide that we want to do this next big thing. Well, if we've already tried that a year ago, we can say, "Well, look, we did try this a year ago and these are the things we found," rather than not being able to demonstrate that we've tried this before and all trying to do the next big thing that we know is going to rinse and repeat what we've done already. So the corporate record I think was really nice because historics are great, but yeah, you know, we, it's not a release plan, it's definitely not a project plan, and that's sometimes people's go to when they think of a roadmap there.

  - Yeah, absolutely. It can't be , that is something else.

  - We do love a delivery or a project manager as well. So talk to me about, if we think about the roadmap then in the loosest form, which is that statement of intent with where we're going forwards. I think you mentioned already product management have a part of that, but who do you think of the audience?

  - That's the other controversial side because if you try and treat everybody the same, you're failing. Everyone has a different need for what they, what they're trying to do. Sales has one way that they're looking at things. Marketing has another. Ops has a different way of looking at the world. And you need to communicate to each of them in their own language based on their own priorities. So ideally you have a corporate strategy or a divisional strategy or business line strategy, and you're talking in response to that, "These are the problems that we intend to solve." And then for the things that you're closest to, you probably have a way that you intend to solve it. And you can give a rough timeline. "This is the type of stuff we think we're, that we're concentrating on this quarter, this half year." Potentially you can go a little bit further out and say, "These are the things we currently intend to solve later." The problem is other people take that as a commitment. There's, I'm going to totally butcher his name, but there's a brilliant guy named Javier Grillo-Marxuach. And I, if I'm pronouncing it correctly, he is not a product manager. He actually is a producer and a TV screenwriter and a showrunner. He was on "Lost", he did a show called "The Middleman", he did the recent "Dark Crystal" thing. He's fantastic if you're into the type of genre stuff that I love and he does. He wrote an essay, it's free, you can find it just by Googling it. It's called "The 11 Laws of Show Running". And it is one of my bibles for product management because it talks about all the things you need to do to be good at your job of leading a TV show. And it starts with the whole idea of you're breaking, you set the intent for a series, or in the US, a season, and you set the arcs for that, which is kind of your roadmap. And then you set different character arcs and storylines and you break down the episodes into what you're gonna do in each of them. And you do all these different things. And he has lots of great stuff about explain your plan early and often, you know, be really clear about it, expect varying levels of competency from people at different levels of seniority and experience. But one of my favourite things is if you give a writer of an episode a plan, and they come back and write a script that totally changes the plan, they have done a real disservice to everyone else on the production because costumes and set building and scenery and scouting and everyone else has gone out and taken the loose spine, you know, essentially the roadmap as a work order and started making plans around it. And if you come back with a script that totally changes the locations, the costumes and everything else, you have wasted a lot of time for people. So it's coming back and it's doing that. It's what is the level of faithfulness? Be conscious of what kind of things people are hearing when you give them the roadmap. So if you tell sales something that, you know, "We are planning to do this later this year," they are gonna tell their customers that. So you have to be really careful with what you say to whom and how you say it and how you qualify it and what they hear and how they're gonna use it.

  - That's a mic drop moment right there. I absolutely love that because product management is a level of storytelling, you know, so what a great analogy. And so in your mind, who owns a roadmap and who maintains a roadmap?

  - Well it is the product manager's job. And I saw a little bit of an episode you did with Janna Bastow and talking about there isn't always someone who specifically has that title. It is, product manager is a job title, it is also a role. So sometimes it's a business director who's doing this, and sometimes there is someone called a product manager that isn't actually doing the product manager's job, but it, the person who owns the roadmap is the defacto product manager for this. And they are the person who's looking at the strategy and determining how resources and energy are going to be spent on on what you're doing. And that is the most important thing. And they're the one who's, you know, essentially the keeper of the flame. If, you know, they should be able to articulate it out to everyone else so everyone else has a pretty good idea, but if there's ever a question on how to interpret it, it goes back to them.

  - You mentioned it's a job title or a role, that's quite right, you know, there's someone gonna be holding that flag or that baton within the company, whether it's formally by name or role or something otherwise.

  - And if you have the title of product manager and you think you're their product manager, but someone else is doing that, then just be realistic about it. Understand that that is actually their job and if you want the job then you need to speak to them about it or you need to get the promotion.

  - Great comment, sir, as well, especially maybe for early stage companies where those boundaries are not quite so well defined.

  - Yeah, I don't think it's only the early stage companies. You've worked in enterprise, I mean, to come, and I'm sure you knew that the business director or the business owner, the person who was responsible for PNL would overrule you and have their own concept on it. And in that case, you know, no matter what your title is, fundamentally they're actually doing at least that part of the job.

  - A hundred percent. And actually, I experienced that from my time in one of the large companies I worked for where there was sort of directorate for strategy and planning, and then there was another directorate where digital lived and the product managers lived. So who owned the strategy and planning for digital? Because then you had two different departments and so, you know, you could end up coming against some conflicts or some loggerheads there because, you know, you're trying to define the strategy as a product manager, but there's also a dedicated strategy and planning function that does that as well. So that's quite true. You know, and we find this a lot when we work with different clients that you have the organisational structure and then you have the power structure, and they can be very different within these companies. I wanna talk about something you mentioned at the beginning, which, again, really resonated with me, which is kind of the vision, the strategy and the objectives. You know, the roadmap is not just a single document or a single page. There's a lot of other things that are critical here. What do you think the relationship is of a roadmap to say the vision, the strategy, and the objectives? How do you see those two playing, kind of reinforcing each other?

  - I like Teresa Torres's framing of all this and her opportunity solutions tree. It's a really good way of looking at it. The vision is something that shouldn't change, or shouldn't change very often. It should be, you know, ideally five to 10 to 20 years in duration depending on the maturity of your business, or potentially even longer. So the roadmap is there in service of a vision, but it is probably much shorter term. It's this current business cycle that you're looking at. Maybe you have some theme for later, but those are very low fidelity and just an intent that, "Oh yeah, we're not do," it's more of, "We are not doing this now rather than when we intend to do it. We know it's important and we know it's something that we want to build on if everything aligns," but it's, yeah, that's the, if you have now next leader for your roadmap, this is way later sometimes. So that's vision, then objectives and things like that, you know, sometimes you had, depends, again, depends on your business, depends on the cycle, depends on your industry. Some things move incredibly quickly. You know, I've worked in retail before where it's intraday or weekly cycles for some of it, but then you also have worked for a big grocery chain and so, you know, sales and promotions and things like that would, could be incredibly quick, but infrastructure was still a long cycle. So you had both planning cycles at the same time. So objectives can be really short or they can be pretty long. The roadmap is the thing that helps describe how you are going to hit those objectives. So I promised I would contradict myself quite a lot. There is the idea of what is the problems we're going to solve and the roadmap will should detail that. But for the things that are in the three month or so timeframe, it's not enough to just say, "This is the problem we're going to solve." It's also, "This is how we currently intend to solve it." Now whether you're detailing that in an active roadmap and updating that all the time, or whether that is a more informal document, whether that's something that's just your, you know, if you've got a scrum board and you do epics, great, I really don't care how you do it, I don't, I've seen teams work in any number of different ways. All these different frameworks and tools that we use are just ways to ensure that we're communicating well. So if you as the product manager and your design team and your dev team are all able to communicate psychically and you all will just know what people are talking about, then you don't need any documentation whatsoever. You know, if it's three of you that are best friends and never have any miscommunication, great. But as you start to get complexity in lots of people, having some form of documentation is useful, but just because you write it down doesn't make it useful either. How many times have people created a document that no one's ever looked back at?

  - All the time? Yeah, absolutely. And even using tools, you know, and so, you know, might be seen as kind of the tool guy, a lot of the time it's like, and Rich Mironov mentioned this as well, you know, how many times have people realistically, even if you're spoonfeeding them these views and giving them the links, you can't trust that they're gonna be going off and finding the information. So it reinforces what you said at the beginning, which is that roadmaps are a communication and an alignment tool, and it doesn't matter what they look like as long as they do that job of communicating and aligning.

  - And it comes back down to perspective. If you're the product manager for one area, that is your world, that is your life, you are into every detail of it. And you want to tell everyone about your roadmap and what your plan is for that, that may be one small piece of a much larger product or one product in a much larger business. And the people, your stakeholders, the people you're communicating to, they don't wanna go and look at 20 different roadmaps and try and coalesce everything. And yes, that is someone else's job to try, ideally pull it all together and talk about the strategy at a higher level. There's a couple guys with a great podcast, I think it's called "Agile". Oh, they, they wrote the book "Agile Conversations". Anyway, they talked in one episode about the idea of briefing and back briefing. So what we do generally with roadmaps or from CEOs or anyone else, is we are very good at disseminating strategy down or out. We're not very good at understanding how other people understood it and what they plan to do with that information or what to do about it. So the idea is that you brief the information out and then you ask people to come back to you with a short document, you know, a one pager, say what do they understand from it and what do they intend to do from it? And you as a leader, if you get a bunch of things back and you see that there are contradictions or things aren't going to work as expected or people didn't understand it, that's your opportunity to fix things now rather than three to six months from now when it's a real problem. And I love that concept.

  - Let's talk a little bit about the design of roadmap and so kind of what do you think are some of the key elements or content of a roadmap?

  - I've seen different ones in different places. I've seen people do them in Excel or Sheets. I've seen them do in PowerPoint and slides. I've seen people use various tools over the years and I've seen them live on walls in offices back when we actually, you know, worked together in places. I don't, again, I'm sorry, I don't care. I mean, I like the idea of now, next, later as a concept and that is definitely the theme that I prefer, but it's whatever works for the people that you're communicating with. And if you come into a business and they have something established that works for them and that's how they plan and you come in with a totally different format, they're just gonna ignore it. So not very, I'm pretty, let's put it this way, I'm pretty agnostic about it. The point is, are we having the right conversation as a result of it? Are people paying attention to it? Are people using it? Is it useful? If that's the case, then the design works.

  - Again, fantastic advice. You know, it can often be a real leap of faith or a big step, it's a huge step change for organisations. So let's just use whatever format or whatever nomenclature or graphing or whatever the business are used to already, use that tool to communicate.

  - And if that's not working, you know, if they've been using it forever and it's not serving the right purpose, talk to them about that. Say, "Why are we still doing this? Can we try a different way?" Get them on board with it. Understand what is the problem that they're solving with it and why do they like using that format? And then talk about the problems with the format and, you know, point out the failures and then you can get them on board with change. Just bringing them the document that is the product management best practise, the one that we like, that doesn't mean that they're gonna use it.

  - Such a good answer, Randy. Thank you. Let's talk about best practises in roadmapping that you've seen. So we've obviously, you know, seen some great examples. We've been burnt by bad examples ourselves. What are some of the best practises you see in roadmap?

  - I think the, again, I'm sorry, I'm not gonna give a very, very prescriptive advice on this. It's what's, if your team and the teams you're working with and your stakeholders all have a pretty good idea of what you're doing, what you're trying to do and why you're trying to do it, then it's working great. If not, then we need to apply our, you know, our basic product management principles hat to the roadmap as well and say, "Why is this not solving the problem? How do we iterate to solve that problem? And what can we do differently?" And whether that's a document, whether that's meetings and conversations, whether it's sessions, whether it's co-creation, it, again, it doesn't matter. I like living roadmaps, you know, things that aren't just published and then forgotten. An idea that you can go back and refer to it. I like the idea, you know, if you can use something like Muro or Mural, people can come back and post questions and comments on it. They can do it in some of the other platforms as well. That stuff is great. But again, it's a vehicle for having good conversations and that's it.

  - A hundred percent. Succinct but so true. And it, like you said, it's agnostic of any tool. It's just what's really working. How about what you think some of the biggest mistakes may be that people make in roadmapping. So things that they've just done that's caused them challenges.

  - I'll go back to the religious iconography of, you know, Moses coming down the mountain with the tablets, you know, going off and consulting with the Lord and coming back and saying, "This is it that we have spoken," and doing it on your own. Not, it should be a collaborative effort to come together and it should, nothing in the roadmap should come as a surprise to people. There should be conversations all the way along the way and you bring people on the journey. The artefact is the end result of the process, not just something. The other is assuming, you know, sending it out or posting a link somewhere and just assuming that people have seen it and actually understand what you mean by it. And then the last one is I think, you know, if you are not doing this as part of a concerted effort, if you're a part of a larger company and there's multiple other product managers or teams and you're not doing this with any conversation and coordination with them, then you're just gonna have lots of competitive, lots of things in there that are competitive, that don't agree with each other, that are gonna cause alignment problems further along the line. So yeah, again, it's conversations.

  - Isn't it incredible? And I've been in a situation as well where, you know, wearing the product manager hat, you go into a room, you create this roadmap, you outline your plan, there's no, you know, no involvement from other people or not enough people. And then suddenly you come out with this 12 month delivery plan and they're like, "Great, off you go then." And it's just like, yeah, there's no conversations, it's done in isolation. Just the wrong thing to do.

  - And sometimes it's not a bad thing to go into a room and do a first approximation and to have a, you know, depending on who your partners are and the types of relationships you have with them, you can go and do that and say, "This is my first pass at this, let's use this as the basis for a conversation," that can work great. It can also totally backfire because people assume that it's, that there's rigorous thinking in there and that they don't have the opportunity to put in input, they can be dispirited by it. So it can work both ways.

  - Maybe it's the minimum shoddy roadmap and then, "Oh, there we go from there, right?"

  - Yeah. "Lemme get my crayons out."

  - What you've described there is a great anti pattern as well, or a bad practise of what people do. Do you have a pet hate that you just hate to see on the roadmap? Any roadmap that you just want to get it off there?

  - Dates, specific delivery dates. I'm, again, they're incredibly important. They have a time and a place, it's just not on a roadmap. It's on a release plan and you should have both documents and they should be linking to each other at all times. You should, you as the product manager should own the roadmap. Your delivery manager should own the release plan and you should always be best friends with your delivery manager.

  - Boom. If we could underline that quote that you just said there, we, obviously we can't do it on audio, but completely agree with you on there. Randy, you're a learned man, done a lot of these as your role. You've experienced them as well. You've obviously got some fantastic advice there, but whose advice on roadmapping do you listen to? As an expert yourself, what sources do you take from?

  - Oh, there's so many people out there. We've got the book by C. Todd and Lombardo and Bruce McCarthy and a couple of their co-authors is fantastic. Janna Bastow from, yep, "Product Roadmaps Relaunched". We've got Janna Bastow obviously from ProdPad and her cohorts are really good at this. To be honest, I'm a member of a few communities, "Agile in Ether", I run one called "Products in the Ether", a couple other communities like that. It's fantastic whenever I have a question just to go after them and say, "Hey, how do you do this? Show me an example or talk me through it." And there's always someone who's willing, who's been in a similar spot, who's dealt with something. Not roadmap specifically, but retros. I was always really bad at retros and recently, and I was complaining about it recently and someone's posted that she loved retros. We grabbed 20 minutes, she showed me her format. I ran a retro the following week and it was the best one I'd ever done. It's easy to listen to, to read the book, to listen to Janna and I absolutely encourage you to do that. But I'll also tell you, just talk to other people who are practising and ask them how they do it because the people who, you, myself, Justin, anyone else that you're listening to on talks and podcasts, we all have some good advice, we've all lived through it, but we're talking about our experiences and what's worked for us. Talk to someone who's closer to you in your specific situation and you might even get better advice.

  - Yeah, yeah, that's phenomenal guidance there, Randy. And you know, it turns something that we typically wouldn't want to do into something that you enjoy because it's a better way of doing it, a different perspective. And I think again, it comes back into what you said about applying product management skills and expertise to ourselves or to what we do. Just go and ask people, who's it doing well for? I used to find that when I was creating proposals. I didn't used to enjoy them. Now I absolutely love them and it's just a different perspective and just getting that guidance from someone else. I think that's great. Thank you for sharing. So are there any kind of roadmapping resources that you use or recommend, or actually maybe just product management resources in general. You mentioned some groups there. Where could people go that you kind of some resources that you would recommend them to go and see?

  - My first port of call for anything is usually just going to the "Mind the Product" site. Now granted I do their podcast, I've been affiliated with them for a long time, but it's a great starting point if nothing else. Beyond that, I find I've got a good social network, so LinkedIn and Twitter, asking a good question, I'll often get good answers, but I've worked hard to make sure I've got a good community there that I can talk to. And then I've got a few Slack groups and meetups that I do this with, I mentioned earlier. So "Products in Ether", the one I run is at pitta.social and you're more than welcome to attend that. It's a free monthly virtual ween coffee for product people. And yeah, I think it's, and I've got, to be honest, the other thing I'd recommend, it's something that I've heard from a few different people, Gibson Biddle recommends it and a few others, is the idea of having a personal board of directors or a small group of people that are peers of yours that you can chat with on a regular basis. Even if you are in a company, sometimes you want to talk to your peers and sometimes you need a safe space aside from them. So finding a few people that you're comfortable with is great. The other one is, and this will sound self-serving because I work as a coach, but I also get coached, and I highly recommend coaching, whether it is formal and you pay for it or your company pays for it or it's informal. You can do peer coaching with a friend, with somebody else and just trade advice and have a safe space to explore things. So I think coaching is, you know, for anyone who wants to get better at their craft, it's a really good thing.

  - Coach and be coached. To coach people reinforces learning, to be coached gives you that support and that ability to learn new techniques. I think that's great. Randy, I'm just wondering kind of as we look to close out, whether we could kind of think about distilling your philosophy of roadmapping into one to two sentences. And we've had a really varied discussion though, which I've loved, so, you know, don't hold back here, but how would you distil your philosophy of roadmapping into just a few sentences?

  - I think it's a little more general than just roadmapping, but all tools are awful, but some are useful and road mapping can be both awful and useful. It is a necessary thing to make sure that you're telling a story, but the format can be whatever it is. It it's not doing the job, then it's just an artefact.

  - Reminds me of something that somebody told me way back when in my career, which was, "A fool with a tool is still a fool," and I just loved it, it was like, "So true," you know? a tool is just there to expedite process and we should be doing that process already. So that's brilliant. So Randy, I've absolutely loved chatting with you. Thank you so much for kind of taking us through your experiences. There's been some real gold in there as well, so I'm really excited to share that with the audience. I also wanted to do a courtesy of giving you a chance just to kind of tell us a little bit more about what you do, maybe pitch to our audience how you can help them. I know that you run your own company Out of Owls and obviously you are within a bunch of different social networks as well. So just tell us a little bit more about you and how you help people.

  - As you said, you can find out more at my site, which is outofowls.com. My son named it. We were, I was teaching him about brainstorming. I did a talk a few years ago about God's superheroes and product managers and I said, "Athena is the featuring goddess of product managers for various reasons. Her spirit animal, her symbol is an owl." And we are trying to come up with an idea of a company named based on that. And we were brainstorming as we walked to school and then 15 minutes in, he looked at me and said, "Daddy, I'm sorry, I'm all out of owls." But yeah, I work a lot with communities, with mentoring and teaching and I also do consulting, sometimes interim roles and various different kinds of consulting. And if I can't solve your problem for you, I often partner up with people or can refer on to others. I've got a great network thanks to the podcast. The one other thing that might be of interest is a couple years ago I wrote a book called "What Do We Do Now?" It was written at the beginning of lockdown and the idea was that everyone was a little confused as well. Their roadmaps were suddenly very wrong and they didn't know what to do. And the main theme of the book has nothing to do with Covid or lockdown, it has to do with any time you are in a point of pivot or crisis, what do we do? Well, we have all the tools. Go back to basics, do your discovery, ask the right questions to have the right conversations. It's a short book and all profits from it go to charity. So, you know, if you're interested, please do check it out.

  - Well, we'll be sure to put those links down below. That's certainly gonna be one that's on my reading pile along with some of the other books that I've had here and I'm touching now have piled up. But Randy, thank you so much. We've absolutely loved chatting with you today. Just before I close out, so again, Randy, massive thanks, personally, I'm really pleased to be part of your network. I'm really pleased to be part of "Product Managers in the Ether" as well and to attend those groups. Again, it's kind of that community thing that is so important. A reminder to our audience. I hope you've enjoyed today's session. If there's any thoughts or things or quotes, mic drop moments that have completely resonated with you, feel free to drop those down below. You know, we're not all pro roadmaps here. We'd love to hear the good, the bad and the ugly for them. And if it has resonated, please give us a like. If you think that somebody needs to hear something that Randy or I have said, share this video with them and do comment down below as well. If you'd like to take part, if you'd like to be in the pleasurable position where Randy is today, drop us a line, drop us a something in the comments and we'd love to have you on the channel. But for the moment, Randy, I've absolutely loved chatting with you today and I look forward to being part of your network in the future.

  - And you, Justin, thank you so much.