Is the roadmap owned by the product team? | Adam Davis

In episode 51 of Talking Roadmaps, Justin Woods interviews Adam Davis, CEO of Colab Cohorts. They discuss the ownership and purpose of roadmaps in product management, emphasizing their role in aligning actions with strategy and company goals. Adam shares insights from his extensive career, including his experiences at Productboard, Hootsuite, and Trade Me, offering valuable perspectives on scaling B2B SaaS platforms and the importance of building products that deliver real value.

Adam's journey kicked off in sales, where he learned the hard lessons that shaped his career. The key takeaway? Focus on building tools that deliver real value.

Fast-forward to today, and he's the CEO and co-founder at Colab Cohorts. Most recently, he was a Director of Product at Productboard, where he led and grew outstanding product experiences and people while navigating the challenges of scaling a B2B SaaS platform from $20-$50m ARR.

He's navigated the dynamic world of startups and global tech companies like Hootsuite, Trade Me, and Rightmove, honing my skills and embracing the chaos. He's passionate about 0 to 1 products and scale, dedicating his career to bringing new ideas to life in high-performance teams.

Now, at Colab Cohorts, they're on a mission to nurture product professionals from day one, offering a platform for top-notch learning experiences. Beyond the hustle, you'll catch him chasing waves (not as much as I'd like) and savouring food adventures with his better half.

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

Is the roadmap owned by the product team? | Adam Davis

Justin Woods and Adam Davis

In the next episode we are talking to Raphael Weiner, he is a Co-Founder at Orbital. So watch out for Season 1 - Episode 52!

• Transcript

  - Welcome to the "Talking Roadmaps" show. I'm one of the co-hosts, Justin Woods, and in today's special episode, I am joined by Adam Davis. Adam, welcome. Please tell our audience a little bit about yourself.

  - So, yeah, my name's Adam Davis. I'm based here in London. I was kind of born into product. I won't bore you too much, but I started my career in my early twenties working for a company called Trade Me, and that's kind of where I sunk my teeth into product management for a company in New Zealand. And then since then I had quite an interesting, and I think probably a little bit of a lucky career path in terms of trying to start my own startups, from travel and accommodation websites for surfing, to working at Hootsuite at a really pivotal time and being able to bring one of their flagship products to market and kind of stepping up through the career ladder into a senior product manager, and then working here in the UK for Rightmove, and then most recently working as a director of product at Productboard. So I've seen it all in terms of working in B2C, B2B, working in small scrappy startups to kind of publicly funded companies, so yeah, excited to share some of my perspectives today on product and roadmapping. And right now, most recently, I'm the CEO of Colab.

  - Fantastic. Yeah, that sounds great. And yeah, what an awesome career, global movements around, working for different companies, kind of working at some pivotal times. Adam, I can't wait to dive down into those areas and chat with you about them. If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. So Adam, let's jump into it a little bit with possibly kind of the top level question, which is from your perspective, what's the purpose of a roadmap?

  - Well, look, I think it depends, right? It depends on the stage of company, what role you're in, in terms of directly with your team, working more with senior leadership or executives. I think we'll probably get a little bit into that. But ultimately for me and from my experience, the purpose of the roadmaps, it's about clearly demonstrating what actions you are taking and the investments you're making to deliver against your strategy and your company goals. And in my experience in kind of how lots of product teams use them, it's about communicating what are those problems you're investing in and what you're not doing. So it's a really good conversation starter, it's a really good framing exercise for the rest of the organisation, and I think finally it's a really good artefact to help with alignment. So alignment in terms of being able to make decisions at a real kind of macro level with your team, or kind of building out, making smaller kind of micro decisions with your kind of individual squad as well. So I think ultimately it's about what are those actions and those investments you're gonna take to be able to fulfil your strategy and those objectives, and then how does it tie into kind of your wider vision in terms of what you're trying to achieve. So there's many different ways to do it. I know we'll chat a little bit about that, but that's, I guess that's kind of some of my thoughts on the purpose of it.

  - Yeah, great, great response. And the classic, "It depends," right? because it does. That's the beauty of these things as well. The one thing that I picked up in what you said there is it's very much what we are doing, but also what we're not doing, and I think that's really important in terms of focus, strategy, direction. Some of those things should be within the strategy itself, but the roadmap should clearly articulate what we're working towards and potentially what we're not gonna work on right now. It's about focus as well. Nice. So if the roadmap is about that alignment, communication, direction, who do you think the audience of a roadmap typically is?

  - I think this is, probably a lot of it depends on this.

  - We wouldn't be product managers if we didn't.

  - But look, I'll break it down kind of what I'm seeing and also in my experience as well, working as like an individual contributor, and then stepping up into more kind of senior leadership roles. So I think there's three kind of primary audiences that I like to think about or talk about with folks that I'm working with. So the first one is your direct team. So if you're a product manager, being able to build and craft that roadmap with your team is so important. First of all, A, you should be setting the vision with the team in terms of what do you want to be true in the next 6, 12, 3 years, whatever stage you're at; B, what are those problems that you're gonna solve; and then C, it really, at that team level in terms of that audience, helps drive that discussion in terms of what is the sequence of the problems, what are the dependencies, how are we gonna work on it together. So while the direct kind of squad, and when I say squad, it's like a designer, engineer, et cetera, et cetera, whoever makes up that team, that audience there, you're gonna be co-creating with them. But for me, that's one of the most important audiences. As a product manager, you need to be showing this every single day, every single sprint. I used to ask my team, I'd be like, "What's coming up in the next few weeks? What's the problem that we're solving?" So I think the second audience I would like to think about, once you go beyond the individual team, it's just a larger EPD. Now, that's how we refer to it at Productboard, engineer and product and design, so your R&D teams. The audience there is a little bit different in terms of what you're communicating, but that audience cares deeply about, A, what problems you're solving, what technologies you're using, when are you doing it, and who's doing it. That audience cares about different types of information, but it's a very important audience to think about in terms of the person who's creating the roadmap and how you build it. I think we'll talk a little bit about tools, I'm assuming, but that's where you might use different types of language or communicate it slightly differently. I think building on that, you then have the wider business, so folks outside of R&D. That could be, I don't know, the customer success team, the sales teams, the customer support team. Again, they wanna understand similarly in terms of directionally where you are going, what are you doing, what are you not doing, how we can use that information to speak to our customers, what are those trade offs. And then finally, exec or senior leadership, and I think for them, this is kind of the fourth, I guess, layer I would think about in terms of roadmaps, but for them it's about understanding those core things, what is that progress you're making towards their objectives, how does it really align to the business and company strategy, and then finally, what are those investments we're making at different levels. So when I previously have been working with my teams, we kind of think about those four different layers, and always ensuring that, A, you're connecting the objectives to the tactical work, but you're being really thoughtful about what levels of detail and how you communicate at each one of those levels. So it's a lot of work, but they're really important, and I think one of the key things I'll add to having like these four layers of roadmaps is you need to make sure that there's consistency there; A, consistency, B, they clearly kind of align to the company goals as we were saying before, and then finally that you're not wasting time on these artefacts, because I meet and speak with so many product people who are just putting their time in the wrong areas and they're spending hours updating roadmaps even if they're using a tool. So I think that's one thing to bear in mind.

  - Yeah, massively. What a well-thought-out answer, Adam. Thank you for that. So kind of the three to four different audiences: team, EPD, engineering, product, and design, the wider business, and the exec and leadership. And I think what I heard there is it's really important to consider each of those audiences and what they need, and then to tailor the views and the information you give them to make sure that they have what they need to make those decisions. So, but then that consistency across the piece, which ties it all in and gives us a single version of truth. That's a great response.

  - Yeah, exactly. And that's just, it's such a key role of the product manager, and this is what makes it so difficult, but it's about, as the PM and as the team, making sure that there's shared ownership around creating the roadmap, but also getting feedback quickly on how you're positioning it, how you're talking about it. So as a product manager, that should be such a fundamental part of your job, because, A, it's about keeping those micro commitments in terms of what you're trying to achieve and do and demonstrating that, but, B, it builds that trust and that accountability with the rest of the folks. This has skipped a lot. It's talked a lot about on LinkedIn and blogs and stuff like that, but this is really how, in my experience, how you build trust, through really demonstrating what you're doing or not doing and then delivering on it.

  - Yeah, that's a great take. So from that perspective, who owns and maintains a roadmap then? Does that sit within EPD or the team? Where do you think that should lie?

  - Look, I think the reality is it generally sits with the product manager. I really feel like it should sit with the whole team. Like the best roadmaps in terms of well-thought-out, executed, ownership, autonomy, all that jazz, are when they're owned by the trio, so the engineering, product, and design manager. And they all add their expertise to be able to build and execute on the roadmap. So I think that's ideal in terms of like a North Star of what we would want product teams to be able to operate in. And whenever I've worked in a really high-functioning product team and been fortunate to work in one of those, you have that shared accountability. I think what we see a lot of the time, or what I see a lot of the time is it's generally the PM who's responsible working with the engineering manager. So the engineering manager's there trying to figure out how many sprints it's gonna take, is it feasible, what's the sequencing, what are the dependencies, and then they'll kind of work together on it. So I think that's at an individual level. I think going up kind of one step from that, it would be certainly generally fit within like head of product directors or product group PMs. They'll be responsible for their portfolio area and then that would then lead up into a VP of product. So I think at Productboard as an example, our VP of product would kind of set the scene in terms of what we're doing for the year, and then at a director level, you would have each of your kind of portfolio or product areas, and you would be responsible for building, maintaining, and accountable for your specific roadmap based on the strategy that you've created for your area. But I think ultimately the state you want to get to is that every team should be accountable and have the autonomy to create, build, and execute on the roadmap based on guidance that they're given at a strategic level.

  - What a great response, and actually ties into kind of the next logical question really, which is what is the relationship of the roadmap to those strategic artefacts? So vision, strategy, and objectives, how does the roadmap tie into those things or how should it?

  - It's hard. It's really hard in practise. Like I really feel for people who are trying to improve on their career and they're working in a company and they're not getting as much support as they want, or folks that wanna step into product management, because as we talk a lot about vision and strategy and objectives, and I feel like OKRs are kind of, they peaked and then they're kind of disappearing a little bit, and they're maybe resurfacing a little bit now. But I think my perspective on how I think about it or how I like to think about it with my teams is the vision kind of helps paint the picture of where you're going, what you want the world to be. Like when you wake up in 12 months or two years or three years or whatever your timeframe is, what's gonna be different, you know? What's gonna really excite you about getting up in the morning, going to work, motivating your teams, and putting the effort in. And I think ultimately with the vision, you need to make sure that you're thoughtful in terms of where you currently are, how feasible is it, all those other kind of questions. Now, vision is generally, I dunno, in an artefact or a one-pager or something that's easily explainable. I think what I would certainly not recommend is using a template. Instantly see when a vision's being made from one of these bog standard templates, it just, it is the worst. It so predictable, they're using the same terminology. You need to co-create the vision. Anyway, I'll stop there. I can talk a lot about visions, but I think the second part, so you've got your vision and then you've got your strategy on how you're gonna get there. And I'm sure you probably talk a lot with your guests in terms of this topic, but, A, you're gonna answer a specific number of questions, including a diagnosis. I was just listening to Lenny's podcast again on good versus bad strategy, and it's a really good reminder of kind of those key set of questions in terms of diagnosis, and then what are the problems that you wanna solve. And that kind of builds out those actions and that success criteria. So from there, that's where I would start to translate, you got your vision and your strategy, start to translate that into the roadmap in terms of you could have an objective-based roadmap for what do you wanna achieve, what does success look like, and then the individual actions or problems that you're gonna solve to try and achieve that. So generally I think the best way I've seen it communicated and executed on is when all of that is a clear narrative, like it makes sense in terms of pragmatically it fits together and it also aligns to what the business is trying to achieve. So I think that's where you need to be quite thoughtful in terms of how do you access it, how frequently is it updated, how often do you talk about it, and is it answering some of those key questions.

  - It's a great response, and I'd love to dive into a little bit more about strategy as we kind of unpack some more of the questions here. But I fully agree, you know, with what you've said. And often what I've found is that a crappy strategy leads to a bit of a crappy roadmap as well. You know, you can tell a lot about a product organisation and a product function by what their roadmap looks like, how they tackle it, how it's linked to these other strategic artefacts, often whether the roadmap has been given to them or they've been empowered to create it to solve the problems that really, the things that they should have been given to solve. It's very telling. So I think that was a great response, and we'll talk about strategy a little bit later. Adam, what do we think some of the key elements or content of a roadmap should be? And can we tie in some of those strategic things and bring them on that roadmap with us?

  - Yeah, I think it has to, and it goes back to what we were just speaking about in terms of the narrative. Like it's a story that you're telling. Like as a product manager, and this is a skill that I think is super important, but it's that entrepreneurial mindset. It's that storytelling. It's that ability to engage your team and the wider business and including the company objectives or the market you're going after, or this type of information that your CEO might be speaking about it in all hands, or you might hear it in a webinar. All of that makes a big difference, because, A, it builds confidence in especially senior exec level, in terms of what you're doing and understanding that the work you're doing and the roadmap connects to the broader vision. But I think just to go back to kind of answer your question in terms of some of those key elements. So I think for me it boils down to a few things. Firstly, it depends on like what altitude you're working at. So if you're a product manager working with your team, which we've spoken about a number of times, you might have more detail and more nuances. You might have a link to a PRD, or you might have, you know, a set of user stories with acceptance criteria and design. So I think at that level there's kind of some fundamentals that you need to include. I think going probably a little bit above that and thinking a little bit more holistically across R&D in the wider business, I think for me it's really important to include the problem, being really crisp on that. Also not overdoing it and doing it, like having really complicated user stories, but just really focusing on the behaviour that you wanna change, and what is that difference that you wanna make in the software to help grow the business. So I think the problem, the change of behaviour that you wanna see, and then how you're gonna measure success. What does that look like? And the way I like to frame that, as I just mentioned, in terms of what is the behaviour you wanna see and what does that look like and how are we gonna measure it. And that lens provides a really kind of easier way for the rest of the business to be able to consume it. Like, oh, okay, we wanna make it easier for people to sign up, and in this sign up people are gonna, I dunno, complete it in 30 seconds versus a minute. And what this should look like is we're gonna have less people dropping out at the funnel. So being able to explain it in that way I think makes a big difference. And then finally, this is something that I index, probably over-index on more than anything, but it's about how you're gonna bring it to market, how are you gonna launch it, who are you gonna collaborate with, what does that look like, because I've worked with so many product teams, and I was at fault with this as well, especially if you're working for a larger organisation that it's successful, they've got, you know, some bread and butter products that are doing really well and you're adding features to it and they're not really getting much traction. It's because they're not being thoughtful about how does it fit into the bigger picture, how are we gonna launch it, how are we gonna talk about it. So that's something that I really look for in terms of the roadmap, in terms of the details within the cards, and don't expect too much, but again, the story, and some of these kind of fundamental parts that I just outlined.

  - Yeah, great response. And I think picking up on that, you know, the definition of done doesn't mean that we've just the coded and the development has finished, you know? It really should be, it's in the hands of the customers, they're using it, they're realising the benefit from it. And I think what I have seen over the years and decades is that product management has got more and more focused on delivery and not enough around discovery, understanding the problems, and out the other end of that, benefits realisation. You know, are we actually doing what we set out to do? And so, you know, as you follow Lenny's podcast, and there's other people with the industry, they're talking about Brian Chesky, for instance, from Airbnb, it's pushing that back up again. It's not just about deliver at all costs; it's about delivering the value. You know, one of Pendo's reports that they did was around 80% to 90%, in fact, it varies slightly depending on how you read that source, 80 to 90% of features aren't used. And so it becomes even more important for product managers to seek out that value, to seek out the problems that need to be solved, and to save the development teams from the waste that they're ultimately generating by just being feature factories.

  - No, I completely agree, and we've seen a big shift to there, especially over the last 6 to 12 months, and I think we're gonna see more of it this year in terms of PMs being far more accountable to the business. And what that means is actually delivering stuff that moves the needle, or you're learning really quickly so that you can figure out what to prioritise quicker next. And I'm hoping we see more of a shift to roadmaps where we're really talking about what are we discovering or not discovering, what is information that we have internally or not, and it's all about kind of, it's just speed. Like speed trumps ideas. You know, the faster you go, the more you're gonna learn. So I think that's an important element to include in roadmaps. How you visualise all of that, I think that's a little bit tricky.

  - It is, but I think the multiple levels, you know, we often get the roadmap and a delivery plan get conflated, so I think separating those out into maybe the four different audiences that you talked about before, serving them up the information that's specific to them and is what they need to see, balancing that without oversharing and overcommitment, which can obviously be a problem in and of itself. And I think actually that leads onto the question for you, which is with those different levels in mind, do you have a preferred way to visualise and style a roadmap? And does it depend on the audience as to how you might visualise that roadmap?

  - Yeah, 100%. Yeah, it completely depends on the audience. I think for me, one thing I always do is I'll, as soon as we've got a roadmap, if, just say it's a quarterly roadmap for, I don't know, 2024, I'll go and chat with customers about it as soon as I can, even before speaking with some stakeholders, because especially at-risk or ones that have just signed with us or existing, I'll always canvass to get a sense of do they understand what we're saying, does it land well, what are we missing, 'cause they know, right? They've got their finger on the pulse and they're using it every single day. And I think a lot of PMs forget that, and they probably over-index too much on people internally who might not even use the tool. And that happens a lot of the time. But I think in terms of preferred way to visualise and style, I don't really mind. I think, again, it depends. Generally more senior folks wanna understand kind of how things fit together in the broader picture. So perhaps a Kanban may work better for that, or, I don't know, a broader timeline with milestones versus, say, if we're to go down a level, like in the middle level, if we're thinking about kind of R&D teams, for them, like more of a timeline roadmap with dependencies, being able to easily visualise things and understand, that might be really important. So I think the most important thing is to get feedback from who you're working with in terms of what they wanna see. And this comes out in the workshops, and the discussions that you're doing, and the quarterly planning, and the yearly planning, and that type of jazz. And I think I would always over-index on a little bit less and demo to see what feedback you get to see what you bulk into it, 'cause I've worked with a lot of product teams, especially with my experience at Productboard, where it's just too complicated, and I think it's very easy to be like, "Okay, sure. We're gonna show these four different tags, and then we're gonna make sure every team can put themself on it, and then we're gonna visualise every single dependency." But sometimes that isn't needed. Sometimes it is depending on what you want to achieve. So yeah, I think getting feedback's really important, keeping it simple to start, but generally I always kind of gravitate towards Kanban or timeline.

  - Yeah, I think so. A great response. You know, again, the classic, "It depends," here, but what I really loved about what you're saying there is understand from your audience what they want to see. You know, so often someone, a senior stakeholder says, "I want a roadmap," don't provide any more detail, the product manager runs away, creates the roadmap and gives it to the stakeholder, and they've not really talked about what they both understand the roadmap to be, what they want to show, what communication and alignment they want to have. I've certainly been guilty of that previously as well, as I've excitedly gone away and sat in isolation, crafting out a roadmap. You know, we've all learned the hard way, and part of this show and speaking to experts such as yourself is to hopefully help the earlier Adams and the earlier Justins from making those same mistakes again. But it completely resonates with me, of what you shared there. And you also mentioned around Productboard, so are there specific tools you prefer to use for managing and visualising a roadmap? We know that Productboard is one, but there's, you know, lots of other things out there. What have you found to work well?

  - So yeah, well, I think naturally spending some great time at Productboard and working in the product leadership team there, I'm naturally kind of biassed towards Productboard. Even removing kind of me having worked there and experience, it is a great tool. It's very flexible. It's unique in the sense of being able to connect the deep insight that you have from customers right through to your strategic objectives, so that customer centricity is in the heart of it, and I think that's what makes a tool like Productboard unique. And I think more broadly speaking, when I'm considering tools or roadmapping tools that you're using, I think it's very important that it's connected to the rest of what you're trying to achieve. So, A, it provides a lot more context, B, it's speeds up work significantly, and, C, it just helps consolidate tools which naturally has kind of benefits with efficiency and stuff.

  - It's what we need. Yeah. I think we were talking earlier, and maybe before we started recording actually around the efficiencies of these things, and, you know, it's, yes, updating the roadmap can take a lot of time, so sometimes it's the roadmap at the right level if it's taking a lot of time, you know, and it's also communicating the right things that we should be looking at. So for instance, if you've got a delivery plan that's 12 months long, of course you're gonna be updating the roadmap constantly. If you have a roadmap of now-next-later that's looking at the problems you want to solve over the next half year, that's less likely to change so often because you're not in the solutions space, you're in the problem space. So I think there's, you know, we see these different challenges there, but using these different tools, absolutely, especially when you want to have a single version of the truth but multiple views, that's where tools like Productboard can really play a part in that for those efficiencies.

  - Yeah, exactly. And that's it. That's the nail on the head. It's the single source of truth. It's about rallying everyone behind what investments you're making and making it self-serving, right? Like we still predominantly live in a world where a lot of roadmaps and backlogs and things are in spreadsheets, and yeah, that just creates a lot of extra work and a lot of mistrust and a lot of confusion, and I've worked with some larger organisations that still do that, mostly because the change management side and the training side is a really heavy lift to be able to use a tool. But there's, I think once you reach that point and a tipping point, that's where you can really invest your time in areas that are super important, so growth of the team, making sure that you're being really thoughtful about your strategy, and not getting bogged down in kind of the admin of managing that. But other tools, like I think Notion is certainly, I've seen a lot of product teams kind of use that to effect. Some pros and cons with that. And then I'm kind of going full circle here, but if you're a really small team, maybe spreadsheets are still okay. So I think it really, yeah, depends again.

  - Yeah, it does. It's the classic. But I totally agree, you know, only outgrow these tools when you need to. Just get started with something simple. If Trello works, if Miro works, if a spreadsheet works, that's great until you outgrow them. Coming from the other side, I've seen some people, you know, try and get the best off-the-shelf roadmapping tool at the time and then become completely overwhelmed with what it offers them, but it slowed them down the other side. So, you know, I'm a big proponent of that, which is, you know, find the right tool, product manage your roadmapping tools, go and do some discovery, try them out a little bit, see what works. You know, it makes so much sense. Let's talk about the good and bad of roadmapping. And we've picked up, you've shared us some golden nuggets already, Adam, but I'm wondering what you consider to be a best practise in roadmapping. And now maybe I'll seed that a little bit with, I love the fact that you've already shared the different levels and the different fidelity there, so would that be your one top tip to take away, or would you add anything else as a roadmapping best practise?

  - Yeah, I think the fidelity is really important. Having a shared understanding of taxonomy and how teams talk about it is also super important. It's not something we've spoken a lot about today, but I've spent a lot of time with teams just making sure that they have a shared understanding of what an initiative is, what an objective is, what a feature is, what a subfeature is. So I think taxonomy, having a shared understanding of that, having a shared understanding of process to build the roadmaps and consistency. I'm not the biggest lover of consistency, but it's important, especially if you've got larger teams. It just cuts down a lot of noise and unnecessary work. The only thing I would add, which you've spoken about, is just most roadmaps aren't consumed. They go to waste. So if you're gonna do it, keep it simple, get feedback on it and make sure you're doing it to the right level.

  - Yeah, and to that point, just to take one step further, why do you think that's the case? Why do you think roadmaps aren't consumed? And I'll add some thoughts in here as well, so I'm not putting you on the spot, but when have you seen that happen?

  - I think a lot of the time they're just not communicated properly. So they're not communicated through the right channel. It's like there could be an instance where the product team develops one, they're not quite in line with product marketing. Product marketing isn't excited about it. They're not gonna help try and push it at the next all hands or the next demo. So I think not going through the right channels and getting that buy-in early... It's one thing to be connected to the strategy, and have your roadmap and it's connected to the strategy, and on paper it's all green and your senior product leader is like, "Woo-hoo! This is brilliant." But if the rest of the company doesn't care, that's gonna surface really quickly. So making sure you're going through the right channels. So like for me, especially when I was working on individual teams, I would always have coffee chats with the folks I knew I needed their buy-in, even if they weren't like official, I dunno, senior managers or whatever. So then going through the right channels, making sure you're surfacing it and workshopping it. So going out, getting feedback internally on it, and spending the time investing and building the brand of the team and the strategy, I think that that's really important. And then finally not bringing it to life. So I see so many roadmaps where, you know, you could have taken 10 minutes to draw a quick mock up or take a screenshot from a competitor, and people understand it straight away. Context. Yeah, exactly. So I think those two things are really important, bringing it to life and championing it.

  - Yeah, that's a great response. I think I'd add into that as well, you know, the fact that it's our roadmap, as in the company's, right? I mean, it's a jointly-owned roadmap. You know, there might be people accountable for updating it, but we're working with marketing and sales and customer success to develop these things. It's our roadmap, rather than we've listened to what you've said, we've said no to these bunch of things, and this is the roadmap of what we're gonna do. You know, that collaboration and making them feel... It's that storytelling again, Adam. You know, it just has to happen at every single level with our customers, our internal stakeholders. And I think another challenge can be that if we update the roadmap so infrequently, once every year, it gets lost on a SharePoint and it's lost its value and its intent and its purpose, and so people can't get excited about it, 'cause it's another book of dreams that we've failed to deliver.

  - Yeah, 100%. And I feel like this year, again, we're gonna be seeing I think the benchmark for being a great product manager is higher, the expectations are gonna be higher, it's gonna be more competitive, and as a PM you need to be a really sharp communicator and you need to be really good at networking internally and making sure that you're getting buy-in for what you're doing or you just won't be successful.

  - Yeah, totally agree. And I think that's gonna definitely be a quote for this episode is kind of, you know, we need to make sure that we're elevating our craft and make sure that we're delivering value, not just delivering features that aren't going to get used. Fully agree with that. Are there any antipatterns you see with roadmapping, or a pet hate that you hate to see on the roadmap at all? What really grinds your gears or do you see a roadmap and it's not quite what you wanted?

  - I think we've spoken about a few of them. I think one of them is, what really frustrates me is if I'm seeing a roadmap and I know the rest of the team hasn't been involved in it. It's happened a number of times where we're talking about quarterly plans and the product manager I was working with at the time in a past career, it was just so obvious that the team wasn't involved in estimating or sequencing, and like, that's just absolute red flags. That can't happen. And I think some other kind of pet peeves would be around, like, titles don't make sense, they're rushed. It's amazing. It's kind of like an iceberg where PMs and teams forget that they're working on all the stuff below the line in the ocean, and all this busy work and all these meetings and all this stuff going on, and then they'll spend like 20 minutes trying to think about how to communicate it and talk about it right at the tip, and no one has a clue what's going on. So the titles, descriptions are confusing, there's no clear narrative of story. That's really important. So like what I'll do as an exercise is I'll copy and paste all the titles and descriptions and details into a document and then write the story with them. So we'll co-create it together in terms of you're solving this problem first, this is what success looks like. How does that build into the next problem that you're focused? Does it? Or maybe it doesn't. And then I think finally, and I'll leave it there, because I've actually got quite a few ones, it's just not being realistic or factoring in time for like experimenting. Seriously, like I've seen this so many times, where it's, "Oh, we're gonna release the alpha and then we're gonna start on the beta." I'm like, "You're gonna start on the beta the day after you've released the alpha, even though you don't even know the results of what the alpha is?" And that happens everywhere. So that, I think that kills me, not being realistic about the timing. And that's an experience thing, and it comes over time as well, so I think that's where really strong product leadership can help kind of coach and work through that.

  - Yeah, superb guidance. And I think some of that is to encourage product managers to be a bit more transparent around some of the activities, the peripheral activities that they're working on rather than just delivery. And so we should be more transparent on discovery on our roadmap, roadmapping technical debt on our roadmap. Yes, we might have different views of it and shield that from some stakeholders, but being more transparent, that we are not just about... You know, if your roadmap only shows that you build and deploy features, then it's no wonder the rest of the organisation think that we just build and deploy features. Adam, you've had some some great insights here. I'm curious whose advice on roadmapping or product management in general you listen to.

  - I think, like it doesn't come... Look, I've still got so much to learn, and it doesn't come overnight. I think for me, I'll always make sure that I am reading and listening to podcasts, or, you know, checking out resources. I don't have like a set of people that I look for in terms of roadmapping, but I think the best guidance that I've gotten throughout my career is just working closely with stakeholders and counterparts, building roadmaps, and listening to customers. And I think over time you start to get an understanding of what resonates well with customers in terms of how you communicate it, depending on what type of customer there are. And then the same goes internally in terms of how you should be talking and collaborating or pitching it with the sales team or marketing team. So I think on reflection, the people I've worked with actually really helped me develop how I think about roadmaps and what works well, because that's where you can start to develop some ingredients that you can kind of place and put into other contexts.

  - That's such an inspired answer, and thank you for that sort of thoughtful take on that. I fully agree. You know, if a roadmap is around communication and alignment, it doesn't necessarily matter what the roadmap looks like as long as it is communicating and aligning. And so tailoring it for those audiences in a way that resonates with them, I think is in some ways why some roadmapping templates don't really land within organisations, 'cause the organization's not ready for that type of a roadmapping approach or template. And so it's just about just making sure that what's the job to be done of a roadmap with each of our stakeholders, and then making sure that it does that. And if it's in black and white, or it's a bunch of shapes, or it's a Gantt chart, it doesn't matter as long as it's doing that job. Such a great thought there. So I'm gonna ask you a bit of a tough question now. We mentioned this earlier, but if you had to distil your philosophy of roadmapping into one or two sentences, or maybe some just key words, how would you describe it?

  - Look, I think it goes back to some of the first principles in terms of how we've thinking about it. So know your audience and what makes them excited. Keep it simple and flexible, and that flexibility kind of spans all these different areas that we've been speaking about. And then I think finally just make sure you're seeking feedback; you're being stubborn on the problem, but you're flexible on how you get there. So probably a little bit more than two sentences, but I think that audience getting feedback and just being flexible is really important.

  - Yeah, it's a hard question. I know when my co-host Phil and I asked that question of ourselves, and it's a tough one, but I love the fact that it kind of distils. I think you did a great job there. It picked up on some common threads that you shared with us previously, so there's nothing new there, but it succinctly told us about those two, three elements that you think a roadmap is, philosophy of roadmapping there. Adam, I want to come to you a little bit more and just give you an opportunity to share what it is that you do with our audience. So you mentioned Colab. I can see you're proudly wearing it on your T-shirt there as well. Tell us a little bit about yourself, how people can get in contact with you.

  - I think as we've seen in this conversation, product management is hard. There's a lot of nuance to it, there is a lot of advice out there, and the context matters massively. And I think one thing I've certainly realised and reflected on in my career is that it's the people you meet, the connections, the knowledge you share that kind of stands out beyond everything. But one of the reasons we created Colab is we really want to be that product team that you don't have at work. Because a lot of product people are quite isolated, they don't feel like potentially the confidence to ask their manager or their peers specific questions about the craft or their approach or have these types of questions. So that's why we created Colab. So we're an educational startup really with a mission to help champion your growth from day one. So as soon as you join, no matter what your experience is, we want to help you kind of achieve those goals by connecting you with like-minded people. So what we do is we do cohort-based learning, where we help kind of individuals reach kind of their personal and professional growth goals, but we also help support companies with like bespoke product training to level up their product practise. So we're founders, so I'm one of the founders and CEO. I've got two co-founders, Toby and Lucas. We've got a fantastic team with us as well. We're all product people. We're all building day in, day out, and we really want to make sure that the knowledge we're sharing, the small groups and learning programmes we're creating are the most impactful, because, think just to round it off, I am and I still am dissatisfied with our product management, and product knowledge is shared and communicated and taught, and we really want to change that by having these types of conversations. So you can reach out to me on LinkedIn, AdamDavisNZ. I think that's probably the best way. or you can check out a little bit more about Colab at colabcohorts.com as well. And we launched in London last year, so we've got a couple things happening over the next few weeks.

  - Superb. Well, congratulations, firstly. I think that's phenomenal news. I love that the fact that you felt your mission to do this, after seeing it, I certainly can appreciate that. I've been a product manager that, you know, just found the trade, found the craft, and then learnt on the job. Many people do when they are maybe someone that's in an adjacent department, the companies scaled to the fact where they think they needed a dedicated product person, speak to somebody and say, "Oh, Adam, you're good with customers. We want you to be our product manager." Which is a phenomenal honour, but then like you said, you're launched into this area of responsibility and it can feel lonely. So thank you for creating Colab. It's a resource that I know that I wish I had 10, 15, 20 years ago, but I'm grateful that it is available now and other people can find it too. So we'll be sure to put links down there in the description if you're listening on the podcast, and please go to talkingroadmaps.com and we'll share those links with you as well. And of course, as Adam mentioned, see if you can find him on LinkedIn as well, where he'd be happy to help and engage with you. Adam, thank you so much. It's been an absolute pleasure talking with you today. I just wanted to remind our audience that hopefully you've really enjoyed today's discussion. If it's your first time with us, then welcome. If it's your another time that you've come back, then welcome back. As you know, with the "Talking Roadmaps" channel, it talks about everything roadmapping, with product experts, practitioners, and tooling vendors, of which Adam is many of those as well. Please do share and like and subscribe to the channel. All of that helps us to grow. And if you'd like to sit where Adam is today, then do get in touch. We always love to have special guests on the show. But from other than that, Adam, it just leaves me to say thank you so much for joining us and sharing your expertise with our audience.

  - Great. Thanks, Justin. Really enjoyed it. Cheers.