Are roadmaps ever useful? | Marty Cagan

In episode 26 of Talking Roadmaps, Phil Hornby interviews Marty Cagan from Silicon Valley Product Group (SVPG). They dive into the practicalities and misconceptions of product roadmaps, discussing their real purpose and value in product management. Marty shares his views on how roadmaps can be both beneficial and detrimental, depending on their implementation. He emphasizes the importance of outcome-focused roadmaps over feature-based ones and provides actionable advice on aligning roadmaps with product vision and strategy. Key takeaways include the significance of flexibility, stakeholder communication, and continuous learning in roadmap planning.

Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, advising and coaching, Marty Cagan served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, and eBay.

Marty began his career with a decade as a software developer at Hewlett-Packard Laboratories conducting research on software technology, and building several software products for other software developers.

After HP, Marty joined a then young Netscape Communications Corporation, where he had the opportunity to participate in the birth of the Internet industry. Marty worked directly for co-founder Marc Andreessen, where he was vice-president for Netscape’s platform and tools, and later e-commerce applications, and worked to help Internet start-ups and Fortune 500 companies alike to understand and utilize the newly emerging technology.

Marty was most recently senior vice-president of product and design for eBay, where he was responsible for defining products and services for the company’s global e-commerce trading site.

During his career, Marty has personally performed and managed most of the roles of a modern software product organization, including product management, software development, product marketing, user experience design, software testing, engineering management, and general management.

As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe.

He is also the author of the books INSPIRED: How to Create Products Customers Love and EMPOWERED: Ordinary People, Extraordinary Products.

Marty is a graduate of the University of California at Santa Cruz with B.A. degrees in Computer Science and Applied Economics (1981), and of the Stanford University Executive Institute (1994).

“Used properly roadmaps are a helpful tool, the problem is almost no-one uses them that way”

— Marty Cagan

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

In the next episode we are getting back to a practitioner and talking to Jonathan Gowins, Director of Product Management at Openly. So watch out for Episode 27!

• Transcript

  - Welcome everyone to Talking Roadmaps. We're really pleased today to be joined by Marty Cagan. I'm sure he doesn't need to introduce himself, but Marty, maybe you could just give people a little introduction.

  - Well, sure. Well, the name again is Marty Cagan and I've been doing product for a very long time. I've started as a engineer for 10 years and then I moved into product and engineering and product leadership roles. And after working at some big internet companies, I decided to start Silicon Valley product group with a few friends and we just advise and sometimes invest in mostly startups, but growth stage companies too. And we try to spread the practises of the best product companies to everybody who's interested.

  - Having just sat in on inspired and empowered in the last two weeks and been part of your coach, the coaching session earlier in the year, it's a real pleasure to have you here. Please do like, subscribe, hit that bell icon follower us, maybe share that sort of thing. Let's start out with, in your view, what's the roadmap supposed to be for? What's it there for? What's its kind of raison d'etre?

  - Well, it's not a small topic as you know. I mean, you have a whole podcast about it. It's not a small topic and you know, I'm definitely on the record for pointing out many of the flaws. And consequences of roadmaps, but a lot of people don't really, you know, it's easy to just sort of pigeonhole that as anti road map or pro roadmap. But the thing is, it's more nuanced than that like product. The truth is, when used properly roadmaps are a helpful tool. The problem is almost nobody uses them that way. That's the real problem. So if people really wanna understand how to get good product work done, they do have to be willing, I think, to dig deeper. And one of the challenges with roadmaps is that they are so intertwined with the whole distinction between feature teams and product teams. If it wasn't for that, it would be a lot smoother issue, but it's not. In feature teams, which unfortunately, I mean, feature teams and roadmaps kind of go hand in hand. Feature teams are driven by roadmaps, literally driven by roadmaps. And I should say right up front there are multiple kinds of roadmaps. If I was in charge of the world, the one kind that is, I think a good kind of roadmap called an outcome-based roadmap would be the common kind of roadmap. But the truth is it's incredibly rare. It's incredibly rare. People talk about it, very few do it. I don't never seen any formal studies, but easily in my experience, 95% of roadmaps are not outcome-based roadmaps. They're output roadmaps. And the reason they're basically the tool that enables feature teams. What does that mean? It means the stakeholders get together and they prioritise the features and the projects they want. They put them on this document called a roadmap, and that is the instructions, the requests that are handed to the feature teams. And then those teams, their job is to knock them out as fast as they can. They design, they code, they test, they deploy as fast as they can. So, do you really blame the roadmap for that? Well, the roadmap is just the vehicle, right? It's just the vehicle that's being used to communicate these wishes from the stakeholders to the feature teams that need to build them. How do you blame the document for that? The issue is much bigger than that. And it comes more about like, is that how you really wanna work or in a product team, you're not given these features and projects to build, you're given problems to solve. And that's why I said, you know, in the rare case where you find an outcome-based roadmap, we love that because those are problems to solve. So the thing is, if we need to decide sort of right up front, are we gonna talk about feature team companies or are we gonna talk about product team companies? If we're gonna talk about feature team companies, we can talk about how you can tweak this to try to do a little better. You're still gonna be a pretty weak organisation and if that's what you wanna talk about, we can, but the reason roadmaps are not a primary topic in great product companies is 'cause they're not used that way. They're used as a communication vehicle once we've actually figured out the solutions that we need to build. So it's a completely different scenario. In other words, the use of roadmaps in a strong product company is so fundamentally different than the use of roadmaps in most companies. And again, it's not because of roadmap, it's because of feature teams or product teams. So that's why this is such a messy topic and we'd have to look deeper into, well why do those companies use the roadmaps? They're using them for different purposes.

  - It's interesting that reflection that you had there, because I don't think I've ever been given a roadmap by a leader. Maybe I've been lucky. Maybe I've been lucky. I've always been asked for my roadmap.

  - What's really going on is there are a set of capabilities that those stakeholders need and they're asking the product team, when will you deliver them? And that's the roadmap. So it's not necessarily, although in some companies they do have this negotiation first and then the stakeholders provide the roadmap. But most of the time the product team has to give them the roadmap. So we can talk about why so that makes more sense, right? The stakeholders in a feature team organisation, what they want is they want some predictability. They wanna be able to plan, right? Is this crazy? It's not crazy. They're their ideas. Well, we need these things because we have dependencies, we have partners, we have commitments. We need to know, we need to tell the sales organisation, they need to tell customers. So that's what they're using it for. So it's not that common that the stakeholders will say, "You have until August 1st to deliver this feature." They'll say, "We need this feature, you tell us when we can deliver that." And then there's this negotiation back and forth. But, is that really on any different? Not really. The real issue is when you come up with those dates, do you even know what you're talking about? Do you even know when you'll be able to deliver that? If you just judge it by the accuracy on dates of typical roadmaps, the answer is obviously no. You don't know what you're talking about. If you judge it by the ability for those things to actually deliver on the value, no, you don't know what you're talking about. So that's why feature teams kind of live in this frustrating world where stakeholders blame the teams and the teams blame the stakeholders. It's this natural consequence of this way of working. We're forced to make these commitments and promises all when we don't really even know what we're talking about. And typically the team doesn't even think it's the right solution.

  - I can't argue with that. You've talked about there are some scenarios where there are good uses of it and there also some scenarios where it's a symptom of a feature team. What's the difference there in terms of the relationship of a roadmap? Two things like vision, strategy, objectives, how do they kind of interrelate?

  - Well this is a frustrating thing for me, but in most featured teams organisations, they talk occasionally you'll hear people talk about vision and strategy. They don't have vision and strategy most of them because if that's how you're working where you've got all these different feature teams set up to support the different parts of the business, the real strategy is just support the business. That's not a strategy, right? That's not a vision either. I mean that's why people get all these silly definitions of product vision. They think each product team is gonna do their own vision, which of course misses the whole point. So most of the things we talk about great product leaders do in strong product companies, that's not even relevant in a feature team organisation. There's very rarely a true product vision. There's almost never a true product strategy. They don't do team objectives because they're doing feature-based roadmaps instead. So that whole discussion about what strong product leaders do at strong product companies, it's on a different playing field. We have a different set of things we're worried about. This has always been a real frustration for me is that across the industry we use the same terms like product teams and roadmaps and, but they're not the same. They're very, very different in a feature team context, it's very different than a product team context. Which by the way is very different than a delivery team context, which is even worse. But that's now we're talking pure IT people that yeah, a totally different scenario.

  - Yeah, I remember the other day there was an example, I think it was Stripe that was given as a strong product company that does use roadmaps. I'm assuming there's some sort of link up to those objective strategy.

  - Like I said, almost everybody uses roadmaps. I use roadmap that, but the difference is this, when do you do that roadmap? Do you do it before you know what you're really talking about or do you do it after you know what you're talking about? So in a good product company, they have goals, right? They have like, we need to solve these problems. When the team has done enough to understand what we really need to do. And I don't mean just somebody guessing, I mean doing some product discovery, some prototyping, some customer to really figure out, number one, do we really know how to solve this problem? Number two, do we know we can solve this problem? Like with the team, the time, the technology. Number three, will the customer actually buy this solution or want to use this solution? And also will the customer be able to use this solution? And will this solution work for our business? Once we know that putting it on a roadmap is very helpful because we have to communicate to our customers, to our other product teams, to our executives what we're doing and when. So this is why, and I've said that a million times to companies, but I always try to say it after in a feature team company, they lead with roadmap. That's like the start of everything. In a good product company, the roadmap is the communication tool once you actually know what you need to do. And that's why I say in feature team companies, roadmaps are usually the biggest single source of waste. It's because these promises are made before we know what we're promising. And so we are locking ourselves into delivering capabilities when many very often those capabilities are not gonna solve the problem. Even if we could deliver them on time. So that's the issue is not that you're doing roadmaps, it's when and how you're doing roadmaps.

  - So what about the idea of roadmapping your discovery efforts? 'Cause it's come up for a few times in other discussions.

  - The real issue with that word roadmap has a lot of baggage with it. And so anytime you call a document roadmap people, and I know I've tried for years to put all the disclaimers and caveats and says, these are not promises. These are, you can do all that all you want, it doesn't work. And the reason it doesn't work is because the rest of the company needs actual promises. That's what they want. They wanna know when things are gonna happen. So to do that, as you know, you don't need to do that with discovery. With discovery we've got the input to discovery is, what are the problems to solve? The output from discovery can be that roadmap. I mean what it really is is backlog items to work. But it's easy to do a roadmap with high confidence after that. And then what's really a shame is it doesn't even, it's not that hard to do that, it doesn't take long to do that, but it does take a very different dynamic in the company and that's the dynamic between a feature team and a product team. So when your stakeholders think their job is to say what capabilities they need and your job is to build them, that's a very different dynamic than when the stakeholders say, well, working with product teams, we're figuring out what the most important things for the real customers are and then we're gonna work together to make sure that solution also works for the business. That's the big change, not roadmap. Roadmap is easy compared to that.

  - Okay, so essentially if I almost summarise that back, you're saying roadmap's not in discovery, but could be an output that feeds into the delivery.

  - You're sharing what your deliverables are gonna be and when they're gonna come. That's a very useful thing in a product company is, I mean I've never met anybody who didn't think that was important.

  - I think you've kind of already half said it, but just kind of be clear then in that discovery work, if not a roadmap, what are we using there?

  - Well, there's different systems. What I've been advocating for years and what a lot of companies use is that's what OKRs are for. That's literally what OKRs are for. You're given the problem to solve. You're given the goal to reach, the business outcome. And once we figured out a solution, then we'd say, Hey, we're shipping that new capability here. One way to think about, because the term roadmap has so destroyed trust in so many companies because, you know, rightfully the company doesn't believe the product managers, the product team's roadmaps. Why should they? They're wrong most of the time, why? So that's why they don't believe it and I'm not blaming that on the product teams. I'm sort of blaming it on that whole feature team model about when you make these promises. However, if the team has done product discovery, we call them high integrity commitments and the key word there is high integrity, right? It means that you actually know what you're talking about when you make a promise.

  - So why do you think roadmaps are so popular in product?

  - Because they're necessary. You need some way to plan in most companies, right? Certainly when you're a really, really small startup, it honestly, so many things are easier. But as you get a little bigger, think about it, we have platform teams that need to provide services to experience teams. We have services we're building in those experience teams that our customers are counting on. They can't actually deploy until things come. We've got partners that are actually working on their side of equation and we're working on our side. How can you just tell them, oh we'll just give you a call when we're finally ready. You can't do that. They're trying to run their business, you're trying to run your business. We need to be able to plan. The difference is we don't wanna just pull numbers out of our we wanna be credible. We wanna be trustworthy. We also wanna be honest. We don't wanna set people's expectations if we're not gonna deliver them. So that's where you need to have a communication vehicle, but one that's trustworthy. I mean you could call it, and I have heard people say this, a high integrity roadmap. But the point is, in a good roadmap you have high integrity commitments. But if you have this high integrity roadmap, it is fine. You know, this is a very similar discussion 'cause a lot of teams get the same thing comes up instead of on roadmaps, push it down a level. Let's say you have a bunch of engineers that are all working remotely all around the world. Doesn't the product team, the product manager have to communicate to those engineers what really needs to be built? I mean, of course.

  - And there's the PRD coming back, right?

  - That's right. I mean it's never left. But the issue is whether it's stories or PRDs doesn't matter. The issue is when the product manager writes that up, are they just making this up like they do with roadmaps or are they credible? Have they actually discovered the right product? Product design and engineering and now they're just communicating it. As long as they've actually done their work to make sure that what those engineers build will not be a colossal waste of time. Then the document, the PRD, the stories is useful. It's more than useful. It's pretty much essential. Now, you know, the truth is we can use prototypes for a lot of this too as a form of specification. But no matter what you need to the time to detail these, you know, document these details. And so that's a case where that documentation is absolutely essential. On the other hand, if you write that documentation instead of figuring out the product you need because some product manager believes they're like Steve Jobs or something and they can just dictate this perfect solution, then you're probably causing real problems and wasting real engineering time.

  - Yeah, funnily enough, I have my own version of the five dysfunctions of teams, but it's the five dysfunctions of remote teams and one of them is another reliance on artefacts. Whereas historically we used to work collaboratively and then write it down and it was kind of a memorialization of what we'd agreed. As we've shifted to remotes, I saw a resurgence of, well I write it down and throw it over the fence and then I think I'm done. But actually I still need the conversations.

  - We had already seen this behaviour before the pandemic with remote teams. And so as soon as the pandemic started, this was something I was seeing more of immediately and I tried to warn people about this because that's exactly what happens. You just revert to artefacts instead. Anyway, that's really not all that different. It's the same real problem as the roadmap problem. It's just the roadmap is at this level of granularity. In other words, what are the features we need? And PRD is at this level, how do you build that actual feature?

  - Going back to your comment about the roadmap being such a loaded term, with my cohost yesterday we sat there we were debating do we need to invent a new phrase? And it's like, no, no, no, we're not gonna do that. We're not gonna do the MVP thing again. It's like where it took on a life of its own 'cause sales decided it's the smallest thing to sell, then someone creates the rats. I much prefer your simpler language of they're all prototypes, it's feasibility, it's viability, it's value, it's usability. What are we testing? That cause that sort of prototypes for.

  - Because I understand the desire for a new phrase, like 'cause the term roadmap is so loaded in the whole industry today. How useful is it anymore, just like the term product manager. Look at the job description of a product manager for a feature team versus a product team. And it's like, why in the world do they share the same name? It makes no sense really to share the same name, but they have forever shared the same name. So I mean, when I say, you know, for 40 years they have shared the same names. So it's not like it is true that in the true IT world, they used to call 'em business analysts, but you know, when the world sort of wanted to become more like the Googles of the world, they adopted the same terms. So it's a problem. These these are hard things to fix.

  - I even heard suggestions of calling us problem managers. It's like that just sounds like a working support in IT. It's just there's no easy solution.

  - No, I've never heard of that one, but I have heard of plenty other things. Yeah, it's tricky.

  - No, I guess I'm gonna pull you into a pragmatic perspective here and knowing that feature teams are probably where we're gonna be talking around a bit more. When is a roadmap really useful and how is it useful? You know, what can we really get out of it if we use one?

  - Well, again, the context that I'm interested in is good product company, not feature teams. And we all know how they're used in feature teams for better or worse, but for product teams, they are very useful as a communication tool, especially the larger the company, the more important it is to communicate. Again, there are other ways to communicate these things if you want, but the normal way is you put it on a document called a roadmap. And these are your high integrity commitments. These are when you're gonna deliver the important things. Obviously, even in feature teams, they rarely put things like bug fixes on roadmaps. You don't need the little tiny things. But in the big things you could say, yes, we figured that out. It's coming out the end of the month, end of the quarter, whenever. As long as you have evidence that you will be telling the truth, that you're telling the truth in that it really will come out then. And with reasonable confidence it will come out then and it will solve the problem and needs to then that's what the rest of the company is depending on you for. So that's all, it's just a way to communicate important dates and deliverables for planning and predictability purposes.

  - So, okay, when we think about roadmaps, what do you consider to be best practise on a roadmap?

  - The main thing on best practise in a roadmap is make sure that any deliverable, in other words, output and any date has integrity behind it. And that nobody has a hundred percent confidence on anything in software especially, and it's true with devices as well. We don't ever have a hundred percent confidence, but we do need to have real evidence, we have to be able to be credible and depending on the risk, the more credible we need to be. So if we're doing a very big thing for a partnership, let's say that's got a lot of money involved, we've gotta make sure that we uphold our side of the bargain, our side of the deal. And so proportionate to the risk, we have to make sure we have evidence that we are going to be able to deliver a solution that works for the customer, for the users, for our business as long as we can we need to communicate that and that's what goes on a good roadmap.

  - Look here, so we've talked about best practise, what about the biggest mistakes or biggest anti-patterns you see on a roadmap?

  - You can see we're saying the same things 80 different ways because roadmaps really are not a complicated thing and the problems with them are pretty well known. So the most common anti-pattern is putting a promise on there when you don't actually have evidence it's gonna work. And it might be because some executives thinks it's the right thing to do. It might be because a competitor does something, it might be because they think they're got the great idea and the ideas 90% of the work, but it's not, you know, it could be all those things, but fundamentally they end up putting something on there that where they really don't know what they're talking about. That's the primary anti-pattern right there, primary issue. So we say the most important thing in product discovery is to know what you can't know. And if you know what you can't know, then you say, all right, well there we really can't know this. Very often the person who's blamed, it's not actually the product manager, it's the engineers are blamed for our terrible roadmaps and is this really not fair? What's really going on is nobody's figured out what the product needs to be. And so the engineers, somebody comes to the engineers, it might be a programme manager, it might be the product manager, but somebody comes to the engineers and just says, we need a date, give us a date. And most of the time the engineers say, date for what dude? All you're saying is you want another payment option or you're want whatever, but show me exactly what you need. And they're like, well we don't have that. We're just in the roadmap stage, so we need to know, when you're gonna deliver this. And they're usually say, well that's nonsense, but what happens in too many companies is the engineers are not allowed to just say it's nonsense. So that's where t-shirt sizing came from. Where there was the programme manager would go to the engineer and just say, all right, all right, just tell me is this small, medium large or extra large? And then we'll take it from there. And of course this is all ridiculous, but that's what they're doing. Much better and in fact, I tell engineers never ever, ever give a date for a roadmap unless, and until you have done a feasibility prototype because you're putting your reputation on the line and you're actually putting the business at risk because they're gonna believe you and that's dangerous if you are making this up. You need to be able to, at least if they've done a feasibility prototype, they kind of have identified those things that they can't know or don't know and will need to figure out. So they have a much better informed sense. Virtually, every single time you see the situation where, the engineers think something's gonna take one or two sprints and three, four, five sprints later, it's still not done. The answer's really simple, it's because they didn't do a feasibility prototype. I pretty much guarantee you that's what happened. They didn't do that and they made a very wishful guess and it's not their fault, it's really the fault of who is pressuring for them for this. But my advice to engineers is never give a date unless you've done a feasibility prototype. And what's really ironic is most feasibility prototypes can be done so quickly they are so valuable to do. And I was taught never to give a date without that. But I was told that because I had to be credible.

  - Marty, I know you've published a post about a pledge to customers from product teams, so maybe you could put that into the context of roadmapping as well.

  - In general, what I wanted to do was, when empowered product teams interact with customers, it's a very intense relationship. And I wanted, a lot of times I'm asked by the sales leaders, by the CEO, by customers themselves, how is this different? And it really relates directly to our conversation so far. In feature team organisations, first of all, there's very little direct interaction between customers and the feature teams. And that's because the stakeholders are really the ones in between. And those could be salespeople, it could literally be prospective customers or customers saying they want certain features, they go to their salesperson, the salesperson passes us on to the feature teams and says, I need a date so that I can promise this to the customers. And they expect to see it on a roadmap. And then of course what happens? It's late, long time late or it actually comes eventually and it's not at all what the customer was thinking about. So there's a lot of broken promises out there and what I was explaining in this article was an empowered product team promises we don't do that, we don't do that. Instead we never accept proxies. In other words, you can't be the salesperson, it can't be the stakeholder. The product team has to get going, sit down with those customers and understand what they really need in order to succeed. And what that promise says essentially is, we'll only give you a date once we really understand what you need and once we really know what we have to do to deliver it. And it explained the concept of a high integrity commitment that we were talking about before, said, we're gonna make sure this works for our customer before we promise. Because when we make a promise, we want them to be able to count on it. And so it's a pledge about integrity, it's a pledge about trust. And so what it talked about is what's necessary in order to do that. And this is all framed around 'cause a very big problem in our industry is roadmaps in sales-driven organisations. And this is speaking directly to that.

  - If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - I would say as long as you put real effort into making sure you know what you're promising on that roadmap where you have real evidence, evidence that you know what's required to build it and you know the customer will be satisfied with what you deliver, then that roadmap is gonna be something that is helpful to you and to your customers and to your executive team. If you haven't done that, you're not doing anybody any favours.

  - So true and now what's the thing that I should have asked you about roadmapping that I haven't?

  - Maybe one thing that is important that's really goes beyond roadmaps, but a lot of the purpose of these roadmap items is not even for customers, it's for all the dependencies in a large organisation. And so there's another role that we haven't really talked about. What I talked about is making sure you know what you're talking about when you make a promise, whether that's internal or external. But in a big organisation there are a lot of these promises and the people that track the progress and the impediments to those promises are called delivery managers. And delivery managers are a form of project management of course, but we call them delivery managers when it's an empowered product team versus a project or programme manager for a feature team. But it's project management. But they are very helpful people because they are looking across the organisation at all of these commitments and dates and tracking. And so if something happens, it might have ripple effects. And so it's probably useful to keep in mind that in a bigger organisation, when you have a lot of these dependencies and a lot of these commitments that you often need people to keep an eye on them holistically and that's a delivery manager.

  - Marty, it's been absolutely wonderful talking today. Just a few seconds, do you wanna tell people about SVG? How they can get in touch? How you guys could help?

  - Well we have a website svpg.com and we publish articles. All the content there is for free and Google search is pretty good about finding it. So any of these topics I've talked about, if you wanna learn more, feel free to go there. We also do a newsletter to push that content out to people that want it. And I'm reluctantly on Twitter and LinkedIn when I need to be. So you can also see when I publish there if you like.

  - And I guess I'll also emphasise, don't forget the books, "Loved," "Inspired" and "Empowered," which I can just see behind you on the shelf there as well. We might put some Amazon links below. So Marty been an absolute pleasure today. Just to everyone out there, just a reminder, please do like, subscribe, hit that bell icon, follow us, share it with some of your friends so that they can hear what's going on. All about road mapping. Marty, it's been a pleasure today. Thanks for your time.

  - Thanks for inviting me.