Can a roadmap be interactive? | Hannah Chaplin

In episode 30 of Talking Roadmaps, Justin Woods interviews Hannah Chaplin about the potential for interactive roadmaps in product management. Hannah shares insights from her extensive experience in product marketing and software development, discussing how interactive elements can enhance user engagement and feedback integration. Key topics include the benefits of interactive roadmaps, practical implementation tips, and how they can improve communication within teams and with stakeholders.

Hannah Chaplin is Former Principle, Product Marketing at Pendo, a product cloud that helps digital product teams and application owners deliver software experiences that users love. Hannah previously served as co-founder and CEO of Sheffield, UK-based Receptive, a product demand intelligence platform acquired by Pendo in May 2019. Hannah is a serial entrepreneur who has founded and led several consultancies and startups. Her passion is helping software teams build winning products by managing feedback from their customers, teams and market. She also has extensive experience in project management, software testing, business analysis and market research within the SaaS space.

“On the customer side I like to make roadmaps more interactive”

— Hannah Chaplin

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

Can a roadmap be interactive? | Hannah Chaplin

Justin Woods and Hannah Chaplin

In the next episode we are talking to JJ Rorie, Lecturer at John Hopkins and CEO of Great Product Management. So watch out for Season 1 - Episode 31!

• Transcript

  - Hello, everyone. My name is Justin Woods and I'm one of the co-hosts of the Talking Roadmaps YouTube and podcast series. Here we get to talk to product people, expert practitioners, and industry leaders, and it's fair to say that my guest today is all three. Hannah, I don't want to do a massive introduction of you 'cause I know I'm gonna make a mess of it, so why don't you give our listeners, if they don't know you already, a little bit of an intro to yourself?

  - So, my name's Hannah Chaplin. I work at Pendo, do a few different things here. I run the Sheffield site, which is really cool. I enjoy doing it, that's a lovely place to work. I'm also a principal product marketer, so I work on Pendo for mobile, work on our feedback and roadmapping product as well. And I also work really, really close with the, the product team here. So yeah, I do a bit of all sorts and prior to that I ended up at Pendo 'cause the company I started got acquired and that was a product feedback and road mapping, which is I guess why we're here because roadmap nerds. And then even further back I've started other software businesses as well. So yeah, I've done all sorts, but always on the product side since I was 18, I've always done software, always on the product side.

  - That's amazing. And it's clear to see your passion coming through for those as well and I think once you've got them inside you, you never, you never really lose those. So I know it's gonna be a pleasure to speak with you. I almost can't wait to get started. But before I ask you the first question, to the audience out there, absolutely welcome. Please do give us a like if there's something that Hannah and I are saying as we go through today's series, if there's something that resonates with you, give it a like. If you think that something we've said really resonates deeply and maybe you can share with a colleague, that's fantastic. And also please, if you find value in today's session, please consider subscribing. It really helps the channel to grow and reach more people as we get to speak to fab people such as Hannah. So Hannah, let's, I'm gonna ask you the first question, which is really kind of straight in there. Which is, in your mind, what's the purpose of a roadmap?

  - Ooh, communication would be the one word. A hundred percent. So I've always felt like a product roadmap is about keeping people aligned and like excited about where you're going. I think like where we're at with software, like software industry in particular, is like how our customers like want to know where you're taking the product. And I see more and more that when people are choosing software for their business, one thing they're really interested in is like, is my voice heard? Do I feel good about where the product's going? And I think a roadmap is a really nice way to do that. Do you just, what do you think? I wanna know what you think.

  - I think it's difficult not to be biassed from a lot of previous conversations as well, but for me, and I love that question back to me as well, I think it's a communication and an alignment tool. And I think also in a world where we have things like OKRs and objectives and goals, I feel that it provides some story and some narrative. I find that the key results and the objectives can often be very clear, but I don't know if they necessarily talk about a journey and whether they're as motivational. I think using those two together I think is, would be my answer there.

  - That's a good call out. 'Cause the way I like to run things is we've got like different types of roadmaps, all that are like slightly different flavours. So we do have that internal roadmap that's more about alignment. So we have like top level items that are about like the business strategy and the OKRs and it's like here's, you know, like the swim lane thing? It's like this is the initiative, here's all the things that are building towards it to help like tell that story internally. But then we've got like a development roadmap which we actually have in like Atlas and, you know, like in Jira 'cause that's like really dull for anyone outside the development and product team to look at, right? That's like literally it's like tickets and Kanban style and we run sprints. It's kind of like a mini roadmap, right? It's all like two week map with the development team. So we've got the internal one for like leadership and alignment, the development team two week sprint one. And then with customers we have like a third style of roadmap which is very much about here's what's just being delivered and this is what's coming up next. So we keep it more high level, so it's nice and flexible. 'Cause in a big company like Pendo, stuff changes and a lot of stuff changes outta your control. Whereas, you know, when you're smaller, like when I've started businesses and we've been growing, we've been a lot more transparent and more detailed with customers 'cause I had more control.

  - You've gone from receptive and obviously your previous companies as well to them being part of this larger ecosystem. So potentially the importance of the roadmap in the audience has changed.

  - Exactly, yeah. Hence the need for like, that's why we have like different, different versions. What, did you run different versions? Because I'm seeing product teams do that a lot now and I think that works.

  - Yeah, I think so. I think it's having an, I'm loving these, the engagement actually back and asking me these questions. It's lovely. I think it's important. Phil and I, and certainly Phil has mentioned this in previous episodes as well, is that it's about having a single version of the truth but multiple views. I often talk about circles of trust when I'm using roadmapping tools. I don't really love to give everybody access to them where they can log in and see story points and comments or timings and things like that. I think it's too transparent. And so I think having consistency in terms of what you share but different levels of detail. And I think that resonates perfectly with what you're saying. It's just these common things. But they're all, they've almost got different tracks and cycles to them and that's really important.

  - Exactly.

  - The other question I was gonna say, which was the audience of a roadmap and I think you've perfectly summarised that there, which is, you know, there's a a number of different types and each of them have got important things that they want to get out from it.

  - Yeah, it is what, it is something I've started doing, I think more product team should do, like for that communication piece, especially internally and back up to the business, we're not only showing what features align with initiatives, but we've also got swim lane dedicated to like the go to market motion. So we won't just have like, oh this, this, this. Like product wise. Do you know what I mean? That's nice. But alongside that we'll run like, hey this is the onboarding campaign. We're gonna run an app. This is when we're gonna launch it to market and here's the marketing activity. And it goes back to what you said at the start just in that storytelling piece. It's like come put features out. But I always think of it as like, you know, if you're like an artist and you release a record, you've gotta do all the promotion, you've gotta do the touring, right? Otherwise, no one's gonna listen to it. And I very much think your features are like that, right? You can put a feature out but what are you doing as a product team in partnership with marketing to drive success of that feature to meet those like company goals? So we've started doing that a lot more as well. Like tie in the go to market with the features in a single roadmap to tell the story.

  - That's massively important, you know, and like you said, it's these, if development of building these building blocks and product management isn't just about building things, you know, so that roadmap at that level needs to cater for, hey we're gonna make some process changes, we're gonna make some documentation changes. And all of that is important. And I think, you know, you'll have seen this time and time again as a small company, yes we're gonna be building a lot and we want to try and build for simplicity, but often you just need to build your product functionality up. But then as we start to mature that, it's really about simplicity, sometimes taking away features. You're not gonna have that on a development roadmap necessarily. There is some work to be done. So I think that's really important is keeping those roadmaps at a higher level so that it engages those right audiences.

  - The only thing I've started doing a lot more is making sure we tie anything on the roadmap to data a lot better. So there's two ways I'm thinking about that. One is like when something makes it to your roadmap, we'll look at like all the usage data around the product area that we're like developing. If it's something that exists and we're improving it, of course, if it's new you haven't got anything. And then the second side, it's like the quant side but then the qualitative as well. So on the roadmap we'll tie a customer feedback request directly into like the feature or initiative. So again, think about the story, right? If an exec looks at a roadmap and sees that you've got 2 million of opportunities, 5 million of customer ARR associated with this feature, which ties up to this initiative, that's a great story, right? It's like okay, I understand why that's on your roadmap.

  - Absolutely, I wish people would do that more. You know, providing that insight into the why and in fact I'm gonna park that one just slightly and we'll come back to it 'cause I think that's a great one to dive a little bit deeper into in terms of what you'd like to see on a roadmap. That's lovely. Let's talk a little bit just about the peripheral. So in your mind, who owns a roadmap and maybe is that different to who maintains it?

  - For me it's always been the product manager owning and maintaining it because I just feel like the product person is at the centre of like even the detail, right? I have, we, there's been instances where someone else has tried to update the roadmap like a scrum person or a programme manager person and it just ends up with them having to go back to the product manager and I'm like, well. It doesn't make any sense. Just get the product manager to do it. And you know, I'm a big believer that it's the product manager that has to own it 'cause you're so accountable, like as a product manager, that's the one asset I guess that everyone looks to the product team for. What's your take on that? What do other people do, and what do you think?

  - I think there's definitely, I've been in situations where I've not been an empowered product manager and I've been essentially more of a glorified delivery or project manager with a budget. And so sometimes even though you own the roadmap, you don't necessarily influence exactly what's on it. And so you are told what to put on it, which I think is a shame. But I'm so pleased in, you know, in the last five, 10 years Hannah, we've seen massive moves away from that and actually having somebody accountable because you can't own something that you can't influence. And so telling somebody that they're a product manager and they own a roadmap, but then giving them a delivery plan, that's not really fair.

  - No, that doesn't kind of work does it?

  - So what about the relation of a roadmap to maybe vision strategy? We also talked about objectives and OKRs at the beginning. In your mind, what's the relationship with the roadmap to those?

  - Oh, I've always seen 'em to together, and I think that comes from like from starting companies. You have to like, just in my own head, I've always understood what we're doing and why and then obviously product development has to line up to that. So I think every product team needs to think about which part of the business strategy, like each feature is kind of having an impact on. I kind of see product management and you've gotta please like, you've gotta add value for customers, but you've got to ultimately add value to the business as well. And it's a little bit, you know, it's a balance that, right, sometimes. So yeah, like they're so tied together. I can't even, I'm struggling to comprehend them not being a thing because I've never thought about them any other way.

  - And I love that. I think they're intrinsically linked and I've heard somebody else mention that they are part of a constellation of other documents or artefacts that come together and support it. You know, it's in the middle. Phil often says that it's a, describes it as a bridge between strategy and execution. And I agree with that as well. I think it's often misunderstood, roadmaps. So we can maybe talk about that a bit later. But I think that, I think they're really important as a storytelling. I don't think they're the be all and end all. I've seen many people trip themselves up with roadmaps, creating a well-meaning 12 month delivery plan and them being surprised. I think there's a lot of, a lot of misinformation out there, but I totally agree with you and I can't imagine a world without roadmaps because I think, but it's just one small part that describes and fits in with other systems.

  - Yeah, yeah, that's a good way to think of it.

  - Okay, so we talked about the metrics and I want to dig into that a little bit more. So what do you believe are some of the key elements or content of a roadmap?

  - Ooh, okay, which one, which type of roadmap?

  - Hannah, I'm gonna give you the luxury of just picking an example actually. So just think of, think of a roadmap, maybe describe the roadmap, what its purpose is and then what you like to see on that, those key elements.

  - Okay, I'm gonna go with the one we use the most, which is the like internal roadmap where we're communicating back to the business what we're building and why. So I really like to see that tie up to initiatives like the business initiative or even a metric if it's like a particular metric that you're gonna drive. If you can put like a hard number against an initiative that's really, really helpful. And then I'd have the features. I use feature loose. I know product ones can be a bit funny about like it's a problem space. Like it's just words, isn't it? Like whatever. I'll say features for now, like feature problem space.

  - I think what actually, Hannah, to help you out, you did mention around development and things like that and I think that's absolutely okay when you're looking at the short term, you know, you're looking at the next two to three months, the development, when there is development going on, the feature space is fine, you know, we shouldn't frown upon it and say everything's so high level.

  - Oh that's a good point, okay. So definitely how like what you build in lines up to those initiatives. But I think like you said there, just that we have like features in the nearer term but then we'll have like problems that we're exploring kind of like over here somewhere. 'Cause there's lots of different things to think about all all the time. And then we make a really good point of making sure that we align the data with those features as well. So like I mentioned before, we look at product usage data and how feedback ties in to help like, tell that story. I don't know, I'm quite flexible on, I know there's a lot of people have opinions about like the timeline. Some people like calendars, some people want months, some people want . And I think this is such like a, this isn't a cop out answer honestly. I think that depends a lot on the company, the product, the audience, who the roadmap's for. So I don't have like a set, you know, set time for things like that because we have different ones on different roadmaps so.

  - It depends on the audience. I mean, to go back and I love that answer, that it does depend. Because it does depend. But I think the thing is to help us out here and reinforce what we're saying, the roadmap is a communication and alignment tool. So if it's not communicating and aligning, it's not doing its job. And so I think it does depend, it depends on your audience, it depends on what you're trying to communicate because the roadmap really is about them. It's about bringing them on the journey with you. You've got other versions of the roadmap, but that's the version that they're seeing. And so it needs to be empowering. It needs to, you know, often development teams are so in the weeds of the day by day that they might not see that we've got a six month overarching initiative that we're working on. That sort of stuff helps 'em out. In my tooling journeys, I often get, you know, the Jira, the teams in Jira or Azure, they don't see that visibility of what they're connecting into. And so I think that's really important.

  - It is. And that's like a, something we're really conscious of doing as like a product team is making sure the engineers know the bigger picture. You know, they, like you said, they're day-to-day like on the tickets, in the weeds, in the codes. So we've like to help with that as well outside the roadmap. We've done like a first, first half of the year sort of plan just so people know like wwhat the big objectives are that we're driving to. And that gives them a lot of motivation 'cause we can see what they're doing day to day and like how it impacts.

  - We've gotta bring them along the journey with you. They work really hard. It's nice to show them what they're working hard towards.

  - And I think it's, you can give that context like just day to day. Like if anyone runs like more of a swim process as like a daily standup or at least like a regular meeting with engineers, like whenever we're doing planning for what's next, I'll always just pull the context in. It's like, oh this is for this 'cause we're doing that and that's why. And it's just little things. It's literally two sentences in a meeting. So I think it's really important as a product manager to always like tie engineering back to what you're doing.

  - Love that. There's an example that I'm gonna completely butcher now, so forgive me audience and forgive me Hannah, but it was, it was talking about the people that clean the toilets and bathrooms at NASA and actually giving them a purpose of you are helping putting a man on the moon because you are, you know, keeping the bathroom sanitary. You're helping therefore the scientists to have a more comfortable environment so that they can do their best work. And it is tying that up to, you know, giving the people, the janitors and things like that, that clear sense of purpose that you are absolutely directly contributing towards helping put man on the moon is massively empowering even though that might what be the most glorified job that you could be doing.

  - Certainly you've gotta see the bigger picture. It's exciting when you know what it's for, what your day to day is for, definitely.

  - Yeah, absolutely. And so do you have a preferred way to visualise or maybe style the roadmap then? So we mentioned some metrics and things like that come into that, which I absolutely love by the way. I think that's really motivating and transparent, but do you like to visualise it in a certain way?

  - I don't wanna be like Pendo, Pendo, Pendo 'cause I don't like being like that. But I'm in a bit of an odd position 'cause Pendo has a roadmapping product and we've totally rebuilt it and as part of rebuilding it, I didn't wanna just be like, oh we've done the same thing again. It's just a roadmap tool. I wanted to think differently about what the modern roadmap looks like. So as we've been building it out, we've been tying in like the data piece and the initiative piece, especially the data bit. And so there's other, yeah, there's things I'm thinking about in terms of visualisation that really like tell that story better with data at the heart of it. So we've got to the place where you can tie like customer feedback to like your initiatives and your features and it all rolls up to like, hey, this had a thousand votes and this much ARR or whatever. But the next step I'd like to do with it is to tie off like what happens after you've launched something? Like to me a roadmap is a bit of a beginning and a product manager's job is like more end-to-end from like discovery to releasing something to driving adoption to sunsetting stuff, like an end-to-end thing. And I don't think product roadmaps today generally do a good job of telling you the next part of the story.

  - Totally, they stop at develop, they stop at deployed.

  - Yeah.

  - And it's like, but that's only half of it, you know, really.

  - Yeah, so I'm very much thinking about that piece, that alignment, and storytelling and communication piece back out to the business, especially of like, what happens next? You realeased something. Did it work? Like was it adopted? What was the usage data? Who adopted it? So I'm starting to think about building that out next in our road mapping tool so that you can tie the launch to how it was used, who it was used to, drive, you know, adoption metrics. So again, you can close the loop with the business and be like, hey, we invested in this to drive this initiative. This is, this was the ROI and just closing the loop properly in a roadmap. And that's where I see roadmaps going, it's like more data driven, more storytelling, and also closing the loop better.

  - I think you mentioned it, it's a phrase that I've heard as well around modern road mapping. You know, it needs to happen. We need to, we need to evolve from that. And I think, you know, pushing forward as to what road mapping may look like in the future, how we might have better definitions about what it's for and what it's not for, how to use it well, how to avoid using it, which of course is everything that this channel is about. And we need people like yourselves, you know, with this experience as a entrepreneur and as a product leader to really be curious and think about these things and go, well what works well? And it might be that we actually end up moving on to a completely different type of tool as well. That's completely fine. I think roadmap has such negative connotations sometimes because it just, you look it up on Google and see what it looks like and it looks like lots of different things that got people into trouble in the past. I think we need, we need either need a better definition or we need to change its name and I don't think we're ever gonna change its name. So we need to be able to help people to work out what it should be. That resonated with you, didn't it?

  - I was just thinking, what would you call it? I was like, ooh.

  - It might be a, it might be a landscape, you know, because if you think about ourselves as yeah product explorers, right? We don't, we know some stuff and we don't know other things so why say that we've got a roadmap now and we know how to get there?

  - Yeah. Oh I like that. Yeah, that's a good way of thinking of it.

  - Yeah, so maybe that's what we need. I'm not sure. But to have people like yourself developing these things at Pendo, being curious, stepping into the shoes of product managers, which is obviously something that's impossible for you to step out of really, you know, we're really grateful. So I'm excited to see innovations in this space.

  - Yeah, me too. I just thought of another one, can I tell you about another one?

  - Of course you can.

  - The other thing I like to do with roadmaps on the customer, more on the customer facing side, I'd like to make roadmaps more interactive for customers. 'Cause like I said at the beginning, like more and more customers want to know where you're going as a company. It gives them confidence and that helps things like with things like managing customer feedback. Like if they're submitting feedback to you 'cause you're not necessarily responding, you're not necessarily gonna respond to every customer request that you get. But if customers can see where you're heading, that's really important to them. They can be like, oh okay, they're not working on my thing this week or this month, but I really like the direction this product's going in. This is really cool. So making the roadmap more interactive, things like just allowing customers to see, you know, what's in discovery for example. And being able to add like a comment or a vote or raise the hand to be part of like, you know, like a customer panel or a testing group. Like getting the customer involved really early on to help you make better product decisions and help them like influence as well.

  - I love that. I can see where you set up receptive Hannah. It doesn't have to be us and them. It should, you know, some of the best companies out there is doing it together. You don't just get what you're given. Let's go and work on some stuff together and I think that's a lovely way of working. You know, your customers can be some of your greatest learning points. They can be some of your greatest advocates. Why not invite them along that journey and or them be so bold as to assume that they know what they want?

  - At the end of the day, they're the ones, the reason you've got a job, right? And they're the reason the company's there because they're paying you, you know, for a service. So I've always thought the customer is like so important and I've never felt that meant I have to build everything a customer's asking for. 'Cause that's not right either. But you've got to consult with them, tell 'em what you're thinking of building, get their, you know, buy in early on. Otherwise you just end up building a mess.

  - If you always did what your customer wanted, you might deviate away from what is truly important to your company.

  - Exactly, exactly. So I think there's an opportunity there for product managers to like have an opinion on, obviously have an opinion on what you're building, why, and align that with the company, strategy and goals, whatever, but make sure you are consulting the customer. It's very different to like, hey customers, tell me what to build, I'll go do it. Different, different things, right?

  - Yeah, for sure. And I think that's picked up on actually beautifully into the next question which is around best practises in road mapping. And so I think that's a great way, bring customers and it doesn't have to be your paying customers, that your customers can be your stakeholders internally. Bringing them along that journey is a great best practise. Is there another best practise that you might add to that though?

  - Think about your audience. So a lot of this we covered, but this is a good summary point. I like it. So think about your audience and don't be afraid to have like different versions. So as a recap, we've got like a customer version, the roadmap, which is very high level what we're building, like what's coming up next, what we've just released, high level stuff, that internal version with initiatives, very data-driven about storytelling. And then that like two weekly kind of like sprint roadmap with development. And that's not a lot of work to maintain actually at all. Like the customer ones like once a quarter, the like visionary type internal alignment one, it's not a lot of work. We update it as we go and then we do the sprint planning with the team anyway. So it can sound like a lot but it really isn't. Bring data to your roadmap. Really important that you're backing those roadmap decisions up with data to help with alignment and explaining. Put other things outside of feature development on your roadmap. Like the go to market side is really helpful. Yeah, I think they're, I think they're the big ones.

  - Absolutely, I love that one around the other departments of things. I think if we had an audience here, Hannah, they'd be giving you some applause right now. I'd probably have to get a little applause button for future videos. But absolutely. I think that's, I think that's really important. What about some of the biggest mistakes you maybe see people have done in road mapping?

  - When you say people, do you mean me?

  - It doesn't have to be self-incriminating and you can say that, you know, you have a friend who, if you wish to.

  - Oh my gosh, so going back in time, I think like people used to do a lot of like Gantt chart style. There's a weird lap over, wasn't there? A project management and product management for a while? Do you remember that?

  - I do, and it still is between what you, we might call release managers and product managers and how they're kind of intrinsically linked. One of them is probably around the when and the other one is around the what. And you can't do the what without the when or the when without the what. So they're kind of both in the same box. But I do remember it well and it's still a thing.

  - And I think during that transition there was a phase where we were being pushed to still do like the more project management style, Gantt chart style, you know, little coloured sausage thing. And after a while, especially when SaaS became a thing, that just didn't work. So I'd be very conscious of like timings and things and making sure you're not putting like hard dates where you don't need them and all that sort of thing. I've seen that go wrong a lot of time. What other stuff? Oh, touching a bit again on you know, the customer feedback side. This tripped me up in my first SaaS business where we'd landed like a huge customer and we were like, yay, an enterprise customer. Yay. Isn't that exciting? And really looking back, that product was more for like small and medium sized businesses, but we started like building more and more bespoke stuff for this like big whale customer. That's not a good thing to do, everybody. That made me sad cause you end up building all this bespoke stuff and it's like, well this isn't a SaaS product, we're just the software house or something. I've seen other people do that and I'm very conscious of it now. If we've got a big customer asking for stuff, I'll like have a think and be like, oh, does this align with what other customers are asking for? Does it align with what the target customer needs? Does it align with what the business wants us to do? And I've got a lot more comfortable at like pushing back on those things and saying, no, but that's a bit of a hard lesson, isn't it? Like saying no, especially to big customers.

  - It's massively difficult. It reminds me of yes so many things that I could bring in here, but Daniel Alizaldi talking about the, that the B to B innovators map and that your roadmap should maybe be your first 10 customers before you can even think about product market fit and what you're trying to do there. So I think there has to be a level of tailoring, but with SaaS, you need to account for the many and build for the many. And so it's tempting to go down that route, but it's, there's, it depends, right? There's a balance. You have to get some revenue in. And so building what people need is important. But maybe it could also be around Theresa Torres's thing, which is the opportunity solutions tree. If your customers are coming to you with some solutions of what they want to build, maybe it's teasing behind that and looking at the wider opportunity that may actually be needed by others.

  - Yeah, so like that's a good point. Like the second time round I had that situation in a different business. It was very much about, okay, which, you know, does this align? What can we build here? Or how can we create something that more people can use that also solves your use case? So thinking about it a little bit differently, I think one of the biggest ones that have tripped me up, what's the, I need to ask this now. What's the, what's the one thing that you've done where you were like, oh, I've learned from that?

  - I'll tell you, this is, I think hopefully the audience can relate and you can relate. But I think the first one was my first product manage, in fact it was my second product management job. The first one was when I was at Dell and looked after the basket pages for E-com. I was kind of largely given the roadmap 'cause it was, I was more of regional extensions of a global code base. But I think when I went into this other company and I was, it was a bit more carte blanche, I think I sat in a room in isolation and created much more of a long reaching, excuse me, roadmap on my own. And because I just thought I know best so I'm gonna create it on my own. And I think that was the biggest mistake. You, it's not that you don't run it past other people as well, but I just made some fundamental mistakes of just doing it in isolation, making it too specific, and making it too long term because I didn't really understand what a roadmap was properly at that time.

  - It's funny you said making it too long term. I think my tendency is being the other way. I'd be like, oh, I'll be fine. I don't, I just feel like, oh we'll work it out, it's fine. We don't need to plan that far ahead. So I'm like always the person pushing against like longer term. But I think the key word you've said a few times is like, it depends and balance as well.

  - Well, when you're a founder, the roadmap can be in your head. You know, I'm running Roadmap Heroes at the moment. You've been a serial entrepreneur and created different companies in the past. And so you know when it's just, when you're just on your own at those times, your roadmap is, or your ability to do your analysis on what's right or wrong to build is in your head because you are doing all of that linkage on what aligns to strategy and just that gut feeling. Whereas as you start to expand, that doesn't become the case.

  - No, you're quite right. And there's like, I think when you're early stage, you're in a very, very special and different position because like thinking about when I've started companies, you are doing products, you're doing marketing, you're doing content, you're doing all of the sales, you're supporting the customers. So really you are connected to absolutely everything. So the roadmap is obvious. It's like laughably obvious 'cause you're middle of it every day, but then your company lands, you've got 500 sellers, you've got 600 CS people and you've got like a board and all of that information you used to be so close to is suddenly you have to work harder to get it. It's just different, right?

  - It is, and I think that goes back to what we were saying about the communication, the alignment is really, the, when you are in a smaller team or on your own, that's in your head. So the alignment is obvious, it's intrinsic to what you're doing. But when you are working with other teams, the roadmap is your explicit representation of that. And so that's why it does that communication and alignment so. What about any bad practises or anti-patterns you may see?

  - Planning too far ahead is a big one for me. Definitely like planning too far ahead, nightmare. I think the other thing you have to be careful of, again, for bigger companies as well, along with that planning too far ahead is like communicating things too early on. I've learned we have to be really careful about communicating to our customer facing teams closer to when something's shipping rather than in the olden days, it was a bit more further out. So I think yeah, announcing stuff to customers and customer facing teams too early, that's not helpful either. I see people doing that a lot.

  - Yeah in your best endeavours of being transparent, you're maybe changing it too often or, or you are just, it's that confidence level I think and it's just, there's the right time to share something and it needs to have a certain level of maturity or stability or confidence before you are ready to do it. And so too early can be a problem and too late maybe can be a problem too.

  - You've pitched it right, haven't you? You can give the longer term strategy and stuff without being like, we're gonna do this next week.

  - Exactly. And do you have a pet hate on the roadmap? Something you just really don't wanna see on there?

  - Not necessarily, so I don't see on there, but it really winds me up when, this isn't any particular company, by the way. This is just random people over time where someone swarms in and they're just like, oh, why are you doing this? Or like, I don't wanna do that though. I wanna do this. It's like, oh, let people who don't take the time to ask, ask the product team first why it's, you know, why something's there. Why are you building a kind of particular thing? So I always like, if I'm looking at a roadmap or something, I always come from a place of, okay, this is on there for a reason. I'm gonna go and like dig a little bit and learn about why and have a discussion rather than what's this doing?

  - And I know people want to come in and make their mark and make a change. And often the seagull manager that you described, they fly in, they crap all over the place, and they fly off again. It's almost actually like someone said it, it was Simon. Simon Witkis was on the channel previously and he said it, the roadmap can serve as corporate record. And I loved that because actually it can show a history of things that we've done previously and coming into your kind of thoughts around roadmaps of some of the benefits that they've realised over time. Wouldn't it be lovely to actually say to that person, love what you're saying, but actually we visited this two years ago, and it wasn't successful because of X, Y, Z. We didn't actually achieve these benefits. And so do we really want to go through that cycle again or should we attempt it in a different way? That's really powerful.

  - Yeah, which comes back to why it's so important I think to, when you're producing that internal roadmap, mapping it to the strategy and having data to back you up, just makes those discussions go a lot easier. It's not just opinion versus opinion, you know, it's like, well that's hard, right? In some environments, other product people I've spoken to, it takes a lot of confidence sometimes as a product manager to, you know, step up and have those conversations, especially when it's someone higher level or higher up in the company, it's difficult. But that's why, like I say, data and that sort of thing can really help.

  - Absolutely love that. Hannah, I want to learn a little bit more about where you get some of your inspiration and ideas from. So is there anyone whose advice on roadmapping you listen to?

  - No . Genuinely, no. I think there's nothing like just cracking on with stuff. Like, I think like you have your best ideas, your best inspiration, talking to customers and actually using your own product, that like your product doesn't have to be something you use in your job. You could be like, I don't know, some, you know, something totally different, totally different space to what you do. But I think very often people talk about their products and roadmaps without actually be using their own products. And I think you learn an awful lot from staying close to customers and actually using your own software. That helps a lot.

  - Eat your own dog food and talk to the people that are actually using it. I mean I think that's a, that's something that product managers don't do enough of. And possibly because they're more delivery managers, but please, people out there, speak to your customers. That's the most important thing because they're the people that are paying your, keeping your company going, paying your wages, and they're the people that you need to keep happy.

  - Yeah, and I think the thing I see a lot in a similar vein is like, people talk all day long about, they'll sit on meetings designing a feature or whatever. I think it's really important just get your screen up, get the product and like just show people or get people to go away and like click about in it themselves. And again, it really brings it home. And I think that's what drives the inspiration when you're close to customers, when you are using it, when you're taking everything back to the actual product. That's what, where the inspiration comes from, I think.

  - Absolutely, yeah, I love that. And are there any roadmapping resources or that you typically use or recommend?

  - Again, it's probably just the product people around me. Like we talk about stuff, like we figure out what the business needs, what our customers need, and we react to that rather than looking outside. I know some people like it's great to go read up on stuff, but there's nothing like figuring it out. I don't think, that's just what, I'm very practical. I'm not much of a like reader in that respect.

  - But I love that because a template is not gonna tell you what your internal stakeholders want to hear. The only way that you're gonna work that out is to speak to them. And again, we just need to be doing much more of that. A template or a tool even, it might not be the silver bullet. It might help you to expedite a process, but really you need to go have those conversations.

  - Yeah, and I think every set of customers, every product, every business is different. And what's right for your roadmap is probably wrong for someone else, you know? So I think being conscious of who you need to work with day-to-day and reacting to that rather than what you've read or what's on the internet is, I think that's a really cool way to work.

  - And a quick question on tooling. So it could be interesting to hear your thoughts on this, but do you have a particular tool that you like to use or would recommend?

  - Well this is, like I said earlier, this is a bit horrible because we just use Pendo, right? We use our own roadmapping tool, which obviously we're developing, and we make sure the other product managers are using it as well. And we're very in a very special position that we were able to do that at Pendo. So we can work with the other product teams here to help develop it out as well as customers. But there's loads, right? Just tonnes of them isn't there?

  - Explore them, find what works. I think the biggest bit I'd say to the audience is first of all, be clear on your own internal processes and what works for you. And then find a tool that fits that.

  - Exactly, yeah, totally agree. There's lots and lots of choice out there.

  - Awesome, so we're coming up to the end of today's session. I'm gonna ask you a question that can often be a bit more of the most difficult one, but I don't wanna get you too worried. What would your philosophy of roadmapping be in one or two sentences?

  - Do what works for you. That's it though. Do what works for you. But I'd frame it with like the things we've talked about, right? Do what works for you, but be conscious of what the company needs, what that strategy is, back your roadmap up with data, and make sure you're telling that story. Think if you're doing those things, you're not going too far wrong, right?

  - Product management, product managize your own road mapping process.

  - Ooh, hey, that's a strong, strong ending quote there.

  - Hannah, before we let you go, I'd love to give you a chance just to share with our audience if this really resonated with them on the things that you offer, the things that you are working on. Maybe just pitch yourself a little bit.

  - Sure yeah. So I guess if you're a product team that's growing and likes to be very like data informed, I would definitely, you know, go and have a look at Pendo for sure. It lets you like understand what your users are doing. You can guide them in app, you can collect feedback, and you can communicate everything back with like a product roadmap. So yeah, go and check Pendo out. You can start for free on it as well. So it's worth having a look.

  - Thank you Hannah, so much for sharing that with us. We're gonna put links down in the YouTube video. If you're listening on the podcast, please go to the YouTube videos or go to our website and we'll share those on there. But you know, we are really keen to celebrate a lot of different tools because behind those tools are great people such as yourself, Hannah. So thank you for all of the work that you're doing and yeah, I just want to say a massive thank you for spending time with us. It's been an absolute joy speaking with you today. Is there anything else I should have asked you that maybe I didn't?

  - Oh, I think that's a lot for a Monday morning, Justin. No, it's been really fun. It's been really fun. Thank you very much for having me.

  - Oh, you're absolutely welcome. So folks, if you've enjoyed this video, if you've enjoyed listening to Hannah's words of wisdom there, please give us a like so that other people can find this. I think there's so many little bits of wisdom that you shared with us. So folks, please go and share this out with someone that you think may need to hear it as well. And if you found value, consider subscribing as well. That would really help us out. If you'd like to be where Hannah is today, reach out to us. We'd love to schedule a session with you where you can share your thoughts. Otherwise, that just leaves me to say, Hannah, thank you so much. It's been an absolute joy.

  - Thank you.