Do you get feedback on your roadmap? | C.Todd Lombardo
In episode 15 of Talking Roadmaps, Phil Hornby interviews C. Todd Lombardo. They discuss the true purpose of roadmaps, emphasizing that they should describe the destination and the journey rather than predict specific features and timelines. Todd shares insights from his extensive experience in product management and consultancy, highlighting the importance of continuous learning and a growth mindset in product development.
He’s a data nerd, a design geek and a product fanatic. He focuses on building and mentoring teams in areas of user experience design, product management, and product strategy.
He’s currently the VP of Product at Appcues, a product-led company that helps other product teams convert, retain and delight their users. He has also worked as a design and product strategy consultant for notable clients such as: TripAdvisor, LogMeIn, Spotify, New York Times, BBVA, FedEx, Lowes, and Genentech.
Most famously in the roadmapping space he is one of the co-authors of Product Roadmaps Relaunched, along with Bruce McCarthy, Evan Ryan and Michael Connors.
“Sharing your roadmap with customers is a way to get feedback on your product strategy”
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
Next up we have David Bland, author and innovation expert. So watch out for Episode 16!
PS. Sorry for the audio quality issues on the last 3rd from me, my microphone failed and it switched to another one without me knowing!
-
- Welcome to "Talking Roadmaps," everyone, the podcast and YouTube channel where we talk about everything roadmaps, from the good, the bad, the ugly, talking to practitioners, thought leaders and all the rest of it. Today, I'm joined by C. Todd Lombardo. C. Todd, I'm pretty sure people don't need you to be introduced, but go ahead and introduce yourself anyway.
- Oh, man, amazing. Thank you, Phil, for being here. So introducing myself, let's see, I've been in the product world for kind of a while. My first product management job I think was like 2003, 2004, so I'm totally dating myself. But the last decade has been spent much more on the software side. My first product management job, I had a biotech instrument which had hardware, software, firmware, chemistry, and biology all mixed together. So if you think you're getting your front end and back end to work together is hard, try getting all those things to work together. But yeah, I'm a little bit of a pracacademic. I teach at a couple of schools, a business school in Spain called IE University, and I've been sort of in a variety of products, roles, product teams or working as a consultant for product teams over the last decade or so. You know, because of my pracademic nature, I like to share knowledge, so hence writing a couple of books. "The Design Sprint" was the first one many years ago, followed by the book with Bruce, "Product Roadmaps Relaunched" and then the most recent one around product research roles. So currently, I am leading the product and design teams at a company called Appcues, which is a product led growth company that helps other companies build good app and app experiences.
- Awesome, funny enough. Yeah, so well it wouldn't be right, Tom, to be on the roadmapping show and not have a copy of this in my hand. But both of those other books are also, I'm about 50% of the way through them both because I have this habit of having 10 books on the go, dipping in, dipping out, and-
- I have the same problem. Here are the two on mine and I'll give a plug to, you know, our friend Daniel. I got his right on my desk and I have another one called "Captains of Leadership" around facilitative power and facilitative confidence. So I'm right there with you.
- Constant growth mindset and learning I think is a critical part of product management.
- Never stop learning.
- Just for everyone out there, the mandatory, gotta ask you to like, subscribe, hit that bell icon, heck share it, or if you'd like to join us here on the channel and have a chat. You know, you don't have to be as big a name as C. Todd, you can be someone who's just out there doing the job in a product organisation, we'd love to talk to you. Hit us up on info@talkingroadmaps.com, we'd love to talk to you.
- Smash that bell, as they say, right?
- So C. Todd, let's start with the fundamentals.
- [Nick] Yeah.
- What is the purpose of a roadmap for you?
- Oh, the purpose of a roadmap. Why do they exist? I think a lot of people look at a roadmap and think it's gonna predict the future of my product. And in some cases, it kind of does, but it shouldn't be like what's coming and when, like what feature am I gonna get and when? And that's I think the misnomer about it. But a roadmap should describe that, if you think about the metaphor, right, it should be described that destination and mostly how you're going to get there. And I'll use the metaphor continually to like dig into it even further. So I'm here in the Boston area and if I'm going from Boston to where are you Phil, in in the UK somewhere?
- UK, yeah, near Sheffield.
- Near Sheffield, right? So if I'm going from Boston to Sheffield, how would I get there? Well, I'm probably gonna have to take either a ship or an aeroplane. So my roadmap would have to tell me which mode of transportation I might go. And there's probably some level of turn by turn directions I might need now to like get myself from here to the airport. And I would say those turn by turn directions are very specific and what's right in front of me because I don't need to know, like today, I don't need to know, like right now, I don't need to know the right and left turns I need to take to get to your place in Sheffield, but I do need to know the right and left turns to get out of the Boston area and into the airport, right? That's what I would call your release plan or a project plan, right? Shorter term, very focused, has discrete steps you're going to do. That's not your roadmap really, quite frankly. Those are your turn by turn directions, right? Your roadmap says, hey, going to Sheffield, we're gonna take a plane, this is the rough way we're gonna go. It gives me a vision and a destination and a direction of where I'm going, right? So that's really what a roadmap does. It gives you that level of strategy and direction.
- And so who's looking at that strategy and direction then?
- A lot of people, especially anyone who is interested in your product. Oftentimes, it's your internal stakeholders. They could vary based on the kind of organisation that you're in. It could be maybe you make an internal product that never gets exposed, but could be, you know, all those internal stakeholders, or if you do run a software or a company that has external users, it could be them or it could be all the different executive stakeholders, like your chief of marketing, chief product officer, sales. Like oftentimes, if you're B2B enterprise sales, you've got a salesperson saying, "Hey, my customer wants these features. Can we build them? Are they on the roadmap?" Right, that's a common thing you see happen. Depending on the size of your company, it might be your CEO. And of course, your engineering team, whether it be directors, et cetera. So a lot of people, right, I just named a tonne of folks. And the point is a lot of people look at it, but classic case of it depends on who and how you tailor it for them. There are some organisations that advocate for and do share an external version, they make it public. Of course, they edit them and don't share every last detail, but that's a common thing you'll see for some organisations that want to do that, want to engage their customer base with a publicly facing roadmap. There are challenges to that, don't get me wrong 'cause especially if like, what if you put something out there that you don't end up doing? But at the same rate, like John Abasto is very much an advocate for this and he says, "Hey, you'll know where your customer, your customers will tell you where it's not gonna add value for them." Cool, right, it's a way to get feedback on that product strategy?
- Yeah, so if you talk about those different options, but I think, just to unpack it, you talked about editing for the audience. So do they see the same version? Do they see something different?
- Yeah and kind of like you want it all to come from the same place. Right, you don't want to have like a thousand versions and they don't actually reflect each other. So you want them to all come from the same place, but you might edit them based on who they are. If you're a large organisation and you're presenting to your CEO, you're probably gonna get rid of all the details and give 'em the high level. Like these are the areas you want to go, this is the reason for the strategy, these are the kind of KPI and metrics we expect to move along the way. And that's that, right? But maybe if you've got, like I'm presenting this to my engineering team, like I want to give them all the little details like hey, these are the features that we might expect to see, these are the kinds of things we want to go into. You might have a deeper level of detail depending on your audience. So again, they should all come from the same place. And some teams have, they use roadmapping software like ProdPad and Productboard, you know, insert app name here, there's a lot of them out there that are all quite good and they obviously allow you different ways to create and share those. So those are very useful for that. But at the same rate, you could also do it with Excel and PowerPoint, or sorry, you know, Google Docs and PowerPoint some way, whatever way you want to do that. So it's totally possible to do a lot of those things. But yeah, sharpen it and shape it for the audience is really important.
- I think I, I was interviewed myself by my collaborator, I think I said I'm on four or five different views of that one sort of truth potentially these days. It's like I'm starting to get a lot, that's when I think the tool comes in maybe and helps you a little bit.
- Yes, that helps a lot when you have a lot of different types of stakeholders and you need to edit or not show certain things or show other things, for sure.
- I can imagine showing my engineering team that five year projection that I might show to my execs and they're just gonna lose their rag.
- They'd be like, what do I build though? How do I do this? And it's like, yeah, okay, well yes, we're gonna get there, but you don't need to see, they don't need to think about all five years in fine grain detail as an engineer probably should. I often think about it this way, the roadmap is that like plan of intent, right, it's your plan but it's uncommitted. So it will probably change, most roadmaps usually do, so be okay with that. Whereas your release plan is like we've committed to doing this, we're going to do it, it's shorter term and it shouldn't change as much, right? So I sort of use the 80/20 rule for either, right? Your roadmap might change up to 80% but 20%'s always gonna be pretty steady and stable Whereas the inverse of your release plan, 80% should be pretty stable 'cause it's what's you specked out for your engineering team, it's what they're planning to build in the next one, two, three, five months. But beyond that, they're probably not like uber detailed depending on the kind of product you you have, right? Those are the two differentiators. And I think that's probably the big difference that I want to call out a lot. A lot of people think those two things are actually in the same document, that's probably the biggest mistake I see.
- It's the jobs to be done of roadmap where I trying to ask you to do too many jobs and so I end up doing them all badly instead of a few really well.
- Yes, yes. And that's kind of where I think maybe you mentioned that Bruce and I are gonna be rewriting another version of this, a second edition to this book coming up and part of it is, the overall thesis of the book is quite sound, but how we explain it and how we sharpen some of those conversation points around like, yeah, here's, really, it's the job to be done, right. using some of that language, which will be really useful in clarifying the concepts in the book.
- That said, it's still, even in the current version, full of epiphany after epiphany I've got to say.
- What were the things that stuck out to you? So a little customer discovery on my end, like what stuck out for you? What are the epiphanies that you walked away with after reading it?
- Breaking the timeline, moving from timelines to timeframes. I mean I come from, you talked about that type of complex product in the biotech you did and maybe wasn't doing that, but I was typically doing what we call IOT type products these days. So complex, connectivity, hardware, software, backend, embedded and bringing all those things together. And I'll be honest, I still haven't found a better way than a timeline for physical products. But that kind of step away, and there was always that perspective from the, as soon as I went to that, say the now, next and later, customers wouldn't accept it or management wouldn't accept it. But in my experience, it's actually they usually do, they realise it's more honest.
- Yeah and it's part of it is like, I think we had a quote from the book from, I think it was Dave Cancel. It was like, you know, I'm either gonna disappoint you by telling you what I'm gonna do and I'm not gonna do it or I'm gonna lie to you. Right, you're asking me to do one of those two things. It's a rock and a hard place. So why don't I just be honest with you and tell you these are the things that are coming up next? I can't give you just explicit timeframes, maybe the shorter term thing, sure. And when you're thinking about hardware, software, the thing that I always try to do is like look for, look for the connection points. Like your hardware needs to go off and obviously, you can update firmware and update software to a certain point, but figure out where those points or those sort of like connection points are, where it's like, yeah, I can develop my hardware to a certain point or a version of this and then I'll be able to update software to a certain point beyond that, right? And like you just think about the over simple ones of our phones in that at some point, Apple's like, yeah, I can't support this hardware anymore with firmware and software updates, so you need to upgrade or you're just gonna stay in that version, right? And that's a hard truth of any hardware. So find where those points are and just kind of put 'em on the, stick a pin in them and say okay, these are the things that are like knowns that we have to design and think around and plan around, but the stuff in between leading up to and after that can obviously change.
- What I think about that physical product on the portfolio level, you have that challenge. It's like Apple, is that TikTok once a year, new iPhone coming out? Well that's a timeline at the end of the day. I'm putting a date on it. And there's certain things like getting into catalogues and so on but then I guess is that's a release plan.
- Yeah, it's a release plan. But they don't tell you like here's when the next iOS, like the specific iOS build is coming, right? They don't really get a specific timeline for that. They just kind of like when they're done they ship them and your iOS updates, right? They don't necessarily publish that but they have those very specific, like those are those, those points that I mentioned, like those connectivity points between the hardware and software like yep, here's this. And they've gotten to a point where they're big enough and can be predictable. I think that actually speaks to some of this, like there's an element of predictability that people want, which is why they're so attracted to seeing your roadmap. What's coming and when? Right, can you give me some predictability? And that's part of where I think some of these, this approach, whether it be Now, Next, Later or Q1, Q2, Q3, whatever, just not getting down to like month and week level, that starts to give a little bit of predictability. Like here's what's coming. And if you also frame it with it might change, then okay, right, you've at least set the expectation of here's what we're planning, it might change. You want to know what our short term is, check out our release plan. And you might may or may not want to publish that so it's up to you guys.
- There's probably still that portfolio level, which I know is part of the plan for the next edition of the book that is-
- It is, we don't talk about that, it's right.
- 'Cause I think at the individual product level, it's quite clear how you can manage that. It's that next level up that I sometimes find a little more challenging.
- Yeah and one of the other things that we kind of want to dig into is you think about, like we talk about like setting your vision and your goals, making sure your goals and your objectives are part of one of the five main components, but what we don't talk enough about, I think we've mentioned it very lightly is like, well how do you structure your teams to match your goals, which matches your roadmap? Like Conway's law is in effect here in some way. And so making sure that we're talking about how do you set up your teams for success too? Because sometimes you'll, we'll talk to companies and they'll be like, well I have this, but then I've got a front end team and I got a back end team, I got this other team and everything's functionally aligned. It's like, okay, but do you deliver value just with front end only or just with backend only? Well no. Does the customer only use the front end or only use the backend? No, they use both, right? So how do you slice and dice your teams to match up your objectives to match up to your roadmap? So they're all intertwined, one affects the other in some degree, so we don't talk enough about it so we need to dive into that more too.
- So I can anticipate we're gonna be talking about platform and experience teams and this sort of thing coming forward. So okay, interesting.
- Yeah, yeah, we need to add that layer in. I don't think we talk enough about it so.
- Funny enough then, who owns the roadmap? Any thoughts there?
- I mean I'm very biassed, but I think the PM should own the roadmap. Right, the PM should own the roadmap and it should be driving outcomes. Engineers and engineering teams own the release plan and that's defined the outputs. Now granted, you get the outcomes from the outputs, so they obviously need to be very much joined at the hip, but I'm a firm believer that the PM is the one who owns the roadmap with a lot of influence from a lot of different folks. And that's what makes PM hard, right? They've got to align. Everyone wants something on the roadmap and what they want needs should be at the top, right? Well that can't happen. It's like saying everyone expects to be above average, but that's not true either, right? So you can't have 100% of people above average. Only 49% I guess are. So similar kind of thing, and how do you align that? And how do you make sure that everyone is okay with that and okay with those trade-offs? And that's a lot of why a PM job is so hard.
- So then would I be writing assuming that the product manager also maintains that roadmap at the same time?
- Of course. They own it, maintain it, they update it, they share it. Absolutely. And it should go out for, you know, some people ask me, well how long should it go out? Should go out like three years, five years, 10 years? I was like, it kind of depends. There's no one right answer. Like for one team, it may be like, you know what, a roadmap that goes out three to six month is perfect and another team might be like a super mature product. Like look, if you don't have something going out three to five years, you're slacking. Right, it really varies. And I think that's, you know, maybe we can put a little more context around that in the next edition too is like, hey, here are the examples where like a short term roadmap is a really good idea and your release plan is probably like two weeks. And then there's another example where like you probably want a three to five year roadmap at a minimum and your release plan might go out six months, right, type of thing. It all depends.
- I mean, I could even imagine having a release plan that goes out that five years, we're just not seeing what's in it. But we're gonna do, we're gonna release certain milestones 'cause they hit market windows or cadence in an industry.
- We gotta hit this for this hardware, you know, update or in these areas that we've gotta get our hardware ready for this point in the future. So that means, you know, what does our software cycles need to be to get there? Again, finding those points in the future which things need to converge and align are critical but once you've aligned those, then there'll be other points that, or other streams that might be able to go at different cadences and velocities.
- You mentioned vision or objectives. I know there are two of the key parts of the roadmap in the book. What about strategy? What about other artefacts? What else kind of links in or relates in?
- Yeah, for sure, definitely sort of mission or vision, especially if it's a team level, right? Like depending on the size of your company, you might have a large company mission or vision that does one thing, but your product that you're managing might be one part of that. I think we give the example in the book of Google, like if their mission and vision is to organise the world's information and make it accessible, great. But if you're a YouTube product manager, like YouTube itself is its own product and well that mission and vision is like well organise information but it in video content and make it accessible, right? So it's related to the main companies, but it's different in terms of like maybe the type of organisation, the type of content, type of channel it is, right? But there's still some relationship there. And you can even think about their sub below that. Like, okay, we've got creator level products and you've got viewer level products on YouTube and they may each have their own, like hey, allow creators to really easily create and deploy an audience management on YouTube. And then a viewer to be like, how do I view, discover, find? There might be different kinds of mission and visions there that you could could think about. And so those all can be described on our roadmap. And of course, the things you also want to make sure you, it's a little bit about how, right, strategy? Like how are we getting there? So if this is, again that end destination of Sheffield UK, how am I getting there? Well I'm gonna take a plane and this is the kind of plane I'm gonna take, the kind of airline, the kind of class I'm gonna go in. Right, starts to give some attributes and maybe problems to solve along the way, right? Right, I have to get to the airport. Then once I get to the airport, I have to get from the airport into Sheffield. I'm gonna go from Sheffield, I gotta get to Phil's house. Like all those things of like what are the maybe a little bit layered down without getting maybe to the turn by turn directions at least gives me some indication of way points along the way to get there.
- So this is an area I've been thinking about a little bit. But then we get to the innovation and of things where actually we don't really know the end destination, you know, kind of, I tend to think of the exploration. It's like if we were to draw a map for that, you've got the here be monsters part.
- And that's great and that ends up being more of a, probably a technology development. Like, oh, we're trying to develop a technology, but are you still solving a problem and what's that problem you're trying to solve? Can you contextualise that a little bit? And maybe that's where a difference between a product roadmap and a technology roadmap might come into play. It's like look, I'm looking at developing and advancing this technology. I don't necessarily have a use for it, I just want to dive in and see, you know, is this even possible? Cool and then you can start to think about what use cases you might have after that. So that might diverge a little bit, but I think a product roadmap is different in that it should have some kind of customer value and destination to it. So if it is an innovation perspective, maybe it's just a technology development roadmap. It's less of a product roadmap, I would argue.
- So I mean I know in the book, there are five key elements that you talk about on a roadmap. Since you've thought about a bit more, is there anything else you'd change? Anything you'd add? You know what's the main content that we need to consider in there?
- Yeah, yeah, I think they're mostly still pretty relevant. And the way I also frame it is we talked about having a vision being part of it. It doesn't have to, like once you've established it, like maybe you're talking about it to your internal stakeholders and they understand, like they know your vision, okay then maybe you don't need to repeat it ad nauseam to them, it's good to have, make sure it's there. So if the team is very familiar with it, do you have to have it on the roadmap you're presenting? Maybe not. Always good to tie it up, like, hey by the way this is our vision, making sure that we're actually still tying things to that, it's still very useful to do. But I still think having some kind of goals, objectives, very important. Now some people, you know, OKRs, OGSMs, EOS, there's a lot of different goal-based frameworks and whatever they are, some form of goals of what we want to achieve, right? And that's probably from a business perspective and even potentially a customer perspective. And that might flow out to be like, okay, well we want to reduce our self-service costs, which means we want to reduce the number of support calls coming into our company, we want to add more self-service tooling to our software so that customers can figure things out for themselves much easier than having to pick up the phone or chat with us or whatever, like one example. Cool, then so under that, there may be other different thematic areas, hence the word themes. I've also heard of like initiatives, they could be even be objectives that are sub-ojectives themselves, ways you're gonna hit those goals. So that's sort of the third bucket item is like what are the initiatives or things you're going to do to reach those goals, which will help you reach those vision? Notice it kind of always cascades. Yeah and then you wanna make sure you have some kind of disclaimer, like, oh hey, by the way, this is a draught you have as of July, 2022 so that you know that that's the timestamp and it's a draught and you're setting that expectation, right? And the last thing is, on a date perspective, this is the timeframes. Right, we're not talking about a specific timeline, we're like these are timeframes. Now, Next, Later is a common one, that's thanks to Janna Bastow, Q1, Q2, Q3. There's a lot of different ways, like first half, second half, this year, that year, depending on the level you need to have, whatever interval you want to put there. Is it monthly? Is it quarterly? Is it semi-annually or annually, right? And think about that versus a, you know, here's a set of weeks and this is when we're gonna deliver these things. So it's less about delivery, right, and more about strategy and where we're going versus we're going to deliver these things on this timeline, that's good for a release plan.
- So okay, we've got the key content, what about visualising? Any strong feelings on how we visualise? I'm a fan of visual roadmaps. Andrea, not so much, I wonder where you fall on this one.
- No, I agree. I'm a visual thinker. I love to visualise things so I think it's really important. That said, I have seen great roadmaps that are literally like an Excel spreadsheet. Like they literally look like they were copied and pasted from a spreadsheet and it's like wow. But when you dig into it, you're like, oh, this is really done well, and here's why, it has objectives, it has themes, it has some status and some objective, like it's really well done. Whereas some of them are like, if they're just like overly visual with no structure, then that's a problem too, right? I want to be mindful, like to call out like yeah, be careful of the Gantt chart, you know, be careful of the Gantt chart lure 'cause it is very alluring to be like see these bars of like the starts then, stops then. And not a bad thing and there's a lot of, you know, you just don't want it to have like concrete dates. It might be like, yeah here's our bars of when we expect to roughly be tackling these particular initiatives or themes or elements so it's certainly not a bad thing. And especially when you're thinking about portfolio, like the one I did at my last company, like we had to stack it and we had to have like, it kind of looked like a big Gantt chart in many ways, but it wasn't like a typical Gantt chart where like everything was like, you know, this waterfall element of things underneath it. It was like, no, this is the rough time we're gonna be tackling this initiative, rough time we're gonna be tackling this initiative, et cetera. And it was useful for us to see it in this big long document that had all of the products across all the teams available so we could start to think about, oh, we're trying to do a lot. Do we have the resources? Are these prioritised right? Should we think about, you know, dissolving one team and giving the other team resources or giving one team more priority than another because of business value, right? And that's really useful to see those in that way to say, oh well they're not tackling this till Q2 of next year, they're tackling this now. You can start to see those cross team opportunities show up and it's really, really useful. So I'm very much a fan of doing it visually. I think we used Productboard at my last company, it worked really, really well. But I know that there's plenty of others that have similar kinds of visualisation.
- You mentioned a few tools as we've talked there. Do you have a favourite?
- I don't know if I have a favourite. I have a lot that I've liked that I've used over the years. Productboard's pretty good, ProdPad's great, but I've also used like Aha! and ROADBOOK and a few others and they're not bad either, like there's a bunch of them out there. And there might even be one I'm missing, I think Air Force I tried a little bit. We use Canny at Appcues. They all have like pros and cons and a lot of the things, you know, I look at it as it needs to serve a couple of jobs. One, you need to pull all of your product feedback into one location, sort of a centralised database, and you need to tag them with thematic areas, and preferably if you can get the customer's name associated even better, right? Because it's better than having like a Slack thread with a whole bunch of stuff or somebody putting stuff in an email, like stuff gets put everywhere in a lot of different channels. So you need to figure out a way to centralise all of your product feedback, whether it be internally or externally, right? Gotta put it in one central location. Second thing you need is a way for a team to map out what their plans are, map out what their roadmap is over the next whatever timeframes are useful. Like if you expect your teams to be, you know, crafting one to two year roadmaps, then they should be able to do that, right? Their six month roadmaps, they should be able to do that, right? Whatever time horizon that is useful, they need to be able to map that. And so when you start to connect those two together, and that's where some of the, some of the tools are really useful is like, oh I can put the roadmap theme areas over here or objectives and then I can actually attach these five pieces of feedback to this one initiative the team's working on so that I know which customer was interested in it, when they were interested in it, what did they say about it, et cetera so the teams can, the product teams can look at it and say, oh great, let me go talk to these five customers 'cause they had requested it or they had asked about it at some point and it's been in our database. So I think, you know, there's really two to three of the jobs to be done that I think about for product management tooling, for product roadmap tooling. And I think the first two are the most important. The third one is kind of a nice to have that you can do manually if you don't have that. But those are the three key ones that I see.
- So, okay, now let's dig into, let's get specific. What's the best practise that, you know, if you had to say one thing on a roadmap?
- Only one thing, that's really hard. If it was one thing, I'd wrap it up into a product strategy, right? That's kind of really what it is, it's an artefact that describes your product strategy. And there's a number of different ways to do that. Like GitLab describes it in blog posts form, like they do a great job at describing it, it's very verbal, but they describe it in very verbal form whereas other teams might do it in a much more visual way, they did it in a very prose storytelling way. And that's maybe the other, the secondary thing is like you've just gotta tell a story, right? You've gotta tell a cohesive story as to where your roadmap is going and why, right? And you do have to get to the why. So like if I said, why am I going to Phil's house? Well it's because we're gonna talk about roadmaps and we're gonna do it in person, we're gonna do it this way and this is the reasons why, like I'm gonna have to have a good why behind the why so to speak. So maybe that's the higher, higher level question, it's less about the when and more about the why.
- So then let's go the others end of the spectrum, biggest mistake or biggest anti-pattern you see on a roadmap.
- Sure, the biggest one is the one I mentioned earlier is like people think the roadmap and the release plan are the same thing and they try to create one artefact to do both. See it all the time, all the time. Even today, the teams I talk to, they struggle with being able to do that. You know, and then sort of the dirty secret is that I'm okay if you put a feature or two in a roadmap if it helps you with the conversation. It's like everyone knows it's a problem to solve, everyone knows it's validated, everyone knows that that's the thing we're gonna go build so throw that in the roadmap if it makes it easier for the rest of your company to understand it. That's okay. Otherwise, if it's not unvalidated and you don't have the clarity, then sure, put the them of the problem to solve or the goal you're trying to achieve. But if all those boxes are ticked, there's nothing wrong with throwing a feature on there, especially if it helps with the conversation. 'Cause again, as a PM, it's less about is my roadmap, you know, technically and academically perfect? It's like no, do you get alignment? It's a tool to help get alignment for where you're going and you actually want to surface the differences in thoughts and conversations 'cause that will actually help you get aligned.
- So how is my roadmap aligned with discovery then? 'Cause that's kind of fundamental is that getting aligned and kind of finding the differences.
- If your roadmap is sort of a list of thematic elements or initiatives and problems you'd like to solve for your customer and/or business, actually, ideally it should be both, right? You should be solving for something that is user value and company value, right, it should be a mix of the two things, not just one or the other. And so, especially for things that are beyond your release plan, you should have some element of like, yeah, we need to be doing discovery around these things so that we know what we're tackling. Like is the UX team aligned that yeah, we're gonna be tackling self-service items in the next quarter, so let's make sure we, any interviews we have lined up with customers, they're around how they struggle to do things and when the last time they actually had to call customer support for, and then then getting data quantitatively around all the number of times. So it can help identify the teams to prepare their discovery activities because they know where they should be focusing.
- Well, so it maybe overlaps a little bit with the biggest mistake or anti-pattern. Do you have a pet peeve, something you just really don't like seeing on a roadmap?
- Probably, I think it's similar but it's really like the detailed dates. Like all right, here's January 28th. Like why? Like that's a project plan. Like we're gonna, this is gonna be released January 20th and it's like it's July but you're talking about January 28th is gonna be the day you're gonna ship it. I'm like uh huh.
- So I guess so long as you gonna ship, but you can flex what's going into it, the good old iron triangle, then I guess you can commit to a date, but then who knows what the heck you're gonna give 'em?
- Right, how many vacations happen during that time or the holidays get in the way? Does somebody get sick? Does anyone quit or do you hire somebody new? Does that change any of that? And the likelihood is all of those things will probably happen between now and January 28th. So don't say January 28th, unless it's like, oh we have it like a conference or something, an external event is causing us and we have to have this stuff ready by then. Then okay, great. Then back plan, like what is the minimum we need to have by then? And then what's the idea, like then you start to really prioritise like I have to have this, but a lot of those things are rare. Many of them are self-imposed and when you poke at them you say, well what's that date for? Well we just like to say, or some CEO or some executive said it should be by this date. Well okay, but why? And if they can't answer why, like, oh there's a conference, there's other date, there's other things, something related that's usually external to the company, probably those dates, as Andrea probably says, those deadlines are BS.
- We have a habit of making deadlines because we've been talk that they help us hit them whereas actually they probably do the opposite. So I mean obviously a lot of people listen to your advice on roadmapping being in the book, but if you're listening to advice on roadmapping, who do you listen to?
- Let's see, I would listen to Bruce, I would listen to Marty Cagan, I would listen to Andrea, I would listen to Daniel Elizalde, I would listen to Gibbs Biddle, even though we have a slightly different take, he did an outcome-based roadmap with Bruce I thought was really clever. Who else would I, Teresa Torres, Hope Gurion, those are great voices I think, and Melissa Perry, those are people who I would listen to.
- Many people I listen to, a few of them we've already got lined up but a few more that looking forward to talking to hopefully in the future. Are there any particular resources that you use that you could recommend for people?
- I think, you know, following Teresa Torres's Product Talk is always great, very discovery-focused, but certainly useful. Marty Cagan, Silicon Valley Product Group blog is great. Hope Gurion's Fearless Product always has some good content. The Mind and the Product team, whether it be their blog posts or their podcasts, et cetera, has a lot of great stuff. Who else? Melissa Perry's, obviously she's got a great podcast with her products, Product Thinking Podcast. So there's a lot of stuff out there, but those are the ones that off the top of my head resonate really well.
- So now this is the hardball question to C. Todd. If you had to distil your philosophy on roadmapping down to one or two sentences, how would you describe it?
- I'm gonna puppet Janna Bastow a little bit. A roadmap is, I think I said this earlier, a roadmap is an artefact that describes your strategic intent. It is your plan, but it is not committed. So it will probably change, but at least as of the most recent version, it should be your plan for where you plan to go in the future, how you want to realise your vision and goals and mission. So that's how I would describe it in just a couple of sentences, hopefully that's good enough.
- Is there anything I should have asked you about roadmapping that I haven't asked?
- I think the thing that I, and we struggled with this with writing the book, is in terms of like thinking about how do we organise chapters. We were like, oh, step one, do this, step two, do this, well wait a minute, there are plenty of teams that like might be at step five but actually are gonna go back and do step one. And so I think part of the, a lot of people don't know where to start to like refine their product roadmap, they've had this feature-based roadmap the whole time and how do they switch, right? And so a lot of it is like, think about where your current state is right now, how well you are aligning to a more strategic level of roadmap, you know, have you decoupled your release plan and your roadmap? If not, maybe that's the first thing to do. But don't try to do everything all at once. Think about doing this one small change and seeing what the impact is, right? So experiment with your internal roadmap processes just like you experiment with your product. So many times, Bruce and I have done a bunch of workshops and we've seen people like super excited to go and like implement everything we taught them in the workshop the next day. I'm like, like, no, no, no, no, don't do that. You'll either hate your job, quit or get fired. Like that's not the point here. Pick one thing that you think can make a difference and do that, right? So it's like, hey, if you've got a roadmap and it's a whole bunch of features, start switching the features to like problems to solve or themes, right? Just do that. Then think about changing the timelines to timeframes later, right? Think about like just one little thing to do. And then once that's done and you see an impact, do another one. Right and that's sort of, that's the advice I would give to somebody on where do you start and how.
- Almost feels like you need a roadmap for your roadmap.
- Yes you do, you absolutely do. And I would say that I last, my last two jobs as VP of products absolutely were very critical for me to, and I actually wish I had clearly stated it at my last job saying, look, I need to give you the roadmap for us getting to a roadmap because I'm gonna make some changes. And here's what I'm going to think about doing first, second, third. I kind of wish I did that in hindsight. And with my new company, I'm actually in the process of putting that together. So yes.
- I mean I was think about roadmap for product management team and function and product teams, not just for the product itself. And so yeah, we may as well use the tools and techniques we use and work on ourselves and our artefacts. Great. C. Todd, it's been wonderful having you here today. I've loved this conversation. Lots to unpack from it and I'm sure our listeners are gonna lap it up and love it all. As always, to everyone out there, please do like, forward, share and subscribe. C. Todd, I just would like to give you an opportunity to pitch yourself, the business you work for.
- Sure. Yeah, I mean I love helping teams with roadmaps. I am not a consultant by trade, I am literally a practitioner so I have a product team. My product is called Appcues right now. It's a great little thing, if you make products, you might find that super cool. But if I can help your team, let me know but there are a lot of other consultants out there who could probably help you that have more bandwidth than I do. But you know, invite me to be a guest speaker. That's probably one of the coolest things and funnest things for me to do. Thanks so much Phil, for having me on. It's been a lot of fun. I love this topic clearly.
- It's been great having you and yeah, so we'll make sure there's links to some of those things down below so that people can find you, find those resources, get in touch. So just a reminder for everyone, if you are interested in being where C. Todd is and taking part in the conversation, do get in touch, info@talkingroadmaps.com. Find us at talkingroadmaps.com, the website, or on YouTube where you're probably watching this right now. C. Todd, thank you very much for your time today.
- Thank you Phil, it's been a pleasure.
