Can a roadmap answer all your questions? | Cliff Hazell

In episode 59 of Talking Roadmaps, Justin Woods interviews Cliff Hazell about the limits of roadmaps in answering all product questions. Cliff introduces the concept of flight levels to explain how roadmaps can serve different layers of an organization, from strategy to operations. He emphasizes the importance of context, adaptability, and focusing on real organizational capacity rather than overloading teams. The discussion highlights the need for flexibility and alignment across all levels of a business when using roadmaps.

Cliff has made a career out of breaking down the obstacles that stand in the way of great work. He is often challenging the status quo in his quest to develop the right culture and systems for the creation of excellent Companies and Products.

After a tour of addresses across South Africa, Cliff moved to Stockholm where he led a team of Coaches at Spotify for 4 years.

Now he helps Scale-ups remove their Growth pains, enabling them to Create Focus, Find Leverage, and Build Habits. More than guidance and theory,

He'll teach you how to do it so you can continue and fly solo.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

Can a roadmap answer all your questions? | Cliff Hazell

Justin Woods and Cliff Hazell

In the next episode we are talking to Steven Haines, he’s an author and the CEO of Sequent Learning Networks. So watch out for Season 1 - Episode 60!

• Transcript

  Cliff Hazell:
  The point is really that whatever we're doing, there's always going to be some level of, you know, things we don't know, and people who have different ideas, and so the idea that you could have a roadmap that is ever going to answer all of your questions, I think that this is not the point, and I'm not even sure that that's achievable.

  Justin Woods:
  Welcome everybody to the Talking Roadmaps Channel. Today I'm joined by Cliff Hazell. Cliff, welcome. Please introduce yourself.

  Cliff Hazell:
  Thanks, Justin. It's lovely to be here. I started my kind of background is in product management in South Africa, most recently I've been at Spotify in Sweden, and since leaving the company, I've been jumping around all over the world, and helping companies that are doing all kinds of interesting things as they're growing and scaling up, mostly in the space of kind of leadership and coaching leaders, basically to build better organisations, and design more sensible systems. So lots of interesting things that I think can intersect with what you folks are interested in, and so, yeah, let's talk about it, and see where it goes.

  Justin Woods:
  If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. So Cliff, let's dig in with maybe kind of the high-level overall question. From your perspective and from your experience, what's the purpose of a roadmap, do you think?

  Cliff Hazell:
  I guess there's a lot of different takes on what the kind of the objective of a roadmap is. For me at least, I think any kind of exercise that is around roadmapping is really around trying to figure out some kind of, I don't know, I guess a cohesive set of ideas about the direction we're trying to move in. So, you know, you could do something like a now next later sort of approach, you know, those are the things we're doing today, such stuff we'll do later on, and things we'll think about much later. I think there's also things in the space that some folks get kind of hung up on sort of the level of precision and accuracy, like how much detail do you need, and so on, so there's a set of interesting questions and topics around that, but I think at a high-level, the goal is to try to say, you know, we want to move roughly in this direction, this is sort of where we're pointing, and so I think it's really about some sort of a plan, and being able to communicate that to others, hopefully so that we can get some input from them, not just so that we can tell 'em this is what it's, but yeah, I think there's, like, just like everything in the world, there's a thousand different ways that people do it, some people do it really well, some people do it really strangely, some people like certain ways and others different, so yeah, a lot of different things inside there.

  Justin Woods:
  Yeah, it's a great point actually in the classic product management approach, it depends, but there's a lot to unpack, and I think some of the bits that you were talking about, there's certain jobs to be done of a roadmap, as well, that can be at different stages, different audiences you alluded to as well, so I think that's a great response. And actually maybe we explore the audience side of things, who's the audience do you find typically for a roadmap?

  Cliff Hazell:
  I guess it depends a little bit on the type of roadmapping that you're doing. So I'll be honest, I don't tend to use the term of roadmapping, but I also don't tend to use a lot of the common terminology, because what I do is when I'm working with a company, I try to adopt their way of talking about things. So, you know, for some people it's a plan, some people, it's a strategy, for some people it's a literal set of like, these are the things we're gonna do in this sequence with dates and timestamps on it. I think the audience depends a little bit on the goal that you're trying to achieve, so not to be too abstract, but if you're talking to sort of the strategic leadership of a company about maybe several acquisitions that you're working on, you might say something like, "Well, you know, this is the point where we're going to sort of be looking at different companies to acquire, this is roughly what the sort of acquisition process looks like", you know, here's the point where we could say, "Okay, they're actually now fully integrated into what we do", and, you know, we're starting to see some of the benefits of the acquisition. So that kind of thing could make sense maybe to a board of directors or the acquiring companies, that kind of communication, I think it gets used a lot in a product sense, you know, we want to build these things or this functionality, I've worked with a lot of teams that are building some sort of platform or internal services, and so there, what you're trying to do is paint a bit of a picture and say, you know, "We're doing this stuff now because you've asked for it, we're gonna do this stuff later because maybe it's, you know, it builds on the thing we're doing now, or it makes more sense to do that after we've done something else", and just kind of set and align expectations a little bit, so that people aren't just constantly going, "Hey, can you do this thing? It's really urgent, we need it yesterday." I think that's part of the conversation that you're trying to have, and just kind of outline a little bit of like, "You know, here's where you can be involved, this is what we're thinking about", and as a tool to get it out of somebody's head, and into a conversation space where others can weigh in, and say, "You know, I like this, yes or no."

  Justin Woods:
  Yes, it's a great response and I love the fact that, you know, Cliff, you work with a lot of different clients, and get involved within their business to help them with their pain points and help them kind of overcome and get to where they need to be, and I think sort of jumping in and understanding the tools that they're using at the time, the language they're using is so important, first of all, to help embed you within the company as quickly as you can, but also so that you are talking their language, and it's not around just taking a couple of different frameworks or tools off the shelf and throwing them in. You really need to meet with them where they are now, and help them get to that new piece by maybe introducing something, or just working with what they've got, and I think this is one of the reasons why there's not really a one-template-fits-all for roadmaps or anything else, because it just depends completely on that client and where they are.

  Cliff Hazell:
  I think a lot of it is that you have to recognise that everybody is on a bit of a journey, you know, maybe they started somewhere, and they're going somewhere else, but it's like the idea that you would sort of, I don't think that there's a point, where like you have most things in product development, and products kind of design, it's always going to be a little bit messy, and so at least from my experience, the kind of stuff that I've been working with, it lends itself to trying to be roughly coherent, if that makes sense in the sense of like, you know, if we're doing this thing, we're going left, but we're also trying to do something where we go right, that's not coherent, because those two things are in tension with each other, and there's going to be some obvious friction and conflict. Whereas if we're saying, you know, we're building two sets of capability that when they actually connect, they enable us to go further, because, you know, they amplify each other, something like this makes much more sense in terms of coherence. But the point is really that whatever we're doing, there's always going to be some level of, you know, things we don't know, and people who have different ideas, and so the idea that you could have a roadmap that is ever going to answer all of your questions, I think that this is not the point, and I'm not even sure that that's achievable, you know, as long as it's useful and it's helping you to have a good conversation, I say great, but I think I've seen a lot of companies and a lot of people when they, especially when they're using it like a tool, or if there's some sort of like change programme attached to it, you know, "Everything is in Jira, then it's all going to be magic and ponies", and it's just like that reality just never, ever actually happens. And so I'm always kind of a bit cautious of working with folks who haven't actually seen the things that they're selling, working in practise, and unfortunately, there's quite a lot of people out there who, I mean, I think it's fine if you're sort of aspirationally saying like, "Imagine if we could do this", like you're inspiring something, but it's a different thing to be able to say, "I've done this, and I actually know how to get you there. I've walked this path before", and I think in the world of product management for sure, and certainly in the agile space, where I've spent a lot of time, there's a lot of people selling things that they've never actually seen happen, and I think that that's a little bit challenging, and usually that's one of the things that I caution, I mentioned earlier that I've been at Spotify, and I mean famously there's companies like McKinsey selling the Spotify model, none of the people who sell that have actually worked at the company, and putting aside whether or not you should copy the model, it is very strange to me to say like, you know, "I can teach you the McKinsey model, I've never been at McKinsey, so what do I know about their models and tools?" You know, so I think there's a couple of things inside there that are interesting to chat about.

  Justin Woods:
  Yeah, I fully agree. You know, I think we need to be looking at, there's tends to be a lot of bashing around, you know, I'm seeing at the moment, at least at the time we're recording, around discovery, around product management and those things, frameworks is one, and I think we need to you know, look at these different tools on their merits, and make an informed decision on them, and also take some of the best practise bits that we like, and leave some of the other bits, the best implementation of a tool, or the best practise for a company is often what works for them. You know, I've been having some recent chats with my wife who leads a business systems team looking at bringing OKRs in, and how that can work, and there can often be a lot of confusion, or a bit of doubt and things like that, and I said, "Look, just look at the framework, look at the bits that are relevant to you, implement those that work, and just evolve, you know, we should product manage these tools and techniques to a level, and just take the bits that work for you." And often the best practise of that is actually what works best for the company, not whether it's specifically working in the exact way that the framework thought that it should work, you know, and I think that really makes sense that there's a level of caution we should take in roadmapping or in fact in the Spotify model, as well.

  Cliff Hazell:
  I think that that highlights an interesting thing. I like to separate two types of practise, at the very least, the difference for me between best practise, and let's say, good practise. I think very often what happens is that people assume best practise as if it's like a sort of universal, applicable thing. There are a incredibly small set of things in the world that I think are best, always best, if that makes sense. So what I like to differentiate there is like something like using OKRs for example, I would consider that generally to be a contextually appropriate good practise. If you have this set of problems, it may help you with those, right? If you don't have those problems, however, it's not good practise, and it's certainly not best practise. But I see companies often muddling this up, and I think that this is a big part of the challenge is that what we tend to do, I mean it's a human nature thing to an element, or to some extent, but we tend to leap to a conclusion, or leap to a solution before we've actually understood very much about the context that we're dealing with. And the funny thing is that we do it both to ourselves, like in our own company context, but we also do it with others when we're diagnosing their situation. You know, I could say, "Oh, Justin, your business, you need to do this and this, and then you'll grow like that and so on." The reality is that you understand that context better than I do, and so this is a lot of the approach that I take, and why I don't usually come in with a lot of language, especially at the start. That's not to say that I'm not bringing any sort of new concepts or ideas, but when folks talk about best practise, I'll often say, "Well, are you talking about something that is always best for every situation, or are you just meaning that it's the best thing that we know about for that context? Let's define a little bit what that context is, so that we don't use it when it's not that context." You know, it's a bit like the hammer sort of situation. If you have a hammer, everything looks like a nail, and I think this is the challenge is that we have to get out of that idea, because the most common mistake that I see folks making is using an approach that is not suited to the situation that they're dealing with. And you know, you can hire the best people in the world, but if you're hiring for the wrong skillset, or you're putting them in the wrong places, or you're giving them the wrong problems to solve, using the wrong tools, I don't think that this helps so much. And so I like to get that understanding of the context right, or at least coherent to go back to the term, and sometimes the roadmapping exercises can help to paint that picture. We think we're here right now, we're going there, "Okay, this makes sense to do because of those things that we understand about the current situation."

  Justin Woods:
  Yeah, absolutely. Or sometimes things like roadmaps can actually drive the anti-patterns that we don't want. You know, Marty Kagan's often talked about roadmaps being very much associated with feature teams, and things like that, and that's not a good, I mean, in some instances it is, if that's definitely what they're engineered to be set up for and that's what they need, but traditionally it's not what they should be used for, and I think it's having a level of responsibility over the tools and frameworks that you introduce, and knowing what they're there for. And you know, I've been in situations, where a roadmap has been really positive, and I've been in situations where a roadmap has not worked very well, and it's been the wrong thing to share, you know, a stakeholder asks for the roadmap, maybe the roadmap is not the thing that they need to make the decisions they need to make. It might be a list of goals, or a list of principles, for instance. So it's great that you've got that experience, Cliff, where you understand the tools and the frameworks that you've had experience with, but when you work with your coaching, and your consulting clients, you're going in with a level of curiosity so as not to bias them. And I think that's important.

  Cliff Hazell:
  I think also, I mean, I'm quite lucky in that for the most part, I get to pick and choose the clients that I work with, and so part of that process is that I want to make sure that what I'm doing and how I go into that situation is by making sure that I'm really only working with people where I think that I can bring something useful to the conversation. When I first started out with my consulting business, I mean, there's definitely a temptation, you know, you're always sort of worried, "Am I gonna get clients? Is everything gonna work out?" and so on, I think this is a natural concern that a lot of people have, but what it leads to, I think a lot of the time is people jumping into and taking work, because it's available, rather than because they can add something unique to it. And I mean, I don't say like, I have never done that in the past, but I try not to do this now, because what I wanna do is try to understand what is the context that people operating in, what is the situation that they're trying to solve, and if you're looking to do something like just instal the Spotify model, I mean, I can talk to you about some of the nuance of it, and probably the conclusion that you should draw is that you can't actually copy the Spotify model per se. That doesn't mean you can't learn anything from the experiences of what Spotify has done, and use that as a lens to make improvements to where your organisation is maybe struggling, or where you have an opportunity. But I think the idea that you can go and say, "Well, you know, if we're gonna make everything, you know, in our squads, chapters, tribes and guilds, I don't know, like, is that fixing, like what's the problem that it's fixing?" And so a lot of the time, I've come into companies, where they've already gone through that kind of change, and they're saying, "Well, help us figure out how to make sense of this, and kind of organise ourselves sensibly." And surprisingly often the conclusion is that you've added quite a lot of complexity and change into an organisation that was already very, very busy. And the thing that you haven't addressed is the enormous amount of work that is beyond your capacity to deliver. And so fundamentally the fact that stuff is not coming out and that very often the things that are coming out are subpar or not achieving the results that you want, has very little to do with the organisational structure in the sense of did you have chapters or tribes of guilds. It's much more to do with the fact of like, you're trying to do too many things, and you're putting people working on totally different things, and then creating this nightmare mess, where like, every time I need your help to do something with me, I have to wait because you're busy for the next six months on something else. And you compound that by the entire organisation. And so, you know, if we start looking and say like, "You don't have to throw away everything that you've done, this is the context that you now have, this is how you're working, but let's be careful about not just trying to, you know, kind of roll it out to everybody, because if it doesn't work, now you've replicated it everywhere, and certainly there's going to be at least one or two situations where like, even if it's a great idea, it probably doesn't work for every team." So let's unpack a little bit of that nuance and say, "Well, what situations is this great for, like high-end innovation, cutting edge stuff, is it great for more order taking, service delivery, you know, doing the same repetitive tasks, is this great for more of a customer service, like, you know, custom development sort of situation, what kind of things are we dealing with, you know?" So yeah, I think it's very important to, I've said this a bunch of times in a number of different ways, but like really understanding where you're starting, because for me, so often what I see people doing is saying, "Well, we're planning a trip to London, for example, but we have no idea if we're starting our journey in Cape Town or in Stockholm." You plan a fundamentally different trip depending on where you're at. You know, we could actually drive from Stockholm, you could technically drive from Cape Town, it will take you a very long time, but you know, how soon do we need to be there? What are the budgetary constraints? You know, do we have to be there on a certain date or time, or is it just get there in whatever means possible? And so shaping that and giving a little bit of an outline to some of the constraints of like, we're here, and we're trying to go roughly in this direction, or to this destination, that I think is a lot of what, you know, these kind of topics and such as roadmapping, and some of what I've talked about are trying to solve for.

  Justin Woods:
  Yeah, so that's a great, great conversation. And so actually that might lead us nicely into, from your perspective at least, what do you think some of the key elements or content of a roadmap might be?

  Cliff Hazell:
  What I find is a lot of the metaphors that I use in an organisation is the one thing that I often will introduce is this concept of thinking through the lens of flight levels. So for those who are not familiar with it, basically the concept says like if you think about an organisation as, you know, different levels of sort of zoomed out, or abstraction, if you will, if you fly close to the ground, you see a lot of detail, you know, you're in the weeds, you can see, you know, the specific people we're hiring, the specific features and details, the UX wire frames, markup, whatever. If you zoom out and you go high, what you start to see is the breadth, you can see the broader context, but you don't have the detail anymore, you lose that detail, right? Each of these views is different, but important to the company. There's not one that's better than the other, or more important, they all part of the same system. You've just zoomed in or out, right? The question for me is that very often what I find is that when people start talking about things like roadmapping, they're actually talking only about the detail of what the team is doing. So literally this feature, then that feature, then the next feature. But if you zoom out one level, and I like to think of the organisation as operational, so teams on the ground, hiring, building financial reports, product features, whatever it is, at the top, you have strategy, so up strategy, and in the middle coordination. Don't attach too much to the names, there is some nuance and some things that are important about it, but are we solving a problem that is actually about coordinating multiple teams, so we need these five teams to work together to build a product, market it, support it, sell it, that's a value stream, and we should perhaps focus on, you know, roadmapping or visualising things in the coordination space. But we should also make sure that it connects to the strategy of the company overall. Because if we're saying, "Well, you know, the strategy is to be more cost-effective in the following ways, and we're trying to automate and so on, but then you're building some new custom stuff that is not automatable, does that make sense? Is it again, to this point of coherence?" So I think what we're trying to do is first ask this question of at what level of the organisation are we trying to make improvements, are we trying to, you know, visualise, and make sense of the projects, the initiatives, are we trying to make sense of the strategy and the broader kind of investment areas that the company is pursuing, or do we care about the feature level detail? And I think because a lot of people haven't thought about things at multiple levels, and a lot of people, I think actually, they either just don't know, or maybe they struggle to think about things on many different timescales at the same time, they tend to go down into the detail and manage, is that thing on time, well, you were supposed to do that by last week, like the KPI is red and it should be orange or green, and I mean, those things are, I'm not saying they are insignificant, but at the end of the day, like you could be perfectly on time, but you built entirely the wrong thing for your customer, I don't think that this makes sense, or you built something that the customer wants, but it turns out that that's not the customer you have, or it's not a customer that's profitable, or it's not about where your strategy is pointing, because you're doing, you know, Asian expansion, but you're busy building products and services for Europe. Yeah, I don't wanna just say always like zoom out, but it's like, where are you looking, and then we can have this conversation about how do we visualise things, because for me, if you're building that coordination system, it's about building, I mean, I would say it's roughly creating something that is akin to a living roadmap, you know, these things are in whatever stage of visibility, or of development, or of thinking, or of certainty, or of delivery, and so we can map those out at the appropriate level with the appropriate audience, and have a conversation ongoing about, "Hey, this thing hasn't moved in six weeks, we were expecting it to be here, but it's not, that means something has changed, or, you know, didn't go according to plan. How do we respond to that?" Because the challenge often with the roadmapping stuff is this thing of like, you lock it in, it's a plan, it's a promise, and then we never change it, and quarter after quarter we're just kind of faux number, you know, sort of presenting and saying, "Well, you know, it's, everything's going up and to the right, it's great", but is it actually?

  Justin Woods:
  Yeah, that's such a good response. I love visualising that flight level side of things, and I love that concept of different flight levels, different levels of granularity. I think what's probably important is that thread of strategy going through all of them. So, you know, it's that linkage there, but potentially there's different ways to visualise the data at those different flight levels, as well.

  Cliff Hazell:
  I think so, and I think the first part of it is sort of abstracting a little bit out, or separating out the different things that are like what things move on those different systems. You know, it's a bigger chunk, maybe a larger investment, it's got a different sort of time horizon, the higher up you go, and it's maybe smaller, more detailed oriented, kind of the lower down you go. And I think that the biggest factor is really about trying to make sure that we're creating focus and momentum around the things that are most important. And in the absence of doing this, I see teams, you know, a lot of teams doing scrum or something, they're sprinting every two weeks, and they're delivering something, but at the end of the day, when you actually look at the entire product value stream, they've delivered it, but it's not deployed to a customer, or it actually hasn't got out, because the marketing campaign is still, you know, six months away. And to me, this thing, it is very weird that we spend so much time trying to optimise the doing the work, and not the actual gaps between the part, where I did my work, and now I'm waiting for you to do yours, and that's often, many orders of magnitude bigger than the amount of time I spent on something.

  Justin Woods:
  Yeah, I often think of the V model in terms of, you know, verification and validation, and the build is just at the bottom, and the definition of done for some teams is code complete or testing complete. But actually it should be, it's being used by users. And so, you know, I know that must be something that's very passionate and close to your heart, as well, because that is the point. You know, it's not just, I think there's been over the maturity and the decades of product management, there's been over indexing on the focus of delivery and speed. In fact, Cliff, you mentioned something really recently on LinkedIn, which is around the steering wheel and the gas pedal. Maybe you could just share that one for our audience, 'cause that really resonated with me, as well. It's not just about the gas pedal, right?

  Cliff Hazell:
  Yeah, so the phrasing was that, you know, a lot of people misunderstand what agile software development is about, specifically, or agile as a concept, and basically what I said is that I think that agile is the steering wheel, not the gas pedal. And the point behind this is basically that the goal of trying to do something fast is so that can get feedback quickly, so that you can learn and adjust course. It's not about just getting more stuff done, I mean, at some level, you may want to also do more stuff, but there's no point in doing more stuff if it's wrong or counterproductive. And so often I see companies, I mean, I worked with one client, I've written about it a little bit as well on my website, and on LinkedIn, 400 projects for 100 people, and the question is, well why does everything take so long? It's because everyone's sprinkling at best 25% of their effort on, you know, four different projects. And the reality was, for most of them, it was many more, because, you know, most people didn't only work on four projects, they were working on like 24. So why does nothing get done? It's like, well, because I'm, you know, slightly sprinkling a little bit of fairy dust across 200,000 things, nothing's actually getting out the door. And so the problem with that is that in that kind of situation, I'm so busy focusing on getting it done, that I don't actually allocate, or have any brainpower left to then look at, well, what did it do once I delivered it. And so you end up just, well feature factory, as Melissa Perry calls it, you know, in the build trap, you're just constantly building, building, building, building, and never coming out for oxygen to go like, "Hey, does this work? Like how well does it work? You know, could we learn something, or adjust something, change course?" And I think so much of that metaphor of the steering wheel is really about that. And what I try to get people to do is to think a little bit more about, you know, of the last, you know, two quarters, you know, let's look back, what did we deliver, what happened as a result of that, and if we can't answer that in any sensible way, then well, maybe we should fix that before we just do more of it.

  Justin Woods:
  Absolutely. No, it's great, and it really resonated with me. So Cliff, thank you for sharing that with us, I think it's a great metaphor. I wonder if you have any preferred tools for managing and visualising a roadmap. So in the times when you do, or the times when you have with clients, there any preferred ways of visualising it, or managing those roadmaps?

  Cliff Hazell:
  So I'm fairly sort of tool-agnostic, or like framework-agnostic, I use the sort of the metaphor of flight levels, and a lot of the time what I'm doing is helping companies to build either the coordination level, or the strategy level, I find usually most of the teams have got something at the team level already, they're doing scrum, they've got Kanban, they've got Jira boards, Miro boards, Mural, whatever it is, a whiteboard, a Excel spreadsheet, you know, Linear is quite popular these days, it's picking up, and so I don't think that the tool, I mean I do think tools matter, but I don't think that the tool is the most important point of leverage, and in a lot of the companies that I work in, that decision has already been taken. So, you know, there is a tool that is used, and you know, I'm not a big fan of most of them to be honest, I think they end up becoming about the tool, and there's a great phrase I heard, "First, we shape our tools, and then our tools shape us", and I think there's a couple of examples, so not to pick on Jira, it's the easy one to kind of pick on, but you can only have a thing assigned to one person, you can't assign it to a team or a group of people. And so that kind of puts the idea that this is your task, or you are the accountable person, we can't share responsibility for things. There's also sort of things like the way that it does some of the things around visualising lanes and so on, you just end up with piles and piles and piles of stuff, and there's nothing that kind of visually hints back at you to go, "Hey, maybe you shouldn't start that extra 14 new projects, because you haven't finished the other 14 from last quarter." Whereas a whiteboard has a physical boundary, for example, and Excel sheets, you know, runs out of space at some point, and like most tools have some kind of a nudge if they're doing it well, and I think often we miss those kind of things, because we need the reminders, 'cause we're not so good at doing it ourselves. But in terms of visualising, I would say the thing is to try to get usually the projects and initiatives across not just product delivery, but also things like, you know, maybe bug fixes, maintenance, it could also be improvement activities, you know, something that came out of our quarterly retrospective or half, you know, last project postmortem, something like that, and we say, "Okay, cool, like we have to balance across the capacity that we have", so it's the same 150 people in this tribe, or this department or whatever, whether we're making improvements to the way of working, we're fixing bugs, we're hiring people, we're building software, whatever it is, it's all the same people. So let's put it all in one place, and have a look at it, and say, "What are we gonna do about this?" Like, I might, as I've often said in some of my workshops, I talk about this situation where, you know, I might have to make a trade-off decision between, I'm supposed to do an interview this morning, but I'm also needed to fix this emergency fix that has to go out that's blocking the whole of the company's releases. What do I do? Maybe you can fix the bug, or maybe you can take the interview for me, and we can resolve it somehow, but we need to have the space or a place to be able to have that conversation, and as much as I think that in sort of organisations that become more experienced around this, you have these patterns kind of ingrained, but if you don't have those patterns, you have to be quite intentional about creating them, and so you might use something like a standup, for example, to synchronise activities, but it might look a bit different, once you've evolved and improved it, and tweaked it, you know, six months down the line. But recognising that, you know, if we want to solve big problems, we need to be able to work across people boundaries and across departmental boundaries. Great phrase that I heard, "If you can solve your problems alone, you aren't thinking big enough." And I really like this.

  Justin Woods:
  Superb, what a great answer. And I think you picked up on a couple of things there in terms of some of the anti-patterns or mistakes of roadmapping, which is doing it in isolation, or not really understanding why you are doing it, or even from the tooling perspective, allowing the tooling to guide your processes when really a tool should be there to expedite and underpin your processes, I think that's a big anti-pattern that we see there. What are the, what do you think some of the biggest mistakes are that people make in roadmapping? And I know from your perspective, Cliff, that sometimes roadmapping isn't the answer there, even it's not the right tool. So are there any sort of mistakes that you see when people are road roadmapping with your clients that you work with?

  Cliff Hazell:
  I would say probably the most obvious one is ignoring the capacity of the organisation. Almost always. I mean every company from Spotify to others that I've worked with at some point in time has said, "Here's the 17 priorities for the quarter", and you know, if you ask, "How many did you do last quarter?", the answer's like "Three or four." And it's like, "Well why did we plan 17?" "You know, we did that last quarter, and the quarter before and the quarter before that." So we're massively over-ambitious about what we can actually achieve, and that's not to say that we couldn't achieve 17, it's the current setup of the organisation doesn't allow us to deliver 17, but you know, we still plan every quarter way more things than we could do, and I think that there's a correlation between those two things. So that would be the number one thing, and I think perhaps one of the other most significant things is the complete lack of diversity of the teams that make decisions about what's even on the roadmap. It's almost always skewed towards senior leadership and skewed towards product management, and in most organisations that skews towards being white men somewhat sort of my age or maybe a bit younger, that's not to say that those people are bad or have wrong ideas, it's just you need a bit more variety, because your customers come from broader backgrounds than that. And you know, the kind of ideas and services that you can build when you all think about it from the same perspective 'cause you went to the same school, it's by definition more narrow than it would be if you talk to a number of different people. So I think including a larger variety of people in the process of deciding what to do, both in terms of defining the problems you wanna solve, but also when you're narrowing down the solutions that you're actually going to use for those problems, I think that's something, I mean, I've yet to see a company that overdid it in terms of getting alternative input. You know, they might be bottlenecked on bureaucracy, but it's usually someone who's got exactly the same opinions as somebody else, but just, you know, there's a minor, insignificant nuance that we're arguing about. Get the variety, get some diversity in your leadership teams, involve more, you know, varied perspectives, and start to build a little bit of empathy for the variety of different human beings that are out there. I think you can build far, far better products when you do this.

  Justin Woods:
  Yeah, that's huge advice, Cliff. I love that, you know, that diversification, if everybody thinks the same, then we're not understanding all of those different options that are available, massively important, and I expect that's critical for when you are working with early stage companies, as well as mature companies, is fostering that level of diversity and inclusion there.

  Cliff Hazell:
  It's almost always the case that the great idea that changes the company in the future is something that someone who was ignored knew about for many years beforehand. Whether this is a cultural shift or a product idea, and it's usually somebody who is marginalised or ignored for a reason that is beyond just like, you know, you weren't in a leadership position, and turns out, you know, there's a big group of the population that gets ignored for leadership roles, so, you know, we can do something about that, but also just that there tends to be a lot of disconnect between the people who make the decisions and the folks who are actually closer to the frontline understanding some of what's going on. And I really wanna stress the point that it's not a case of saying like, you know, "The CEO doesn't know what they're talking about, so they should talk to everybody else." Like the CEO can only see their part of the picture. And so if you want to see more of the picture, and build something that is more coherent with reality, you have to talk to a broader set of people from different levels of the organisation, from different specialisations, from different cultural backgrounds, people who live in different countries, who work close to customers, who work on the support side, who work in sort of the, you know, building the products, all of these kind of things, and yeah, it's almost never the case that this time has been wasted, because you will talk to them and go, "Huh, that's interesting", and you save yourself a tonne of time, because you don't do something that was not so smart, after all.

  Justin Woods:
  Incredible advice, Cliff, that's awesome. Thank you for sharing that with us. So you've learned from a lot of different people. I'm curious whose advice or even resources, whose advice do you listen to on roadmapping, or what sort of resources can you recommend in roadmapping, or even in the wider product management perspective, you know, who comes to mind?

  Cliff Hazell:
  I think one of the first people that comes to mind in the product management space specifically is Melissa Perry, I mentioned her book "Escaping the Build Trap", she's got a number of things, I've known Melissa for quite a few years, and we've had many interesting conversations about these topics, I think she's doing some fantastic work in that space, specifically trying to address it from a senior leadership perspective, you know, working with her, I think the organisation is called the CPO Accelerator. So specifically trying to help, you know, a broader range of people get into being chief product officer at various companies by drawing on experience from, you know, the leaders who've gone before, in sort of the organisational and change perspective, I look lot at the work of Esther Derby, she's done some amazing work, her book, a recent book, "Seven Rules for Positive Productive Change", there's a number of models and tools, she actually has one called SEEM, which is, she breaks the organisation into roughly three levels as well, she calls them, you know, steering in the middle is enabling and enhancing and on the ground is making, her metaphors are slightly different, and she's sort of looking at it from a slightly different like perspective to what I'm talking about with the flight-level stuff, but it very closely maps, and it's sort of like, you know, you're just looking at it from an org perspective, and a leadership, you know, behaviours, I'm looking at it from like a flow and org design kind of perspective, which, you know, so they intersect a lot. I often recommend to a lot of folks that like the thing that they need is usually not to learn more about their specialisation, almost every case, the way that you're gonna level up in your career, or take the next step is not by, you know, I mean if you're just starting out, sure, like read books on product management, but once you've read four or five books on product management, you're probably gonna be finding some diminishing returns, so jump into a different space, and, you know, read some stuff about data science, or read some things about psychology and anthropology, learn about neuroscience and how humans work, talk about customer experience and discovery, talk about, you know, business management, and operations and financial management. And so I think these kind of like the more, I don't wanna say that it's always better to be a generalist, 'cause that's not the point, but it's more like, you know, in order to do a better job of the thing you do, you need to understand the other people's roles around what you do, and you know, you can value the diversity and the variety of their perspective better when you have a little bit of understanding, and a little bit of a sort of language, or a sort of metaphorical understanding of what it is that they actually do. So yeah, I actually have a list that I can send you, I got frustrated last year at some point about every list of books that was being posted on LinkedIn was the same, you know, 65-year-old old white guys from America, and I'm just like, "Ah, you know", it is not that they have bad things to say always, I mean there are some that are saying horrendous things, but the vast majority of it is like, "Yeah, it's interesting, but where are the other voices?" And so I made a list of, you know, I think it was 20 odd books written by women mostly who are not from the same background, and talking about everything from, you know, the science behind what we get wrong about women, and like actually looking at the scientific evidence, and how that has implications for things like seat belts are designed for the average male, but the average male is not really even representative of the average male, it's just the midpoint. So if you're bigger or smaller, and that's especially true, you know, if you may be from a different culture, or if you're a woman, you're pregnant, these kind of things, your physical body is not as protected by a seatbelt, but we design for the median, and that's a problem. And so this book really looks into a number of fascinating things like that, and I think these kind of topics are worth, very much worth exploring, so I kind of dodged your question, and said "Don't read books about product management", but I'll share the link with you for the summary of those posts and you can have a look.

  Justin Woods:
  No, I think there was a lot of value, and I really appreciate that about you Cliff is that kind of like looking at other areas that we can learn from, you know, if we are all doing, if we're all reading the same 10 books, we're all gonna turn into the same types of people, as well, so I think celebrating those different diversities, and things like that is really important. And also looking at parallels, you know, looking at how football coaching works, and how can we bring those learnings into product management, those sorts of things, I think that's a great aspect.

  Cliff Hazell:
  I wanna just like, at the risk of kind of over-making my point on this, like I think a lot of the time, people get caught up in like diversity and inclusion sort of work purely because they think it's like, "Oh, well, we only do it, because it has moral or ethical things", like it's about, you know, fixing problems that we've created in the past, you know, and so on, and as much as I think it is about those things, I think there are also other concrete benefits that benefit everybody. It's not just about, you know, we need to fix, those people don't get to participate. Yes, we need to fix that, because that makes a better society for everyone. And the reality is that if we're building better companies, better products, better services, better internal ways of working in our companies that take into account the variety of different ways that human beings actually function, we don't all fit in a nice neat little box, and we don't work exactly the same way. You know, some of us are morning people, some of us are afternoon people, some of us are evening people, some of us are just like, "Leave me the hell alone" people. Some of us love to have people around. Each of those different styles and preferences just to make a very simple point, have different needs, and will function at their best in a different environment. And if we're not taking that into account, we're ignoring so much of the information that is available to us that would actually make our organisations function fundamentally better for all the reasons I mentioned, and also solve many of the societal challenges and the exclusion issues that we faced historically. So it's a double-edged thing, and I think that if we solve it, it actually fixes both sides of things. I mean, so I encourage people to think about, you know, even if you're not necessarily yet personally excited about fixing the wrongs of the past, still it will benefit you by fixing these things, and if you look at it from these different perspectives, you will understand more about what's actually going on in the world, and build more coherent products, more coherent strategies, and better change initiatives, better roadmaps, all of these kind of things.

  Justin Woods:
  Cliff, I totally agree, it's more than a checkbox of doing the right thing, it's actually, there's so many benefits there that are just, are not even yet being explored. So I really resonate with that. I'm gonna ask you probably one of the most difficult questions I could ask you, which is that could you distil your philosophy of roadmapping into just a couple of sentences or words? So just think around how roadmapping has been for you within your career, how might you distil it?

  Cliff Hazell:
  I think a lot of the stuff that I've learned over the course of my career has been something that when I first started with it was, I was quite dogmatic about it, and "This is how you do it." And we explored already the nuance between good and best practise, so I think we kind of covered a piece of this, but I think that the thing that I would really say is important here is that you have to focus on the goal of what you're trying to achieve. And like, I mean, not to be super philosophical about it, but if your goal is to create alignment amongst a bunch of people, you need to have something that is sort of directionally pointing, and saying, "We're going this sort of a way", probably there are many different ways to paint that picture. And so the idea that you can just go away and write it down and then go, "Is this right?" That's not gonna give you a sensible roadmap. So I don't know that I'm putting my philosophy sort of in a sentence, but the idea of like, it's okay to make a proposal, and say, "What do you think about this?" But if you're not getting answers and nothing's changing from the input, you're either approaching it wrong, or perhaps approaching the wrong people, or approaching them in the wrong way, you haven't created a space where they feel, you know, if I'm the CEO, and I say "This is my idea", but every time someone makes a suggestion, I, you know, dump on them, pretty soon people learn that I don't actually want feedback. And so like these kind of things, like if you genuinely want to build better products, you have to stay open and curious to the fact that they are things that you don't know, and that is a good thing, because A, it means there's still wonder to discover in the world, but B, it also gives you a reason to spend time collaborating with other people and exploring, you know, their different perspectives, and building something that is more, you know, sensible. So ...

  Justin Woods:
  I love that. No, that definitely makes sense. So I think there's some bits in there that, again, we've not heard from other people before, so thank you for bringing your angle to it, Cliff. That's awesome. Cliff, I wanna wrap up by saying thank you so much, it's been absolute pleasure talking with you today. Talk to our audience a little bit about what it is that you do and how you can help them.

  Cliff Hazell:
  Sure. So I spend a lot of time actually writing my thoughts and trying to get things out of my head, I decided sort of beginning of last year that what I wanted to try to do was find ways to basically not always be required to be physically present in order to be able to help and share ideas. That was my initial goal. What I've been doing since then is writing on LinkedIn and on my website, so just find me, Cliff Hazell on LinkedIn, or go to my website, my name.com, so yeah, all of my writing is up there, I try to write something pretty much every day, there's a lot of different topics that I cover, but it mostly focuses on trying to make better organisations, better leaders and better products, and if that kind of stuff is interesting, I mean, I love to chat to people, I love to hear what they're doing, I have some products and services that I sell, but it'll be fairly evident if the things that I'm talking about resonate with you, and you think that you would need my services, feel free to reach out, but a lot of it is things like I coach leadership teams, you know, through this journey of improving their organisation, I can be a bit of sparring partner to inject some new ways of thinking, you know, into some of the ideation process, and I have a couple of workshops, you know, if you wanna build a flight level two system, I can help you do that, you know, set up the coordination system, but that's like, we know the problem already, we can solve it with the workshop, but usually it starts with some of the other stuff. So yeah, jump on LinkedIn, gimme a shout, I'd love to hear what you thought about the stuff that we've talked about here today, as well, and yeah, maybe we can start a bit of a conversation then, and see where it goes.

  Justin Woods:
  Yeah, thank you so much. So for the audience that listening on the podcast, we'll put those links on our website, and on YouTube, if you're following along on YouTube, we'll put a lot of Cliff's links that he shared with us today, as well. Cliff, all that leaves me to say is a massive thank you for spending time with us, it's been an absolute joy to speak with you, and I know the members of our audience have also been beckoning you to join our channel. So thank you so much for spending time with us today.

  Cliff Hazell:
  Thank you so much for having me. It's been really cool. I've enjoyed this conversation, and I like a lot of the questions, you've got me to talk about some things that in a slightly different way to maybe how I've talked about them in the past, and that's a big part of what I enjoy. So thanks for having me and taking the time to listen.

  Justin Woods:
  Thanks very much for joining us. Cheers, Cliff.

  Cliff Hazell:
  Cheers Justin.