Can a roadmap look like a gantt chart? | Saeed Khan

In episode 25 of Talking Roadmaps, Justin Woods interviews Saeed Khan, a seasoned product management expert. Saeed delves into how roadmaps can resemble Gantt charts, sharing insights on strategic planning and execution. He discusses his extensive experience in technology and product management, highlighting practical tips for creating effective roadmaps and high-performing teams. Saeed also explores common pitfalls and best practices in product strategy, making this episode a valuable resource for product leaders.

Saeed has worked in Product Management for over 26 years in both Canada and the US, in startups and public companies. He was a co-founder of ProductCamp Toronto and also founded the Product Leaders Meetup, which is a meetup of senior product directors/VPs.

Currently, he runs Transformation Labs, which is a consulting and advisory firm that helps companies in areas of strategy, roadmapping, launch and discovery. Saeed provides consulting, mentoring and workshops to help companies create winning products and high-performing product teams.

There is also a blog post be Saeed on the same subject here.

“If it looks like a gantt chart it’s probably not a roadmap”

— Saeed Khan

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

The next one is a BIG one, Marty Cagan from SVPG shares his thoughts on roadmapping in our 1 year anniversary episode. So watch out for Episode 26!

• Transcript

  - Hi, and welcome to the Talking Roadmaps Channel. I'm one of the co-hosts, Justin Woods, and I'm here to present all things roadmapping to you. Talking Roadmaps is the channel dedicated to the craft of roadmapping, the art and the science of it. Without further ado, I wanted to introduce you all to Saeed Khan. Saeed is a product consultant, a coach, a speaker, and a founder of his own product management company as well. Saeed, welcome. Tell us a little bit about yourself.

  - Thanks. Thanks very much, Justin. Yeah, so I think you described me fairly well at a high level. I've worked in technology my whole career. I've worked in product management for 25 years, actually. Started in 1997. Worked in Canada and the US, and yeah, for the last five years, I've been working as a consultant, helping technology companies and IT organisations execute better on product. The way I like to describe it is I help them make better products and better product organisations.

  - That's a great way of putting it. And what a wealth of experience as well that you can bring to those companies, which is great, and it's something that you deeply enjoy.

  - I do, actually. That's a really good point. I really enjoy the work.

  - Awesome. It came across from our discussion earlier. If you like today's show, it'd be great if you shared this out with your friends. Maybe give us a like. Also, if you'd like to take part, then please, again, drop us a comment down below or reach out on the website. We'd love to have expert practitioners thought leaders on the show. Why don't we jump in a little bit and talk about kind of some of the core concepts of a roadmap. So you've obviously come at a roadmap from different areas, from a product management area and a leadership. In your perspective, Saeed, what is the purpose of a roadmap?

  - A roadmap is a component of planning and execution. And it has multiple purposes, includes communication, right? So when we present the roadmap, we've done a lot of work and we communicate outwards. But I think the biggest benefit and purpose of a roadmap is to really clearly identify priorities and direction. So where you're going and sort of what's most important. And the basis of that comes from strategy and objectives and other things, but really, priority and direction are the real big benefits of it. And clearly thinking that through and then clearly articulating into others.

  - Massively important. I love that. The priority and the direction is kind of this the overall trajectory of where we're going, and then also the priority of those items. So which are we gonna tackle first? Which of them may be a bit further out? Yeah, it's a great response.

  - Yeah, and just generally, what are the most important things? Like a roadmap won't contain everything that you plan to do. That's not its purpose, but if you do your homework and you think about where you wanna get to, your vision, et cetera, your roadmap will show those things that really help you move in that direction and that are things you shouldn't let slide, right? Like there's lots of things that can distract, but these are things that we really have to focus on.

  - Yeah, that's a good point, the current focus. I love that. And so who is the audience of a roadmap?

  - So I think there's, first of all, there's different types of roadmaps and they serve different purposes. And I won't go into sort of all of that, but in the most general sense, it's anyone who needs to understand the strategic direction of your product. Let's talk about a product roadmap specifically. So internally, obviously, it's product teams, it's executives, it could be other people that come to the other departments, whoever you wanna communicate that to. And then externally, again, people who need to understand that. So I worked a lot in B2B product, and so strategic customers and partners and people who we were collaborating with. So we would share roadmaps with each other, and then trying to align what we're trying to do together, et cetera. So, but roughly speaking, anyone who needs to understand the strategic direction. So again, direction and priority, what's important and where are you headed?

  - I like that kind of casual statement, which is anyone that needs to understand. So anybody that needs to be involved. And that could be down even into legal teams, finance teams, and so on and so forth. But it doesn't have to be everybody, it's just the teams that actually need, maybe have some skin in the game or they need to be involved to deliver the overall trajectory.

  - Own is such a loaded word. Generally speaking, product management is responsible for the definition of the roadmap. You know, if you think about like accountability, absolutely, product management is accountable for that, but it's not a sole ownership in the sense of product management goes away and defines it and then tells everybody. It's obviously a collaborative effort. And again, this is one of those reasons why when I talk about roadmap, I always talk about strategy, I talk about objectives, I talk about vision, et cetera, because it's really a component of your business planning and how you expect to achieve your goals. And so if you think of those four words together, vision, objectives, strategy, and roadmap, there's a lot of people who are stakeholders or who have some aspect of responsibility over those things. And so all of those people on some level will be part of the roadmap and process.

  - Yeah, that's a great response actually. It's the people that are responsible for kind of updating it, if you will, or maintaining it, and then the ownership of the roadmap could actually be much more widespread. It's all of those different artefacts that have different ownerships within the company feeding into that roadmap.

  - Yeah, and like in a nutshell, like product management is responsible, accountable, whatever you wanna use for defining it, but not solely, right? That's the thing. So you have to work with others, like as a product manager, as a sort of individual contributor product manager, I worked on many roadmaps, and I'll admit, quite honestly, some were not really great roadmaps, but the sort of context was always the same. Like we were given objectives from our management team. You know, there's a revenue target. Usually it was revenue, but sometimes for early stage projects, it was customer acquisition or something like that. It could be retention, it could be whatever. You know, you're given something from above and then you're really trying to frame a lot of other contextual items to do something that addresses those things. So yes, we're gonna focus on X, Y, Zed to meet these goals or objectives, but we also have these other constraints and we have these other areas we have to focus on. So it's a blend of all of that. And then it's very political too because you can't please everybody. And so you have to sort of really be great at prioritising, and then weaving a good story around why you made certain decisions, right? But that's where the collaborative nature of doing it comes in. You don't just go away, do it, and then come back and explain everything.

  - You mentioned there about storytelling. And I think that's such an important and possibly a lost art of the roadmap as well, which is to, as a compelling document to bring people along with you, you need to infuse them and invigorate them with that story. And often the storytelling aspect gets lost and it's just a slide or it's just a diagram.

  - Yeah, and again, the story has to have context, right? So it can't just be, "Hey, we got a bunch of customer requests and that's why we're doing all these things," right? That makes no sense. Yet, unfortunately, there's a lot of feature roadmaps that really are just that. But if you have a clear vision of where you need to get to and you have these objectives and you understand the market and you define really good strategies to address challenges, et cetera, there's a story right there, right? That whole context is the story that you can use to then say, "Okay, and because of all of that, here's how we're going to prioritise." This is why we're going in this direction, this is why these are things that are important to us. And if people buy into that context, and hopefully you've describe the vision and all these other things so it's not new to them, then it becomes so much easier, right? Because people aren't questioning every decision like, "Oh, what's that thing two years out? Why did you put that there?" How come something is in column B and not column A? Et cetera.

  - They've got the context of why it's important and this is the next statement.

  - Absolutely. And context, I mean, I say this all the time, but common context is literally one of the most valuable things. Like you can be sitting across a table from someone and if you don't have common context on something, you will talk past each other and you won't even realise it until it's way too late. And all of a sudden, you're just like, "Wait a minute, we've been talking about two different things for the last half hour or whatever because one person assumed one thing, another person assumed another." And so this idea of common context in, and I think to get away from roadmapping specifically, but I think in almost all the work we do in product management, common context is probably one of the best things you can strive for, right? When you're doing discovery work, right? You want common context with the team. When you're doing prioritisation, you want common context with the team, right? You wanna have that common context throughout all the work you do and roadmapping is no exception.

  - And I love that you talked about kind of the relationship of the roadmap to things like the vision, the strategy, the objectives, something that I know we're both passionate about as well is the concept of a product roadmap, and then a business roadmap. I was wondering if you could kind of talk a little bit about that.

  - Yeah. So this is interesting. So when people say the word roadmap, sort of the implication is a product roadmap, but one of the things that you really have to remember is the product is there to serve the business, so to speak, right? Like you can't have business success without product success, but the product lives in a context of the business. You can't just do anything in the product. Like we're not just saying, "Hey, let's go off and build X, Y, and Zed because we can." We're doing it because the business is focused on something, there's a business vision, right? So we talk about product vision a lot, but there should be a business vision. And the product vision supports that business vision, right? I worked at Informatica for many years and we were data integration, data management company. And all of our products, master data management, data quality, data integration, our cloud products, et cetera, all fell under that umbrella, right? We could have done other things 'cause there were lots of cool things to do, but we didn't go off and do like storage or something like that. And so there's a business vision, there's a product vision, right? There's business objectives, there's product objectives. There's business strategy, there's product strategy. There's product roadmap, but people don't talk about business roadmap. And it's kind of interesting that this idea of a business roadmap is not really talked about much and it's not really understood because it, from my view, the business roadmap, right? The business strategies, right? The direction and priority that the business needs to take is going to feed into what you do in your product, right? So this business roadmap is there and the product roadmap supports it. So as an example, if you have a product and you're a growing company and then you want to expand internationally to grow revenue and extend reach and whatever, right? That's a business strategy. It's very clearly how the business expects to grow. As a product, you're going to have to support that, right? And it could mean localization, it could mean understanding the local context, where the company's going to operate, and then maybe there's some regulatory issues that you need to understand. Or maybe there's, you think of an HR application, right? Like, boy, if there's an application that has to understand local context, it's HR, right? And so the focus really is that this business roadmap, right? That'll have go-to-market, it'll have strategy, it'll have operational, organisational things, there'll be lots of stuff in there, is a key feeder into what you're gonna do in your product. And those two things have to be aligned. And I think this is another important point, which is that a lot of times, when people talk about the product roadmap, it's isolated from the business, right? And this is one of the reasons why there's often a lot of questions and pushback on a product roadmap. It's like, where did those decisions come from? Why are those the priorities that you've put on the roadmap? Because those priorities don't align with the business, right? Or how are those priorities supporting what the business needs to achieve? And so if you come at it from the business side first and you say, "Okay, as a business, our goal is to grow this much and we have to make these organisational changes, and then there's these other issues." And there's aspects that we'll filter down and some of those will be product related. And then those feed into your product roadmap. And then there's other things that are gonna go in there from your own product strategies as well. But now, that connection between the business and what it's trying to achieve and the product and how it's gonna support it are clearly aligned, right? There's not a question of where did that come from? Where did that come? All of a sudden it's like, "Oh yeah." You know, the question might be, "Oh, maybe the timing is not right or something," but you're not gonna just have questions about random things that are on the roadmap. And I think this idea of bringing this alignment and using the roadmap, the product roadmap as a communication tool to support the business becomes really valuable. And then people from sales or people from marketing or people from other orgs aren't looking at you as, "Oh, what are they doing now?" It's more about how are we working together because those business goals are gonna be communicated to the sales team, to the marketing team, to services, et cetera. And so now you can get a sense of alignment across the teams as opposed to misalignment or whatever the right word is.

  - One thing that I think dovetails into that, of course, is some of the goals and initiatives that might come down from the company level that don't hit, just hit product and they come to other areas. So like you said, customer success, maybe we're gonna have to expand our customer success or organisation in another company. Maybe we're gonna have to look at architecturally scaling the product. So we're gonna need much more infrastructure. Those are things, those are business, true business objectives that might not just touch product, they touch our other areas. But it's so important to have that alignment.

  - That's a great point actually. And I think this lack of alignment is another huge problem you see in companies and people try and address it through meetings and things like that, but in essence, what they're doing is putting a bandaid on the problem. They're not really solving the problem. And this idea of having real alignment really means we're working towards the same objectives, we're headed in the same direction, we have the same priorities, and we're moving together forward with common context. So you notice I'm repeating certain terms intentionally because that's where the value of a roadmap comes from, or roadmaps, right? Depending on how you're thinking about them. And it, what I found is that when, product management, first of all, I always try and repeat this. Product management itself is cross-functional by nature, right? It's cross-functional management driving product success. That's the way I think about product management. It's not about stuff you build. Yes, that's part of the job, but that's not the focus. You know, I ask this question sometimes. You know, people talk about product management. And when they say product management, it's like product management, right? What's the management in product management? Because management is the word, right? It's management of product, right? Product is the modifier, right? The main word is management, but what's the management that you're doing? And so this idea of managing products, it's not about building products, right? It's about managing them to drive success. And that's cross-functional by nature. It doesn't, it can't be done in a silo.

  - I'm a massive advocate of that coming from a, as a former BA, business analyst as well. You know, sometimes we don't have to build stuff. Sometimes the answer is to take features away. Sometimes the answer is to change a process or make it into a different channel or multi-channel. You know, there's so many different ways to do it. And you are right. Sometimes the emphasis can be so much on the product, and actually it's not the answer. So product management and these roadmaps is looking at it holistically across all of those different areas. Yeah, that really resonates with me.

  - When I think of business roadmaps, the way I approach it, I usually look in and say, look, there's four main areas when you think about a business roadmap, right? So there's, what's tied to the business itself. So there's strategy and things like that from a business perspective. There's go-to-market, right? You can't have any kind of business success without some clear go-to-market. There's organisational readiness or organisational capabilities, right? Can we actually do this and what do we need to do in order to do this? And then there's product and I put product last, not because it's the least important, but because products is one people always think about first. And it's really important not to just downgrade the other three. But if you think about them, right? So again, business organisation, go-to-market, and product, if you take any one of them away, could you be successful, right? If you didn't focus on go-to-market, obviously not. If you didn't focus on the organisation, obviously not. We wanna expand internationally, but we're not gonna think about the organisational impact. And in that sense, like if you don't think about all those things, you're not gonna be successful. And then yes, product, obviously, you have to think about, and then that has its own level of detail.

  - I love that, Saeed. That's some really great thoughts there. I wanna talk a little bit around, kind of from your experience, the designs of roadmaps. So what do you believe are some of the key elements or content on a roadmap? What do you like to see?

  - So it depends on the kind of roadmap you're talking about, but I think what you don't wanna see on a roadmap are dates, like specific dates. If you roadmap visually when you represent it, if your roadmap looks like a Gantt chart, it's probably not a roadmap, you know? But I think the idea, again, getting back to direction, priority, et cetera, you can't be specific on dates when you're talking about direction and priority. What you can be specific about is timeframes, right? So no, the common now, next, later kind of model that people talk about, I think that has value, but the question I always ask is when I see someone who has strictly now, next, later as column headings is, okay, that's great. So now I understand priority and direction, but when does now end and when does later start? But like the problem is that, I think just strictly saying now, next, later is the sort of an overreaction to a Gantt chart type approach. And the reason I say that is because dates are important in business, right? We do things in certain timeframes, right? But there's a difference between having dates like X will be delivered on this date or even we're gonna deliver it in October or January or February and saying there's a timeframe like Q4 or first half of next year or something like that, right? And when you think about it, if you derive your roadmap and it has objectives, objectives have timeframes, right? Like our revenue for this year, right? Like we've got, it's not just some revenue number, it's revenue in a certain amount of time. You have strategies, right? Strategies have timeframes associated with them, right? It's not just a never-ending strategy, but we need to accomplish X or this strategy has to be something in the first half of the year, we're gonna do whatever. So there is a time element to it, and you have to acknowledge that. And I think the challenge is not to get too specific where you're making promises that aren't real. But what I often look at it from a time perspective is that, look, we are more confident about things that are closer to us than further away, right? So this quarter, next quarter we have higher confidence. So you could put, and if you're gonna deliver things this quarter, right? Like they're already underway. Like you've staffed them, you've planned them, you've analysed them. So you should have high confidence. So there's nothing wrong with putting some dates in the now. Like now is the next three to four months let's just say for sake of discussion. And in fact, we're gonna deliver something. Right now, let's say right now, literally right now it's late August, we're gonna deliver something around September 15th. Okay, great. Like high confidence, but let's say that goes to end of the year. So after January, like we're not sure, but certainly in Q1, this is what our priorities are. And then Q2, this is what our priorities are. And then second half of next year, this is what our priorities are. To me, that's reasonable. It's not, like you're giving people information so that they can do their planning and make their decisions, right? And as you move forward, then, as we get to first quarter of next year, we have higher confidence we can put more specifics, right? And if there's certain dates, like for example, you got a trade show in February and marketing is saying, "Look, we got this big trade show in February, it's our first trade show post pandemic, we're gonna go and we got a demo and got big booth and all that, and we need the latest, greatest whatever." Okay, that's fine. That's a date. Like I know exactly when the trade show is, it's February, whatever.

  - We can't really move it.

  - You know, we can't go, "Well, around that time, more or less." You work towards that, and then as you get closer, you decide, like the date can't move, but maybe the scope of what we're doing is gonna move. It's gonna change, right? You work in that. But, so I think dates are important, but not overly focused on delivery, right? Their dates in terms of context, in terms of strategy. And so I use the word timeframes. That's really, versus dates.

  - Really like that. So I love the exploration there of talking about the timeframes, specific dates are still, they're okay when they need to be, but we also need some agility to allow some flex. And I love the thoughts around of confidence as well. You know, of course we can be confident in something that we have a delivery plan for and we're actually delivering right now, but we should encourage the fact that things can change a bit further out.

  - And the thing is that, that's again a good point to distinguish between a plan and a roadmap. You know, my roadmap, which is tied to objectives and things, might be a year even two years out. It's depending on the business you're in. I mean, I remember one seeing a roadmap from HP for their Itanium processor, if you remember that way, way back. And if I recall correctly, I think this is around 2004. So it was a while ago. But it was about a 15-year roadmap for their processor. And what was funny was they were like, "Okay, in 2012 we'll have this, and in 2000." And of course like two years or three years later, the processor was pretty much dead. But they had this roadmap. Yeah, that's not the kind of roadmap I'm talking about, but in certain industries you might need for, like even cars, right? You know, car companies, they don't work on software lifecycle timeframes, right? They work on on very different types. So it's whatever is reasonable for your industry. But in software, to me, one to two years as a roadmap is good. And then a plan could be like half a year to a year. Again, depending on the kind of software. 'Cause you can't really be confident about a plan and delivery dates more than a year out. I mean, I think even a year out is a long time. But again, it depends. I worked in companies when I said Informatica and we had very long release cycles. In some cases, like some of our releases, we started 18 months before we delivered, right? And we moved dates around, we changed scope, we did lots of things, but they were very long release cycles. So you can plan for things, but they're aspirational at that point.

  - That's a really good point as well about the context, again, the context of the roadmap, but also the context of your company. You know, manufacturing companies, the chip manufacturers, the service providers, they're all gonna have different roadmaps because it's gonna take certain levels to, certain lengths of time to be able to create that roadmap. And they're also gonna have to think about, well, how long are we gonna maintain this for? You know, even if we take automotives, we're gonna build this car until its successor comes out, but we're gonna have to still support that car and the pieces for it. So that roadmap extends out and out and that's very different from a software B2B type company.

  - Absolutely, absolutely. I once had a conversation. So Toyota was a customer of ours at Informatica, and I had a conversation with them and they were talking about some system they were building and it was to manage parts. And it was really interesting because he got deep on what parts meant and he said, "You have to understand that a part could be many different things." And I said, "Well, what do you mean?" He goes, "Well, take in example a spark plug. Is it an original equipment part, is it a replacement part, is it a substitute part?" He just went on and on and on, like there was like six or seven different types of parts. And it was exactly to your point, like the original equipment part is when you first manufacture, but when you're supporting and you're doing maintenance, there are different parts and we have to understand that. And like Toyota cars last a long time and so we have to think about that from a long perspective. So yeah, I think that's absolutely right. Like the industry will matter. But when we're talking about software, which I think is mostly the context of what we're doing, it varies even still. But one to two year roadmap on a mature product, maybe for a very early stage startup, like even six months, the amount of uncertainty is huge, right? And I was almost asked to, actually, this is interesting. I once worked with a client and they were like pre-product. So they were doing some really good discovery work, really trying to dig in, understand problems, and they had this one idea that they were trying to really, really focus on. And they said, "Can you help us with a roadmap?" And I was like, "Okay." And then I started thinking about it and they started asking questions and it was like, "No, there's no roadmap right now." 'Cause you don't even know enough to confirm what direction you're going. And until you have that and you have some traction, et cetera, then we can do that.

  - We had a guest on the channel previously, Daniel Elizalde, and he was talking about that at that certain stage of a company, your roadmap should be your first 10 customers, and then you can start to understand what the commonalities are, the patterns, and then you have the opportunity to start thinking about what it is your solutions are. But you're right, it was too early for them to start to create a roadmap of building stuff. They were on a voyage of discovery.

  - I think this is where the problem can often start between roadmap and plan, right? So at that very early stage where you don't know enough and the risk is very high, I'm gonna say something and then I'm gonna regret saying it, but your roadmap is your plan. Like at that very early stage, there is no such thing as a strategic roadmap. There's a plan, but you can, those words get used interchangeably. And I think if you don't realise the distinction early on and you're, "Oh, the roadmap is whatever the first 10 customers are gonna do," then it just sticks. And then the roadmap and plan become intertwined in your thinking, in your language, and you don't make that distinction of the strategic side of things versus the tactical side.

  - Before talking about kind of some of the good and bad, and I know we've touched on some of those already. I'm just curious, from your perspective, what are some of the tools you prefer for using to create, to manage, and visualise roadmap?

  - I'm kind of neutral on tools, right? So I think before we get the tools, we really have to understand what we're doing, and then have a clear process to decompose that work, right? So I have customers who've used some of the tools. Aha! is one, ProdPad is another. There's a couple others, Roadmunk as well. And I think that if they're clear about the process to get to a roadmap and a real roadmap, like a strategic roadmap, again, priorities, direction, et cetera, I think most of these tools are capable enough. In fact, I think they might be too much, quite honestly. And I've heard some comments about a couple of them that it was just like, oh, it's really complex. It used to be simple, now it's really complex. Because again, if we go back to the early question about what's the purpose of a roadmap, one of them is communication. And it's hard to communicate complex things, right? Like you want to distil things into simple visuals, and then tie them to clear objectives. And so I don't have a preferred tool. In fact, I'll say this. I have a tool that I've built myself for the work that I do and I use it with my clients. And it's not a competitive ProdPad or any of these products, but it does give people the basic framework and the ability to build that business roadmap first, and then feed that into a product roadmap. And then from there, they can export it into whatever. If they use Aha! or ProdPad, they can export and do whatever. But the point really is you're focused on the most important things. And those most important things are not some huge visualisation in a tool. They're really the key objectives you have. And then the components that break down into, like for example, organisation, business, go-to-market product. And I'll just say this. I really recommend people not focus on tools upfront. You know, it's like, I'll just say this. My kids, they're older now, they're all in university and high school, but when they were much younger in public school, they'd be doing math and then they'd always pull out the calculator and I'd always take away the calculator. And yeah, and I'd be like, "Okay, you don't need a calculator for this." And they, "But the teacher said," and it's like, just understand the process, right? And if you understand the process, then use the calculator to help you streamline the things that you're doing. So I think that's really the recommendation I would have. So I think tools are great, but I think tools are only great if you know what you're doing and you understand them. And by the way, strategy and roadmapping really are such ambiguous terms for most people that you can lose sight of what you really need to do when you get into a tool and it's got lots of features and buttons and things like.

  - That's such a good answer, Saeed. I absolutely love that. I've got a question here, which is what is one of the biggest mistakes you think people make in roadmapping? And I think you just perfectly answered that there. And that really resonates with me as well. You know, whilst I've got a history of working for one of these tools companies, and I've done product roadmaps in my time as a product manager, a lot of the clients that I help now is helping them with the fundamentals of that roadmap. The problem is not the tool. The problem is the thinking around what we should be doing and putting on that tool. And that really resonates with me.

  - I think it's important business work, right? And it's like a spreadsheet, right? A spreadsheet's great, but if you don't know what you're doing with the spreadsheet, spreadsheet isn't gonna help you.

  - So I wonder if there's any anti-patterns or bad practises that you regularly encounter. We talked about dates being a bit of a pet hate on the roadmap, but are there any sort of bad practises that you encounter when you're working with roadmaps with your clients or with people?

  - Yeah, the dates, the Gantt chart roadmap, I think is another one. I think the quote, unquote, feature roadmap, I think that's an anti-pattern. I think the word, like the phrase feature roadmap is an oxymoron, quite honestly. I think the lack of collaboration in developing a roadmap is I would call that an anti-pattern in the sense that, okay, product management owns the roadmap, but product management doesn't do that work in isolation. I think a lot of product managers are fixated on the build side of things. And that leads to just some problems in the sense that if your goal is product success, right? Build is only one way to get success. But yet if you think about the roadmap in isolation, that's really all you're thinking about, right? Oh, what are we gonna build? Let me define the roadmap and prioritise it. I think another anti-pattern is, and this ties into the collaboration, but every product manager has a lot of context, right? They're talking to customers, they're, hopefully they're talking to customers, but let's assume they are. They're talking to customers and doing research and discovery and understanding problems and things like that. But the idea that their context is the primary context when thinking about a roadmap can be problematic. And what I mean by that is, let's just say you did a bunch of discovery work and you talked to a whole bunch of customers and you heard something that was quite common among those customers. Now, okay, that's a customer problem and clearly it's something that your customers are raising up. But the roadmap isn't just a reflection of customer problems. And so if you say, "Oh, you know what, we talked to 10 customers and some of them said this thing is really a problem or they'd really like to see this enhancement or whatever," whatever your sort of rationale is. And so we're gonna prioritise that high. Well, where's the business side of it? Like is that helping you achieve the business goals? Is that really aligned with the context and the rest of the company? And so bringing that in is great, but working collaboratively and understanding the business context and blending the business and the customer context together is really important. And again, this is why this idea of a business roadmap and then a product roadmap to me is really powerful because you're going to start with the business, right? You're not coming in with a non-business perspective, and then you bring them together. So I think those are some common, you can call them anti-patterns. I mean, attention to detail is a real problem, I think. You know, roadmaps can be high level, right? People talk about outcome roadmaps or problem roadmaps and things like that, but it's, you really have to get into detail in the sense that, it doesn't matter what you prioritise, right? You can, hopefully, you're not prioritising features, but if you're prioritising features, you're prioritising outcomes, you're prioritising problems, et cetera. What's the context and are these the right ones? Why did you prioritise them, right? You really need the details underneath it to say, "Yes, this is important," and then connect it back up to the higher level objectives. So the commitment and delivery side, obviously, is in the plan, but you still need detail at a roadmap level.

  - Such a thoughtful response, Saeed, thank you for that. I totally agree with you. It really resonates with me. You've got some great perspectives here. I'm wondering whose advice on roadmapping you listen to or whether there's any resources that you use or recommend on roadmapping?

  - I learned a lot by debating people, I think. Like I put a lot of stuff up on LinkedIn and Twitter and hear perspectives and I learned a lot from customers. I think as a resource, so I'll just say this. So the book, "Product Roadmaps Relaunched," which I think you probably are aware of, Bruce McCarthy and-

  - I have a copy here.

  - Exactly. I have one here too somewhere, actually. I should have pulled it out and made it handy, yes. So I think that's, quite honestly, like if you're interested in roadmaps, I think that's a really good book. I think they cover a lot of topics. I love the fact that it's a visual book by the way. You know, it's not just some text-heavy book. And so I think that, first of all, I think that's a great resource for anyone who really wants to learn about roadmaps. I think things that are good or things that I agree with. I generally agree with what's in there. So Bruce, I think, obviously, he talks about roadmaps a lot. And then I think there's a lot, what's interesting is there's a lot of really good resources on the web, but then there's a lot of really bad resources. And so like you can find on Medium, for example, you can find blog posts that talk about things like a roadmap is a list of the features and the, and it's like somebody very earnestly and sincerely wrote a detailed blog post and you're just like, "Yeah, but that's not really true." But that's their experience, and so it's hard for me to recommend very specifically 'cause I know them when I see them.

  - I think that's a great response is that for the people in the audience, if you haven't read the "Product Roadmaps Relaunched" book, it's a great place to go and see to understand roadmaps and how really they were intended to be launched and to be used because there's a lot of, sort of malpractice out there and a bit of unintentional and unintentionally bad guidance, I think, too.

  - I think that's a big challenge actually in general with product is that 15 years ago, there was not a lot of content online. You know, there were people who were blogging, things like that. And now there's so much, which is amazing, but you can find so much contradictory information. And it's no wonder a lot of people are confused, like what's the roadmap? What's the plan? What's prioritisation, what's like-

  - Exactly. No, I totally agree. And I think that's the part science, part art side of roadmaps. It can be a bit of both there. I've absolutely loved today's conversation with you, Saeed. Thinking of wrapping things up, and this is probably the most difficult question to ask you, which is after all that, if you had to distil your philosophy of roadmapping into one to two sentences, how would you describe it?

  - So I've used some of these lines before, but I think the thing I try and distinguish, first of all, is the difference between a roadmap and a plan. And I think that's really a problem that plagues so many companies, right? So the kind of, the tightest distillation I've gotten to is that a roadmap is a statement of direction and priority, right? And a plan is a statement of commitment and delivery. And I think that language is very explicit, but it's very intentional. That direction and priority is what you should be thinking about. And the roadmap feeds into the plan. And the purpose of that roadmap is to make sure that you maintain your direction priority in your plans. That you don't get sidetracked by shiny objects or HiPPO ideas or sales specials or whatever. And there's a place for all of that. I'm not saying that those are all bad things, but they have a place and a way to be dealt with. But you shouldn't forego your roadmap because your roadmap, strategy, objectives, vision, right? It's aligning all those things is where you wanna go. That's where, it's gonna get you to where you wanna go, right? It's kinda like, my kids have a little thing with me that whenever we go somewhere, dad's gonna take a side trip. While we're going to the store, let's go over here and check out this thing, or there's a farmer's market over there or something. And if you think about it, like on a Sunday drive, it's not harmful, but if you're doing these side trips in your company, you're distracting from where you really wanna get to. And then the flip side of that is I'm not competing with anyone on my Sunday drive to go somewhere, but you're competing with other companies to get somewhere. And so every distraction that you go down is an opportunity for your competitors to get ahead. And so you're all headed in the same direction, you're trying to get to the same thing, you wanna dominate your market, you wanna compete, whatever. And if you're taking these, oh, sales special side trips, et cetera, it's not, you're not gonna win. You might think it's great, it feels good in the short term. "Oh, we did this one short-term thing," but the opportunity cost and the long-term cost isn't easily measurable, but it's real. And so I think that the idea of having this roadmap, tying it to strategy, objectives, and vision and being really diligent about staying focused on it is critical for any product company, right? And I once talked with Eric Boduch, Eric who's one of the founders of Pendo, and we're talking about, actually, roadmap and how they approached it and he said, "Look, like if, we absolutely were sensitive to deals and things like that. But if we had to do something that was gonna accelerate a roadmap, we'd absolutely consider it. But if it was gonna take us somewhere else, then the answer was no and we were really strict about it." Right? They had a clear vision of where they were headed and I thought, yeah, like that's, I mean, it sounds logical when you say it, but when you're in the heat of the moment and you have to say no to a check or a deal, it's a lot harder. But I think that's really the goal.

  - I love that analogy about the kids in the car on a Sunday and the insights you've just shared there. So I thank you so much. You've been incredibly generous with your time. So we've really enjoyed talking with you. I wanted to give you an opportunity just to connect with our audience, tell them a little bit about what you do and pitch how you can help people.

  - For the last number of years I've been working as an independent consultant working with technology companies, software companies, usually startups and scale-ups. And really, as I said earlier, I talk about how to help them build better products and build better product organisations. And it's really the second part where I find the most value. So things like mentoring, training, workshops, helping them do this hard work, the discovery work, the roadmapping work, et cetera, and sort of help ingrain it into their organisation so they can then go and do it themselves. So the work that I do, it's sort of very hands-on, very active. And then I work with leaders as well to develop leaders and sort of help them manage their teams. Because a lot of leaders, I mean, this is truth, I'm sure you know. A lot of leaders in product didn't come from product. They came from other areas. And this whole area of product is new to them. So I work consulting, advisory work. And as I said, training and workshops, and really helping these organisations build long-term sort of high growth, high performance organisations.

  - Fantastic, Saeed. Well, we'll share the contact details with you down below, your website, maybe a link to your LinkedIn profile so that people can find you 'cause I think that's a really worthy cause there. So Saeed, look, thank you so much for spending time with us. I've really enjoyed it and I can't wait for our audience to hear. For the audience out there, really hope you've enjoyed today's session. Some great insights from Saeed there. If you haven't subscribed already, please consider subscribing. It really helps us to grow the channel for other people to hear wise words of wisdom from Saeed and myself having a chat there. Again, please feel free to like and follow the channel, and may be share it out to someone. If something that we've talked about resonates or you think it might resonate with someone else, do share it out to them as well. And if you'd like to take part and be where Saeed is today, feel free to reach out, drop a note in the comments or email us in. We'd love to have you on the channel to speak with industry experts and practitioners alike. Saeed Khan, it's been an absolute pleasure. Thank you so much for joining us, and I look forward to speaking to you soon.

  - Yeah, thank you. It's been great. Thank you for having me.