How important is a roadmapping tool? | Tim Herbig
In episode 8 of Talking Roadmaps, Tim Herbig discusses the critical role of roadmapping tools in product management with Phil Hornby. He shares insights from his extensive experience, emphasizing the importance of connecting strategy, goals, and discovery to focus on outcomes. Tim also explores the challenges of balancing large-scale product iterations with the flexibility needed in early product stages. Practical advice on leveraging roadmaps for effective product discovery and strategy alignment is highlighted, providing valuable guidance for product teams aiming for evidence-based decision-making.
For more than ten years, Tim worked in various in-house and consulting roles as a Product Manager and Head of Product. He constantly challenged himself to make an evidence-informed way of working in industries like publishing, professional networking, and building Enterprise-level SaaS applications. He knows what it takes to balance large-scale product iterations with the scrappiness of a pre-Product-Market-Fit state. Tim is on a Mission to help Product Teams find their path to focus on Outcomes by connecting the dots of Strategy, Goals, and Discovery. He wants to create a future where Product Teams can make real progress toward meaningful goals through self-determined and evidence-based decision-making.
“Don’t over-tool your roadmap approach”
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).
Our next guest is a big one! We have Bruce McCarthy one of the authors of Product Roadmaps Relaunched on the channel! If you haven't read the book you should! It's the best guide there is to modern roadmapping! So watch out for Episode 9!
-
Welcome to Talking Roadmaps, the channel where we talk about everything roadmaps, exploring the craft of roadmapping. Please, if you're interested, do like, subscribe and follow the channel, maybe some shares. We'd love it if you commented down below if there's anything interesting you here today. I'm joined by Tim Herbi. Tim, please introduce yourself.
Hi Phil, thanks so much for having me. Yeah, my pleasure. So my name is Tim coming from you from Germany today, which is where I live and where I started my product career back in 2010. Lots of interesting bits on this journey from large scale corporate publishing to working professional networking as well. A couple of very, very interesting startup experiences as well as well to share the least with all the usual ups and downs and self conviction versus real user insights and some B2B mixed into that as well, just to make sure that things don't get to stale to borrowing. And since 2019, full-time coach consultant working with product teams pretty much across the globe, helping them to find their own path toward this mythical word of focusing on outcomes that we all love to talk about in our industry. Predominantly doing that through things like product discovery, OKRs, product strategy, and of course something like roadmaps that sort of seems to be the glue for tying some of these bits together one way or the other.
Perfect. Yeah, I mean, and funny enough, I think I'm on your adaptable product discovery course. I am subscribed there and going through it slowly. I subscribed to too many courses myself, but I'm always trying to learn or trying to get that growth mindset I think is a key thing for any product person. So we'll make sure we get a link to that down below as well when we put this in. Yeah,
Good idea.
Great. So well let's get to the nub of it. Let's get to the heart of it. In your opinion, what is the purpose of a roadmap?
What is the purpose of the roadmap? So I'm trying to not blame too much on the usual. It depends. Response. I would say that for most product teams, the purpose of the product roadmap should be to communicate priorities and mostly internally. So I would say communicating typically more tactical priorities, more strategic outlooks for an internal audience. And of course there are different other formats and artefacts out there that you could use to do the same thing. But that's where I would say if I would had to sum it up in one sentence, that's how I would do it.
Interesting. And so you said mostly internally. Next thing I always like to ask is who's the audience? So yeah, I guess maybe you can unpack that a little more.
Yeah, for sure. So as I said, so mostly internal, I was saying that because there is this case out there that some companies work with those public roadmaps, which well typically very feature centric, which is a topic we'll probably get into later on, but this is some kind of excellent roadmap you could use as well. I would argue that rarely do these roadmaps get used, one-to-one internally in the same way, the same format. And so I would argue that the main audience for any kind of fraud roadmap is probably your own team members. Everybody might not be always on the very same page of what might be the outlook, the next priorities focused on their craft. It's certainly a vehicle to align yourself with other teams or to be aligned with other teams if you're doing something like a portfolio level roadmap to make sure where different teams are working on within any given portfolio area, but also of course to communicate to non-product stakeholders within the organisation. Look people like the sales team marketing or customer service, like, hey, here's how we're addressing some of those issues you brought up some of the problems we're seeing, here's where we'd like to go and communicate that. And of course, last but not least, executive leadership level to make sure that they get a sort of very condensed oversimplified version of Hey, here's what we're going to working on. And probably also mixing in how are we going to measure success and how are we going to achieve that.
Perfect. And when you say your team, we're talking about a cross-functional product team presume. Yeah,
Yeah. So whatever your typical product team is, right. I think it's good that you bring that up for clarification because still a lot of companies think that I'm talking about the product management department when I say product team. So yeah, I'm actually referring to the product team and that includes, right, whether it's the traditional trifold of product UX engineering, I would like to argue that most companies should think of the cross-functional team as whatever skills are required to create value as autonomous, most autonomous way. For some organisations that might include marketing on the team, that might include data science, analytics, whatever you need.
Yeah, one of my favourite to make sure is in there is operations, for example, and testing exactly. Because often testing are represented by the dev team. And there
In my mind, that is a good one. You could probably get the ethernet started on this one. Do you have an educated QA testing person on the team or not? I always really valued that to have that person on team. They were really such a great enhance of engineering quality. It's almost like not to downplay anything, almost like the technical sidekick of the product manager in order when it comes to figuring out how are we building the thing to ultimate end.
Yeah, I mean we've, are we building the right thing and are we building it right? And the two
Have
Together obviously. Yeah,
Exactly.
So who owns it then? Who owns this work?
I think it might be easier to answer the question of who doesn't own it. I think it also depends on, what do you mean by what does owning mean, right? So I would say I think there should be this, to me, ownership would mean who's the core group of people who have to stand in for the choice being made and articulate through the roadmap. So ultimately I would say who owns those prioritisation decisions? And the roadmap is just like a visualisation communication vehicle for set prioritizations. I think it really indeed does depend on how you have spread or distributed responsibilities within your product team. I would say the typical product review of engineering lead, lead your X product manager might be a good starting point to have those continued roadmap discussions. Of course, there might be certain, let's say domain knowledge between the three of them who probably has an idea of like, oh, I know about this strategic business priority coming up. I know about this company, what refactoring coming up? I know about the need to introduce new design system, which might be in the heads of all of those three people. I think this might be a good starting point of people standing in for the collaborative decisions and actions by a team. So owning them, having ownership in the hands of individuals from each domain of expertise within the product team might be the very diplomatic answer.
Do they all maintain it as
Well? Then I would argue that very often you probably will see the product manager being the one maintaining it as the person working with the artefact most often is probably what you will see just as one of the other domains might work with a specific artefact or topic more often than the others, even though it's a shared conversation. So even though the whole team talks about a ticket might be engineering who does the majority of work in detailed descriptions, whatever or documentation within the ticket. So I would argue probably product management role. The product management role is the one maintaining it. At least that's what I've seen most often. And of course you could argue that if you have this portfolio level perspective, you then might have the head of product slash VP of product maintaining the portfolio level roadmap with inputs from the individual contributors or the whole product teams.
Sure. Yeah, that makes good sense. Yeah, I guess because there is that subtle difference of who, who's owning what it represents and who actually puts it together almost.
Yeah, exactly. I mean it's similar to when you think of OKRs, you would make the whole team should be involved in the OK finishing process. And of course you would want to have this conversation within the team every week, every two weeks of like, Hey, where are we going? Do we have to course correct? But there typically is only one or two people who are actually filling in the OKR check-in like writing the actual thing and potentially submitting it, somebody who wants to review it. So I think there's this differentiation between collaborative discussion and the technical delivery, so to speak of the artefact.
Sure, yeah, it makes good sense. And funny enough, I was about to ask you about relation to other artefacts like OKRs or vision or objectives. So maybe unpack that a bit more for me. How does the roadmap
Lead? Okay, how much time do we have? No. So the way I see it, I think I've seen plenty of talk out there that people would have to choose between OKRs and broad roadmaps. These are conflicting artefacts. I think that certainly is not the case. And of course, again, this comes with a big, it depends, right? For example, if you work with OKRs that are very output driven, meaning the key results are pretty much slightly summarised product backlog, then the question might be worth asking, well if the OKRs list which feature we're going to build this cycle, what is the additional purpose of a roadmap? Which is fair. I think it becomes more interesting if you truly embrace this concept of having the OKRs being more outcome oriented and try to stay away from the best practise outcome. KR don't try to get too caught up by the best practise or by the book definition, but let's say more outcome oriented, the journey most teams are on or want to be on.
If you work with these, I think the biggest obstacle you might take is that when you talk to non-product stakeholders or even product team members who just look at the outcome metric, but then ask themselves, well what are we going to do to get there? So you still need to have that expression of what are we going to do, whether it's a feature or an experiment or an activity to move closer to that outcome. And you don't want to squeeze that into the ARC KR itself, so you don't want to spread it out even further or have key result activity in one list. So I think that's where the roadmap can come in really beautifully because then you're coming from things like you have the qualitative intent for your objective. You have some of the key results that would tell you implicitly which problem you're trying to solve a K which outcome to drive, and these two could already form one roadmap item.
And then you could list as an addition at least for the near term, like let's say next three for six 12 weeks cycle, even articulate, well here are some of those current ideas we're going to pursue to drive this key result to contribute through that as qualitative intent, whether again, whether it's experiment or feature or something like that. And I think that might be good for the short-term perspective as in the current cycle the next couple of weeks looking ahead and of course this will change, you might not be able to say, these are all the features or activities we're going to do throughout the cycle to drive the key result. Some of these might not work out. So what might be the best guesses, the most educated guesses at the beginning of a certain cycle? Think Greg gets really interesting as if you adopt roadmap format and just to borrow from this very common now next later format.
If you look at columns like the next or the later format, then it gets really interesting because you don't want to be as descriptive. You can be for the immediate future. You don't know the OKRs for the following cycles yet. Ideally that would be quite descriptive. But what I've seen work quite well for some product teams, and honestly you could argue this is kind of a bandaid for gap in the product strategy, but to work with annual OKRs to say like, okay, maybe we are not as clear as we want to be in articulating the product strategy, but we can articulate some the key high level metrics and how they should be evolving at the end of the year. So you could work with an annual KR and this annual KR might give you some input for the next column at least of your roadmap and give you an idea of, okay, which other metrics, which other intentions do we potentially pursue as well? And then I guess the later column is really about those very fluffy high level pieces that might also contribute to your vision being even longer out.
Interesting. And now next to later format of roadmap being something that Jana Basto famous to have created, she's a previous guest and definitely one that resonates with me. I made that transition in terms of roadmaps in my last organisation often find there's that perception that's going to be hard to make that shift. And actually I find general it's not because people realise that it's a more honest way of communicating the direction instead of just moving everything to the right constantly.
Yeah, I I love that. I think, I don't know who wrote that, it might have been Andrea SAEs who wrote this idea that there's this term of the CanBan roadmap out there, which sometimes seems to be referring to the noex later roadmap. And I think what I love about her take and which really just makes a lot of sense, it's like Kanban is about moving things from one column to the other as fast as possible with a certain work in progress limit. Whereas the later roadmap, it's not about moving everything from the later column as fast as possible to the now column, which would get you this feature Hester wheel. And so I love this antied of not treating the column-based roadmap as something where everything will move as fast as possible from one column to the other. It's not a gim that it'll
Be done. In fact, the NEX literary is almost a use of the three horizons concept and often in the three Horizons concept, you are already working on the things in the later in order to pay off long term it might be high level discovery activity and so on going on, you just don't know how it's going to land or where it's going to land.
It's true, it basically supports the whole dual track agile mentality. At least there are things in the here and now quite literally we have to deliver on, we know how to measure. There are things where we just know that these are mid to long-term strategic intentions. It's not even fair to call these a batch or specific metrics. That's the direction we want to explore. We have some idea of what to do to explore this problem space, but whether it would ever result in anything like being delivered in the current quarter or would ever lead to current quarter OKR left to be seen.
Now I wonder, are there any other artefacts that you think kind of link in or relate to roadmap?
Well, I think you missed a couple of these, right? So I'll believe product strategy might be incredibly important artefact because again, this hopefully articulates which specific choices you're trying to make in the future, whether it's about expansion to a certain market, expanding to new user segments, trying to prioritise share of wallet with existing customers over getting new customers. All of these choices should influence your roadmap and should make sure that specifically those next and later bits are a little bit clearer and don't just say revenue on them. I think the other bit you mentioned product vision, again, extremely important even though you might find it difficult to link individual roadmap items directly to the vision because the vision is supposed to be that far out. And of course I think the third bit being of course previous discovery and previous delivery activities because all of these should feed back into the next protein you're working on.
So for example, if you're discovering something to continue using this concept in the next column, you're discovering something trying to figure out does the problem exist, which then might lead to, well, maybe it doesn't exist, so we're going to abandon this roadmap item, not going to transition it into the now column. Or just as you are about to deliver things in the current cycle and you figure out, well, we can't move the needle so it might be worth it putting this roadmap item back into discovery mode or to another time horizon or we're discarding it completely. So really it's not like probably all the buzzwords you can name all of these to a certain extent, influence what you should be putting on your roadmap and whatnot and how these things might look like.
So let's switch gears a little bit. Let's think about maybe the design of about the visualisation mentioned visual a little bit. What do you in your perspective think are the key elements of a roadmap?
What content? Yeah, and I have that discussion with quite a lot of organisations because I think it has to be tied into how an organisation currently works as well to make sure that certain artefacts that are non-negotiable will continue to be used, I think should be put on the roadmap item if it helps some with the communication. If you remember, the roadmap is about, it's supposed to be at least from my understanding, the communication vehicle basically for priorities. And so the question is how are priorities expressed in your organisation? So if you work with something like OKRs, I think it makes a lot of sense to not just if you work with OKRs, but it makes things easier. But one ingredient should be, let's say the more qualitative intention of what you want to achieve, not about the specific outcome, the specific metric yet, but just we want to, I mean it could be things like differentiate through delightfulness or something like that, something super fluffy, but which at least gives you certain high level categories to put things into buckets. Almost
Like a product goal, a little bit like you have a sprint goal or it could be a roadmap goal maybe,
Right? Like a roadmap goal. I think probably the time horizon might be key, right? How far ahead do you want to look and how fluffy is it okay to be? I think at this level I think it's fine to be very fluffy. One thing that I love to add to roadmap items, because simply it helps so many organisations to shift the way they work is to have the problem they're trying to solve quite explicitly on the roadmap item. Because I found that if you just write the outcome, people have a hard time not defaulting to the solution already. There's constant struggle between outcomes and outputs and being using clear and simple English and language saying which problem are you solving for whom that's almost like an obstacle for some people to fill in a new roadmap because they're like, well, I actually don't know. It's like, cool, let's put this into the next column then and not something we want to try to deliver on in this current cycle. So having people explicitly express the problem they're trying to solve, and again, depending on the team, this might not always be your traditional B2C end user. This might be an internal team, this might be your own way of working. This might be a buyer persona supporting segment, whatever it is.
Then I'll love getting people explicit about how would the success state of the solve problem look like from a metrics perspective, which could be a key result or whatever kind of metrics system you're using. So when would you know that you have solved the problem form of a metric essentially? And then again, adding things like the features or experiments you're pursuing next trying to drive this key result to solve the problem.
And I heard you say something really subtle there. You said it once briefly, and who would you solving it for as well, which I think is a really key part of that, because that problem might exist for 10 customers and choosing one
Exactly,
You're going to deliver a particular solution, not necessarily to all of them,
Which ties in perfectly with product strategy. I think strategy is about making these high level choices and if product teams are always only talking about solving problems for everyone or just talking to random strangers are using built in user recruiting panels or user testing tools, which is my nightmare quite frankly, to just use pre-built panels without knowing the context of them. It's like, well, it's the same as going out to the streets and asking random strangers. And honestly, if you're building something super generic like a dating app, this might work, but long as soon as you're getting any kind of more specific leave alone, B2B, this feedback from the street is pretty much worthless if this is not an overlap with your target audience and this explicit expression of who are we solving for? Love that as an interesting boundary for people to articulate where they're going.
And I also love that kind of statement of yours that if you don't know it, then we can't work on it Now. It's like if we can't articulate what the problem is and who it's for, then of course we can't work on it. We've got to figure that out as a
Fundamental. Exactly. Quite. I observe a similar situation when people are on the goal definition processes and they land on a really good metric they could use as a goal, but then they realise, oh, we can't measure that goal yet technically, so we don't have the measures in place to measure the goal. And then one of two things happens. Either they abandon this great goal and go back to an evergreen generic KPI because that's easy to track, or they set a new goal, which is about create measurability for this very important goal. And I love to push Steve to the second option to make creating measurability a priority in an actual thing also for your roadmap potentially, right? Because then your objective or your qualitative statement shifts from something like We delight accountants in Asia by, I don't know, integrations, whatever might be a shitty statement toward we understand how to measure success for accountants in Asia. It's like this would be the actual prerequisite for working on meaningful metrics.
I love it. So I mean we've talked about maybe some of the things that go in there. What about visualising it? Do you have any preferred ways of visualising or styling for roadmaps?
That's a good one. I love simplicity, so I love the very plain now next later format with a roadmap card with some colour coded labels potentially. Again, I think it depends on how many aggregation levels you're having or sometimes I'm working with product portfolio within the company, which consists of eight product teams and I would probably introduce Swim lanes to be quite honest, to make sure that you're not trying to squeeze in competing priorities from eight teams into one column. So I think as soon as you're trying to cover two or more teams, I would love to work with Swim Lanes to make sure that every team has their own priority articulated. Other than that high more role visualisation styles, I think I probably haven't seen enough.
Funnily enough, it's probably Anna another few months down the line, we're going to be throwing that question out to the world saying, show me your roadmaps because there's so many I've seen, there's so many. My collaborators just in a scene, there's so many the people we're interviewing have seen, but we want to try and build that library almost.
It's interesting specifically with product management tools being on the rise for quite a while, I guess you will find a lot of very similar looking roadmaps because almost every product management tool has an underlying philosophy from the founders of the product people that goes into how they approach things like ProdPad and Jon Bussel being the most prominent example, which clearly the way ProdPad handles roadmaps is informed by Jon's perspective on roadmaps rightfully, and I think you'll see that throughout some other roadmap, product management tools as well.
Definitely. You certainly see it with Brian De Half and Aha as well. Mike Collaborator is an x aha team guy members, so we see the different styles quite a lot and in fact, so you hinted a couple of tools. I dare to ask, do you have a bad
Tool? I don't have one. I love to throw Jana's name out simply for the reason that honestly it's been a while since I used Prop, but just for what she has done for the industry in terms of shifting the perspective on roadmap. So I love to give kudos to her and consequently to prop at, I honestly try to stay away from the tool discussion as much as possible because I feel that it's a bit of a, what's the right word? I think there's honestly, I'm not sure how much the Pure roadmap feature, I'm not sure how much differentiation is in there. I think where the tools shine is everything they build around the roadmap. So how holistic is the understanding of the tool of what goes into a roadmap? I think that might be the differentiator. Honestly, I love using getting started with something like Mule or Bureau, something very freeform and without a lot of structure just to figure out the general sentiment. Similar with two OKRs. We'd say it started with Google sheets for Excel, get a sense for it and then once things get more complicated or want to commit to it even further, or you find your groove, choose a tool that suits needs.
Yeah, I don't know. I think I agree wholeheartedly. I was close to sourcing the tool in my last corporate role. I am a part of Broadpath these days. It was a different tool I was going to source, but I try to stay agnostic because it's all contextual depends on that organisation set up. So yeah, I feel your position and understand it well,
And it's always interesting because many companies want that specific recommendation for the tool, right? Think again, it's so difficult. It's like whatever tool I think, and you can tell a lot about how well the tool might fit for a company, but looking at the landing page because articulate, they articulate their stand, what's their perspective on product? I think this is almost to me more important than the actual feature bucket list. There are certain hub facts. I would look at things like the integrations I think, which is super important to make sure that the tool can play nicely together with the existing tool to you're using within the organisation to ease the adoption of the tool and the regular usage. Other than that, I think it's more about the attitude and a certain baseline quality execution.
Yeah, I agree. Okay. Now let's switch gears again a little bit. What do you consider to be best practise in terms of roadmap?
I was just coming over a conversation. So I love to avoid the true best practise to be honest, because I think it paints a picture of it's this or nothing of this depends on the people interpreting it. I try to be a little bit more, again, you could argue diplomatic or I would say realistic, which is more better practises. So it's like depending on the context you are in, what could be a teeny tiny bit that would help you to make things a little bit better already without getting intimidated by the over-glorified perfect by the book example.
So yeah, I think some of the better practises, which could be stacked or take it individually is I think switching from the traditional long-term gun chart to column based and more loosely time, time more loosely if find time horizon. I think it's a great thing making sure you can connect your roadmap to the other artefacts you use in your company for prioritisation like OKRs or if you use any kind of scoring, make sure that these things go hand in hand together. So don't try to create a parallel universe but connect it to the other bits and pieces that go on. Again, those decisions, those prioritisation decisions are already happening. The roadmap is more like the window you're creating to communicate it more easily for other people regularly updated sounds obvious, but I think there does have to be a fixed cadence for when you adopt it and you might not want to rearrange it every week, but make it part of those goals. Strategic discussions you're probably having at least once or twice a quarter might be a good idea.
And then bringing the clarity around the problem and the measurement of success in there as well. So don't go straight from broad qualitative statement directly to feature activity, but make sure you have this middle layer of problem worth solving and potential success indicators in there as well to make sure that you're not spinning your wheels to like, oh, we moved the item, we ticked off the boxes, we built the feature so we are successful. Which is of course the broader discussion. I think probably the last one just inspired by the last bit of our conversation, not over tooling, so don't try to over tool it if that's a word I don't know works for
Me.
Yeah, it works, right? It's like don't over tool your roadmap approach. That's a nice headline. This should be something to consider. Again, this doesn't go against roadmap tools per se, but against the idea of starting with the tool and modelling your roadmap approach after the tool. I think it should be the other way around.
Yeah, love it. So let's flip the other right way around. What's the biggest mistake you see on roadmaps?
The biggest mistake? Yeah. I think just leading with the feature and leading with the feature and reading time horizons on a roadmap as it has to be done by that. I think most of the time I would rather embrace a best effort approach for the teams, whether it's in the discovery or the delivery space doesn't really matter. There has to be an intent to deliver as many or best possible features to create a certain drive, a certain metric forward or to reduce uncertainty as much as possible. I think this should be the goal within the roadmap and be a little bit more flexible when it comes to when is the roadmap item really done? Is it only if the last spec of a feature has been delivered to the pixel or is it like if you're close enough to the metric you try to move and it's fine to shift to switch gears and to no longer focus on it.
I think another anti parent might be to completely neglect the idea of the need for potentially more specific timelines having to be articulated for very teeny tiny delivery. I think, I don't know if it was CTO Lombardo or Jana who I heard it from, the idea that there might be the need for a more tactical release plan with specific dates to accompany something like a clearly articulated roadmap and that these two things can be two different artefacts. It's probably still mind blowing to many, many companies. So even though love the more loosely defined time horizons, I think it's important specifically large organisations to acknowledge the need for more specific date oriented statements around when something will exactly be released to coordinate things like GoTo market initiatives or customer
Service. And that sometimes comes up at that discussion point of other related artefacts and that separation. I think John Cutler also talked about we need to understand the jobs to be done of the roadmap, which is trying to say the same thing. We're trying to do many things with one tool and actually maybe a few separate ones would make it work better.
Exactly. That's an interesting balance to strike. Making sure that you're focused on the jobs to be done of the tool you're using and not trying to combine too many things into one tool then becomes a big roadmap item, becomes a two pager almost, but at the same time not, I would argue not making it too granular and have too many atomic artefacts floating around where it's then very difficult to piece things together and how things are related to each.
Whose advice do you listen to about road mapping
Santa Bato without much hesitation. Cita Lombardo as well, predominantly for his work from the road plan through launch book, which is a staple of my bookshelf even if you can't see it right now. Obviously he's as well. And honestly I love listening to practitioners within organisations who own the craft of establishing processes that work. So that would be people in the product ops space for example. Lots of companies I work with have really mature, very well established product ops organisations who spend a lot of time thinking about exactly this kind of question of how do I make roadmaps a useful tool by and how can roadmaps become a useful tool that support this change, this larger shift from outputs to outcomes. So yeah, those would be some of the people I would love turn to and again, people in the product ops space, they have to figure out how do I make this craft that ties in with other efforts and becomes actually useful without just introducing new framework for the sake of
It. Yeah, totally. I mean it's an interesting growing area. It's that product ops. I mean I look back to the last team I ran and realise I was doing it without calling you to, there was one member of my team was clearly doing that
Activity exactly
And now have a label to put onto it what he was doing.
Exactly. Which is good for our industry in a certain way at least I think it helps create this explicit awareness for this need of this role and you can now put a job position out, been higher for this role and get budget for this role without making it an additional responsibility for people. But of course we should be careful to not overload it and make sure that it stays
Practical. And so you've mentioned some names. Are any particular resources beyond the roadmap relaunch book but you also use or recommend? That's
A good one. It's actually, it's my go-to there is this, honestly the one resource I go back to which is related to the book is from the Mind the product talk from C tot Lombardo, I think it must have been might, the product San Francisco 20 18, 20 17, 20 18. You gave a really good talk summarising the to honestly, I think it's still the best. I don't agree with everything, but it's the best talk summarising some of the key bits and concepts and it's a nice storyline, which is I think what makes it so good for communicating it into executives and sending it over because it's easy to digest even for people not being in the trenches.
I might have to go back and look for that. I probably have watched it at some point, but there's so many things
I can do. Sure, for sure. But I
Always like to
Check
Things out again.
Yeah, than that I wouldn't say my go-to resource. It's the things like prop pad block, obviously this into an unpaid prop pad promotion. But also as I mentioned, I think I mentioned Andrea sas, who is a former product marketing manager from Pad, I think is also really, really spot on in that space.
Now the hard question, if you had to distil your philosophy on road mapping into one or two sentences, could you, and what would it be?
What would it be? I think my key philosophy would be to find a roadmap format that supports the organisational change change you seek to create whatever that is, and work with explicit prompting questions to help people fill it. Right? Sounds completely wrong, but I think you get the idea without solving people, oh, this an outcome roadmap. We now put outcomes. Every roadmap item that leaves too much interpretation. So I think create this explicit understanding of what kind of change in thinking you want to create through the roadmap and design the roadmap accordingly, whether that's through guiding questions, templates, fill in the blanks, whatever it is, or tools. Yeah.
Cool. So then I'm going to ask you the classic, I forget who it comes from, might be a Steve Blank or something like that. What should I have asked you about roadmapping that I haven't?
What's the roadmap item I'm most ashamed of ever putting on a roadmap would probably be a fun question.
What's your answer there?
I have to admit, I'm not sure if I actually put it on a roadmap, but it's certainly something that it would've been on an artefact, like a roadmap level, which was a startup I was working on just trying to disrupt the dog sitting industry and we're building a mobile app doing that. None of us owning a dog even, but we're very opinionated investors. And so one project we committed to was we had a map with little pins or points of interest on there and we made it a priority to add a drop shadow to those pins on the map so they're easier to spot
The inner designer coming out of tin.
Yeah, and I mean honestly, there was more of a semi forced effort of like, hey, our investor being honestly 60 plus non digital native are saying it's difficult for me to find the pins on the map. We should make these more visible. We're like, okay, that's that shadow to it.
Tim, it's been great having a chat with you today. I guess last few seconds, here's an opportunity to give a pitch for your offering so that people, if they find you through this, can get in touch and get your help.
I like to pride myself in talking more about better practises and so I think that's what informs most of my content. So if you are interested in data practises that help you improve from wherever you are on your journey as a product team, make sure to check out my newsletter, go to my website, Heric Do co. And I try to distil fun the thoughts like shared in the last couple of minutes with Phil and this newsletter every week goes out except for the upcoming summer break. So yeah, would love to welcome some people there to get some perspective on my thinking.
We'll make sure the link to your site, it's visible and available for people here. So awesome. I say, Tim, thank you very much for your time today. It's been great talking, great to reconnect. As for the whole world, I'd just like to please remember to subscribe and share all those useful things that help the channel get found. You'll obviously see some shares on LinkedIn and stuff like that as well. If you'd like to take part, if you'd like to do what Tim's just done, please do reach out, get in touch. We'd love to have you. We'd love to have a conversation. Thank you again, Tim, and see you next time.
Thanks so much for.
