Beyond Features: Creating Value-Driven Roadmaps (With Phil Hornby)

Phil Hornby is a passionate product leadership coach. Helping product leaders to think clearly, make strong decisions, and take powerful action that drives high-impact outcomes.

In this episode Ben Maynard sits down with Phil, here is what they spoke about:

Key Discussion Points:

• Roadmaps as Communication Tools: Roadmaps should be seen as communication and alignment artefacts, not rigid plans. They help teams and stakeholders get on the same page about the direction of travel and the problems to be solved.
• Content Maturity in Roadmaps: Roadmaps evolve over time, moving from feature-focused to problem-focused to outcome-focused. The most mature roadmaps include a mix of content types.
• The Problem of "It Depends": Product decisions are always made in context, and the context matters. There's no one-size-fits-all answer, hence the title of Phil's book.
• Overcoming Agile Challenges with Roadmaps: Agile teams often struggle with roadmaps because they are seen as plans. A step-wise approach to introducing roadmaps can help, starting with adjusting the timing and then maturing the content.
• Outcome-Focused Roadmaps: Roadmaps should focus on the outcomes the team wants to achieve, not just the outputs they will deliver. This helps align the team and ensures they are working on the right things.
• The Decision-Making Process: Phil breaks down decision-making into three stages: getting to the decision, making the decision, and implementing the decision. 

Resources:

• Lean UX Training - https://bit.ly/3zTmj5g
• It Depends Book: Phil's upcoming book on product decision-making - https://bit.ly/3zTocyS
• Sense and Respond: A book by Jeff Gothelf and Josh Seiden recommended by Phil for its product mindset insights - https://bit.ly/3ydcP4c

Where to Find Phil:

• LinkedIn: https://bit.ly/46ku9Rq

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 http://bitly.ws/GFwi

🐦 http://bitly.ws/GFwq

💻 http://bitly.ws/GFwz

Product Agility Podcast

🔗 http://bitly.ws/FdVJ

🐦 http://bitly.ws/FdVT

🤳 http://bitly.ws/FdW9

🎶 http://bitly.ws/FdWj

🎥 http://bitly.ws/FdWy

💻 http://bitly.ws/GFuS

👤 http://bitly.ws/GFvy

Listen & Share On Spotify & iTunes

• Spotify - https://spoti.fi/3XzuzND
• iTunes - https://apple.co/3YvTX8p

Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Transcript

0:00

Hello and welcome to the Agility Podcast. I'm your host, Ben Maynard, and today is a day where we are going to talk about Rd. maps and decision making with a gentleman named Phil Hornby, who big on LinkedIn, big on tournament Rd. maps. He's got a new book which he's working on. I say new book like Phil's got an old book. Phil has a book that he's working on around decision making, which I think is a fantastic topic. So that's why we've chosen Rd. maps and decision making, because Rd. maps I think is what maybe you've heard Phil talk about is what he keynotes about at conferences and decision making will be his thing, which is going to be focusing over the coming years. So Phil, thank you very much for coming on the podcast. It's an absolute delight to have you here. Pleasure being here, Ben. Now, Phil, we've been talking for a long time before this because I drunk too much coffee this morning, having some choice conversations and trying to decide where we start. And I think like with most of the episodes we have, it'd be lovely if we could start with an introduction to yourself, a little bit of history, as if our listeners can get a feel for who you are. Sure. So well, I guess the one way of phrasing is I'm a player turned coach. I'm an ex product person who I figured that I could help more product people by helping them in that kind of step back kind of coaching model. That means I work independently across many organizations, but my background is building products. Like I started as an engineer. I am officially a geek, you know, And when I talk about that, I'm talking about a full stack engineer. And I don't just mean you can do back end and front end, I mean you can design the hardware as well. That's full stack to me. That's what the team that I cut my teeth in could do. And in fact, in that team, there were no product managers, there was no agile. But actually if I look at how modern product teams work, employing agile practices, that's pretty much what we did. Just there was an engineer actually doing all of those different parts. And so kind of I learned through that Crucible and brought that to modern product teams working. And I remember as an OPS manager 1.1 point in my career, the whole point was about creating the process to scale how we worked as an organization to codify those ways of working. Going and looking at the, the waterfall, the Prince two type models, ITIL, the new emerging agile kind of methodologies and saying, OK, there's this kind of a fusion here of how we work. We're kind of already doing a lot of this. We just need to codify what it means for us in our organization. And that's kind of been the hallmark of how I've worked. He's like bringing that I guess the best practice from out in the world, but also looking at that pragmatic step of what works in this organization and. For the last sort of 6 1/2 years, I've been independent helping organizations and and individuals do that as a coach and a trainer. As you say, I'm pretty well known for Rd. mapping. I have a channel called Talking Rd. Maps, which is full of interviews with the good and the great of the product management world in particular. And yeah, I just started writing a book called It Depends, all about making product decisions in context, because context matters in product decisions and we want to drive outcomes. Well said. And just think about what you said there about context, context mattering in decisions. I suppose this is where the argument that things are too theoretical comes from, right? Because the theory is often devoid from the context. And the challenge is how do you apply that theory in the context? And yeah, it depends. It's a lovely title for a book. I am. Yeah. I'm quite taken with that. So I can't wait. What's the timeline you're thinking of to get this out? So the, the timeline is middle of 2025. I want to get it out essentially for conference season in that year. So I've, I've given myself about 12 months from now to do it. I started working a couple of months ago. I've got an outline sketch. I've got the design for kind of roughly how the flow is going to work. There's a set of core principles, a core kind of rubric in terms of how decision making needs to be approached. Now it's the hard work of actually writing words. Yeah, writing them is hard. Well, it's not. I mean, 10, it's quite easy. You could have tried any old shit, couldn't you? But no, Indeed. Right. Say that they are engaging and make sense. That's the art. Yeah. So for example, I'm planning to apply Rob Fitzpatrick's Write Useful Books approach, which basically means there's going to be a chunk of writing in public. I have 90 people in my early readers club already that are going to get access to those first drafts to give me comments, to give me feedback, to help refine it. Because there's no point in me writing in Ivory Tower. I need to kind of get it out there, same as a product. Yeah, go and test those assumptions and refine and iterate on Yeah, that's been been my week has been having these conversations with. Yeah, Jeff got help from Josh Heiden around Lean UX because yeah, I'm I'll be shortly. Yeah, I'm now accredited lean UX trainer. Good figure. So I'm going to be running Lean UX training re listening to that book as I run each morning right now. Oh really? It's a good book, you know, and I think this is one thing I've really learned from Jeff and Josh, the importance of kind of testing those ideas and how you can care about doing it. And as we mentioned before, we started talk about like jargonisation of things, I think, and road mapping and we'll talk about that. Maybe we'll hit on the jargonisation of the term Rd. mapping because I think it means too many. It's been overloaded to a point. But, you know, talking to Jeff and Josh and Josh particularly says the word MVP or the phrase MVP, you know, which is an initialism, not an acronym. An acronym spells a word initialism. It's just letters, unless is a word, which I think is that. Yeah. But MVP just become just such a nonsense term nowadays. It doesn't mean anything practical, which I think for many people is where they are with Rd. maps. I think the road maps have been with a zeitgeist for a while. Everyone was really into then, everyone wanted a road map and no one really changed how they were doing things and ended up just producing a load of old rubbish a lot of the times. And some organisations didn't. And I was turning everyone on the same brush. And I think one thing I'm curious about is, you know, to start off our conversation is I do think that certain people in the agile world have really struggled with Rd. maps and almost failed to see the point in them or create Rd. maps, which maybe don't pass the litmus test. So Phil, why is it do you think that people in the agile space struggle with road map? I think the fundamental core of it is because it's seen as the plan for a plan. It's seen as right. This is the plan. We're going to stick to it. We're going to follow this to the letter. It might be a plan, It might be plan A. But the reality is we know we started working on Plan B yesterday. There's nothing wrong in articulating a direction of travel so long as you're not investing huge amounts of time and effort in that articulation and getting invested and falling into that kind of forget which bias it is, but the bias to basically keep paying into that same thing. It's some cost fallacy to some extent. Really what we're trying to do is cast that vision and on the channel we had like if someone came on and they talked about how he was really, really anti Rd. maps because he knew that things were going to change. The context of the environment was going to change. Yeah, we know that. Everyone who creates a road map knows that. Everyone who looks at a road map knows that as well, even the customer. But often, in particular in B to B, you want to know, I think you have a similar view of the direction of travel, a similar view of the future of where things are going. And so having that road map to articulate that direction of travel is a powerful tool to drive the conversation because a road map's not a plan. A road map is a communication and alignment artefact. It's about us getting on the same page and understanding that we're going this direction and that we're going to steer along the path. We're going to learn things. You're part of the the challenges because they basically end up looking like a Gantt charts. You know they are, which is not a road map. A Gantt chart is a project plan. It shows the activities we're going to do, not the things we're going to actually deliver or heck, the problems we're going to solve. In fact, one of the things I talk about is content maturity on your road map and going from the maturity of saying this is the feature we're going to deliver to or maybe these are the problems we're going to solve. That's only middle face for me of the maturity actually I get. I believe that the most mature level is a mixture of content on your rogram. And that for example, means that in the short term, maybe we'll use the now, next and later concept the short term. Now we know what solutions we're going to ship. We know what the features are. It's not no problem putting those on a road map and communicating it. On the other hand, in the next, well, we don't really know what the solutions are. We haven't done the discovery. In fact, we're really doing the discovery there. So let's put the problems that we're trying to understand on there on the road map. And then in the last column, really we just know the problem space we want to explore in the later. And so that's really exploration and understanding that actually for us maybe in the product team that's easy to think about, but for people outside of the product team, it's quite hard for them to look at. Well, I mean, one column you're telling me features, in another column you're telling me something else and something else. And that makes it really hard. But when you get to that level of maturity and that honesty of we know with certainty here, we are still figuring things out here and we're frankly just going out searching over here, that helps. I mean, there are another aspect to it is that we ask the road map to do too many jobs. And here I am stealing a quote from John Cutler. You know, if you think about it, we ask it to give us certainty about what's coming When we ask it to help us align people, we ask it to show which problems we're solving, which outcomes we're driving, which leave an impact. We're going to deliver All these different jobs. Every stakeholder group, every audience looking at your road map has a different set of jobs. So one, we expect one view to do everything, and two, we expect to do everything for everybody. Reality is, you probably need a different view for each audience because each audience has a cares about different things. Like showing to an exec all the level of detail that you're going to talk about in line with the development team is not going to go very well. On the other hand, showing to a development of the team all the long term strategic goals. For the next five years, also probably not going to go very well. So choosing which level of granularity you're going to present to the different audiences, how are you going to show and tell that story to kind of have that alignment as a team and the sorts of things you put on there? Yeah, Need multiple views. You need to understand that we've got to stop asking you to do every job. Like a release plan with dates on it for particular features is another artifact that sits next to it. We combine them thinking we're being efficient, we're making our lives easier, but instead what we end up doing is making a tool that does job badly instead of one job. Well. The road map shouldn't be with all things to all people. Exactly. It's an articulation of a bunch of decisions or things that we are or decisions that we've either made or thinking of making in the future and we're figuring out. So it'd be run through something. I like what you were saying. Don't get me wrong. I think yeah, it should be all things to all people. It's an articulation of a bunch of decisions. It's an alignment tool. It's something that we could all work upon. It's a conversation start. I'm much like, you know, the, when you go back to before our trial was really shit and but people spoke about user stories and the free seats. You know, the user stories are about having a conversation about talking about actually what's going to confirm that we've done the thing that you wouldn't want it to do, like it's solved your problem. And then actually that's just kind of write an overview of that covert story on a car, right? Rd. maps are similar to that. Let's have a conversation. Let's figure out what we kind of think we need to do along the way. And let's just kind of get it written down somewhere so we've got something we can look at and talk about in the future when it does change. And I think, you know that that thing gets lost. So going back to you, I suppose one of the challenges with a lot of agile environments is that they're not product environments. Not not in the same way that an actual product company that have come from the ground up as a product company with a strong product mindset of good product leadership who are making different kinds of promises to their investors, to their shareholders, to their senior leadership teams. There's a distinct difference between the traditional firm who never had a say, never had had basically grew a tech function and had the business, everything else on one side, and the product company where maybe it's always slightly more harmonious as a whole. And agile really, you know, took hold in those tech functions of organisations where tech was a bolt on and they were just supplying to a demand from the business. Yeah, they're in those types of contexts, you know, we're saying that. The road map should be all today, shouldn't be all things to all people. When you have agile coaches, scrum masters or people working in those agile environments and they're producing Rd. maps, which are just lists of features or Gantt charts. Do you think that's because that's what the environment is demanding of them? And and if so, you know what, how, what can people do to help maybe shift the shift that a little bit? What's a small experiment they could run? Yeah, so, so this great, great question. The well, that's why I talk about content maturity. I also talk about timing maturity for your time on your road map. Because if you try to go from this Gantt chart feature based thing to the all singing, all dancing perfect world in one step, the organization's going to meltdown overnight. So we're going to be pragmatic about how do we take a stepwise approach? Do we, for example, do we change the timing but keep features? You're still going to upset some people. But look, if we keep features but change the timing, maybe we go from a pure timeline, dates to time boxes, maybe quarters, half years, full years, ultimately to more of a time frame viewpoint of now, next and later. Although I'll be straight with you, I don't use now, next and later anymore. I use discover. So deliver, discover and explore. So those kind of activity types that I talked about, because one of the things issues I find with now, next and later, I'm going to sidebar here is it talks to now, we're going to do something else later and we do next and there's something else later. The reality is the things in each of those further columns we are working on right now, we're just doing things on them. So we're delivering something probably and we know the feature in the now column. So why not call it delivery? We've got things in the next column that we are understanding, discovering well, why not call it discovery? Then in the later, which we're exploring to to find those problems and and bigger things. So let's call it exploration instead as an example. So I I tend to shift that nomenclature, but then. So that's that's kind of the timing, shall we say, communication of what's because we know the things that we can explore are going to come out of the organization much later. So that's why it ties into later. But on the same, on the same vein, we change, think about how do we mature that's that content. Now we might stick with features for a very long time until we get to a time frame model and that, but then we might start maturing the time, the content that we're in putting in there. Do we shift to outcomes? And then we've got the debate of what the heck's an outcome? So traditionally people when they talk about an outcome, often they really mean a product outcome. And by that they mean a change of customer behaviour. I may be reducing churn or something like that. That's great as a goal. That's more of an OK R level thing for me. But it, I, I want more detail and in particular, if I'm ever going to share this with a customer, which there's a whole other controversial subject. Do you share Rd. maps with the customer? My answer is yes. By the way, you put putting reduced churn on there. The customer doesn't care. It doesn't inform them about anything. What they want to know is how are you going to help them? How are you going to make their life better? So there's another form of outcomes. So user outcomes jobs to be done. That's what I shift to putting on my road map. I'm going to solve this problem for the customer. I'm going to enable this thing. I'm going to enable them to do something. And by doing that, one, usually my customers are pretty happy because they can see how I'm going to how I'm going to help them. And two, it's specific enough for my organization to know which direction we're going. But what it's not doing is boxing. As in, it's like saying we are going to ship this particular feature. Well, what if we do our discover? We suddenly realise that there's a better way of solving that. As long as we solve the problem, we deliver the user outcome. Who cares? It's what I find really interesting. And I have to admit, me and Lady Good Liz Emma did a live stream a little while ago and it wasn't until this week I realized that we were coming at it from slightly different angles because I was indoctrinated into outcomes, I would say by a guy called Goyko Anzic. I know Goyko. I was with him two weeks ago in in Krakow. There you go, Legendary chat. And he's actually coming on the podcast. He's booked in for August. And I haven't seen Coico for a long, long time. Remember the first big talk I did at a conference I was on at the same time as him? And my case study was a little bit of it was about how I worked with him on something. And I remember going up to him saying like, I can't believe this is my moment and I'm up against you doing your whole South Park gnomes thing, which he does. And that's like, I says shit. And he was like, I'm up. He said I'm up a SEC because I want to come and see your talk. And I was like, that's very nice of you to say and I think it's bullshit and I think you really want to come and see my talk. Regardless, we both got plenty of people. It was OK, but I was introduced to it via spec by example. But then after that really something called impact mapping, Yeah. And when we talk about impact mapping and this is the thing that me and Liz really struggled to tell the tally of square off like I can now do that is that in the outcome of impact mapping is something which will make save or protect the organization's money. And it's actually a thing. And you're saying kind of what are you hopefully going for your target and your break even points. And it's a real tangible thing. It's something you can go to the business and say this there we are going to make, they will protect money because we're doing this and it's something really tangible, right. But then when we talk about the, the actual changes in user behaviour, they're the impacts. Well, not even user behaviour and actor behaviour, because it's more broader than just for users. We're saying anything whose behaviour needs to change in order for us to reach that outcome, or we hypothesize that behaviour needs to change. They're an actor. So that could be another system, it could be a customer, it could be a stakeholder, it could be anything. It could be an operations person, you know, just not only filling in a form differently and it's not not using a fax machine anymore, whatever it might be. But they really impacts them. And when you look at lean UX, for example, which I think is where lots of people have got their understanding of outcomes, the outcome is the change in behaviour. Yeah. And I think it's it's this weird mix and I wonder they wouldn't we look at people will be listening to, but trying to tally it all off. And I think the important thing we're talking about here is like behaviors will have to change in order for us to have an impact on the business. And what say what goes on the road map? Is it the impact on the business? Is it the way we're going to make, say we'll protect money or is it the changes with desired changes or hypothesized changes in user behavior? Or is it the things we're going to produce which then we believe will create that change in behavior like what took what content mix? Like how do you mix that content together? So the answer is yes. Well, it depends. Oh, shut up. You always plug in your book, Phil. I'm tired of it. I'm tired of it. But I mean, every product to my person says that. Like, literally, I say the weekend I announce the title at an event. We were counting how many times people said that phrase. Yeah. Do you know what I mean? Before product people, man, it was consultants. That was the consultancy thing. I think it might have been, oh, I don't know, did most of the quotes about consultancy come from a guy called Jerry Weinberg? I'm, I'm sure I need to go back and consult some books over there. Jerry Weinberg wasn't. If you have listeners, if you haven't checked out any Jerry Weinberg's book, check them out. The he was a phenomenal, I want to say thought leader, but I don't think that there's some justice. He was just he was a fantastic author and an amazing mind. And I do check out Jerry Weinberg's book, particularly The secret, The Secrets of Consulting is a talking about. Yeah, a wonderful book. The law of Raspberry jam came from there, you know, So anyway, Phil, carry on. But yeah, so. So yeah, interesting that that kind of different terminology. I mean, we language can be the thing that breaks is like I've remember having a long debate in the room when I was a product leader of what was a vision, what was a mission and there was almost like a flip from each side of the pond. Like the Americans had it one way around, the Brits had it another way around and that led to a 2 hour debate. It's like, I don't care what we call it, let's focus on the content. Yeah. I mean, so I tend to think of that kind of scale out of thinking lean UX. Jeff and Josh, I kind of used the same language that I tend to use of impact being the business level metric, outcome being the product level, metrical, the change of customer behavior, output being the thing that you ship. Like a feature. I'd like to add on inputs the level below that of like because sometimes you set those as objectives like I. They're not necessarily ideal, but like. I know interview 5 customers a month. It's not what you actually care about, but sometimes it's a great way to build behaviours in the organization and kind of thinking about those. That's kind of the the different levels that you can measure is useful. I would say the anything from thing from the output to the impact can go on a road map and it depends on the audience. Like if I'm presenting to an exec, an impact level metric may well be there because I want to show the business connection if I'm present. If I'm not talking to an exec, then I might just limit it to product level metrics of change of customer behaviour because those are typically the OK Rs that the team have that they're driving towards. But even in the short, but if I'm showing a short term view, maybe the now column, I might have the outputs on there as well. The features we're going to ship because we have certainty at that level below even the outputs of the change of customer behaviour. I want to show the user outcomes coming from the jobs to be done world of this is the thing I'm going to enable a customer to do. It reminds me what you're saying the the classic kind of backlog funnel, which was very popular in the scrum world for a long time, saying that you're your backlog should be like a funnel and you want things to be small enough to kind of fall through the funnel by the point you're going to work on them. So they kind of the very top of the neck of the funnel was when you're going to begin doing the work. And everything above that is quite coarse grain. And this is what I find interesting is it you can flip that on its side. And then you've got often kind of teach people to achieve flow with the work that's coming into their backlog to kind of layout the stages. And like you were saying for a road map, kind of left to right. So let's say it goes on to your backlog and that's how it goes out. What I find interesting about backlogs is it kind of almost reverses that flow because when you think of flow, generally speaking, it's kind of the work goes from left to right and then the further it gets to the right, the closer it is than to get into the customer's hands. Rd. maps are different, actually. The left side, this is stuff that's closer to the customer's hands and the right hand which is furthest away. And I wonder if that creates some kind of cognitive hoops of people to jump through. I don't know, but let me tell you this. Not all Rd. maps need to go left to right either. Get out of here. Yeah. So breaking that cognitive model is actually super powerful. One of my most loved formats is what I call a radio road map. It's concentric circles. Time goes from the middle out to the outside. And I discovered this a couple of years ago as as part of the interviews on the YouTube channel. And at first it was like, oh, I don't quite get that. And then I realized that was its power. It created some friction in understanding, which could have to pause and think to really understand. And that made them understand better. And it's, it's actually turning to now I, I use the phrase, it's on our radar instead of it's on our road map. If I'm using that view because it's kind of that view. And so you have limited space in the middle for the things you're doing now and far more space for the things in the extreme outside because they're on your radar. You're not necessarily doing anything with them or kind of going to do something about all of them, but you're aware of them, for example, if you look at market trends, because that might also go on your radar on your road map, the why that you're doing things, you haven't figured out the how or the what yet. So it's kind of flipping that. And yeah, there's the radial. We also have the crawler. So it looks a bit like a Star Wars kind of start of the movie. You can do road map in that style about left to right, and that's one of the issues I have with the now, next and later road map because there are things in the right, far right hand side. It's the further away from the customer getting it, but it's being worked on and that meant model breaks down. So sometimes I flip that on its side and turn them into swim lanes to communicate the parallel activities. Yeah. I think basically I find, yeah, yeah, I always find it hard to relate to stuff from the far right because it's just so far out of a distance. And I think having things as a a swim lane or, you know, just as a flow, right, So you can see how things are flowing through. I think it's just such a more conducive way. And you were talking about showing the the radar, the circles. I think that. Part of the reason I think it's useful is because it relates something called the ladder of inference. Have you heard of this? Sounds familiar but not coming to mind by by a gentleman called Chris Agris. And I think it was first published in the 5th discipline field book, which I had a dream about the other day. OK figure it's a very cheap book. It's a very good book. But what it talks about ladder inference, which is, you know, we whenever we're taking the world for a lens and we only pick from the pool of observable data, the stuff which we recognize and has meaning to us. But because we're really barely picking the stuff which we recognize, when we see something, we rocket through this ladder of assumptions and beliefs and basically just reconfirm what we already see. It's kind of like confirmation bias. So when you're showing a road map, which is kind of a 123 or something along those lines, which people are familiar with, they're going to look at it, they're going to rocket of ladder of inference. They're only going to pick up the stuff which they think is already true, and then they're going to ignore a lot of the stuff which actually could be really useful to them. So if you show them that same content but in a different structure, they're having to engage the higher functions of their brain to really to understand them what it is they're looking at. And as a consequence, as long as you kind of really get them engaged in this decision making process and the understanding of it, then hopefully they're going to leave a better understanding. So when if we think about this and road maps being a way to have conversations and make decisions. If you were thinking about that decision making process and you're faced with a situation where you have to create a road map or recreate a road map, right? You can choose a context. You like that. How would you see that decision making process from kind of starting from not a lot to having a road map, which people were collectively saying, yeah, OK, this is this is where this is good enough for today. Like what is that process for you? I mean, so for me, decision making always breaks down to three stages. There's getting to the decision making the decision and implementing the decision. And I, I always emphasize the implementing because no matter what decision you think you made in the room, if you leave and do something different, there was a reality of a different decision. And, and that I think most people when they talk about decision making, forget about. So, so I always like to emphasize getting to, I think in this particular example is the key thing. A lot of it comes to down to gathering context, like bringing as much information together as possible, like what is our strategy? What are our objectives, what principles we've got? What market do we play in, where our strengths are, our weaknesses, what's happening externally, what timings out there in the market because there are always cycles and events, What are our technical capabilities, what's our financial runway, what's the size of our team, etc. All that's part of the problem why it's hard because there are so many things that need feeding in. And often it's a lot of that is treated as almost tacit knowledge. You assume it's in someone's head as opposed to explicitly gathering it together to make that decision. If you're making a big decision of a new road map, then you need to actually spend a lot of time on gathering that context. Now, hopefully it's articulated to a fair degree in your strategy, but actually half the time that's just kind of a wall. You haven't got a strategy. There's nothing there that's actually able to inform those choices. Because I think it's Janna Bastow that says a strategy, a road map is a prototype for your strategies. It's really about saying how do we bridge from these big bets, this big direction that we have decided as an organization we're going to take to what we can actually deliver. And so strategy becomes that key part of informing it, which should have been built around an understanding of the market context, etcetera, etcetera. But also then you need to bring in elements of what are we capable of doing technologically and what is net the current state-of-the-art. I think Marty Kagan uses the phrase in ways that are just now possible when he talks about product work. Because the reality is the state-of-the-art technologically moves on. And so the thing you had on your road map for a year down the line, the better way of doing it has suddenly turned up. Like everyone had AI on their road map 3 years out for the last five years, and then all of a sudden a year ago, it's like we need to pull this in. And hopefully the organization were already doing some capability building and exploring what they could do with it. Don't think many were, but hopefully they were. And then you start to be able to say right now this is now possible. We understand what we can do, but that takes time and investment. Too many teams are actually just focused on shipping stuff, not doing so. They're doing the D part of R&D and actually you need that our part to be coming in and inform and bringing the technologies in. A road map is too often treated as just the product managers artifact. It's not the road map is the team's artifact. If it doesn't belong to the team holistically and they don't take ownership of it, it's guaranteed to fail. Like during early days of COVID. I ended up, it's one event I love that I love. I miss lockdown. It's a little bit, but I don't miss though.

Is that the fact that I ended up in hospital at 2: 32:45

00 in the morning with heart problems? Yeah, I don't think I'd missed that. I I missed it was a bit too, because there was a lot more time with my daughter. Yeah. And that was the lovely side of it. But you know what I mean. It was two in the morning. They wanted to find an ambulance to come and get me. They wouldn't let me go on my own because my heart was malfunctioning, basically. And they'd rushed me to hospital. I went in there and got rigged up and got tested and everything else. And they said I had something called sinus arrhythmia, some kind of heart thing, And they asked me some questions and they said, have you been drinking excessively? And I'm like, fuck yeah, because shit's really stressful. I've just started a business and there's a massive global pandemic. Are you drinking lots of coffee? I'm like, oh, yeah, I'm drinking lots of coffee because I'm always hungover and like, so you're feeling quite stressed in me. Yep. Are you exercising at all? I was like, Nope, They're like, you've got to sort that out then, otherwise you're just going to be back in here. I was OK not drinking as much coffee, not drinking as much booze, exercise and more. Always on the road map. They were always a bit further out into the distance, far enough for me not to have to worry about them. But the day I ended up in hospital and it became real was the day I thought, no, actually now this needs to move into my deliver section, my now section, because I can't afford to do that. And I think that when we're looking for psychological aspect of this, this is, I believe, what they would call hyperbolic discounting, which is we will always devalue something which is more valuable the further off it isn't of a distance, the less it is a real problem to solve now. And we'll always value more highly the things which are probably easier and closer to us. So going to the gym doesn't pay off, so I devalue it. It takes a long time of exercising, going to the gym to see the effects that you want to see. So we just give up. And it's much easier for me to be like, Nah, do you know what? I'll just have that glass of glass of vodka. It looks like water. Yeah, it looks like what? No one will know. You know, I'm on a podcast. No one knows what's in the cup. But yeah, but it's true, we will always discount things. I think that's part of the problem with Rd. mapping is that stuff will pop up and stuff will seem urgent and then the decision will be there won't be a decision making process. That's a fire that's burning. That's something we think is more valuable now. This is what the customer has asked for. This is what we've gone off and sold. So let's do that now because that thing we're saying over there, that does not seem as valuable now as just doing this now. And then all of a sudden AI is a real thing. We're like, oh shit, actually we should have really done that too. So let's bring it in now. And then what's the right? The road map is meaningless, right, Because people are just discounting the stuff in the future. Yeah. How do you deal with that churn when you're just kind of stuck in that kind of washing machine of the now and you can't ever seem to get to the stuff that's later? Yeah. I mean, it is one of the classic kind of, you say means of Rd. mapping of, well, when we'll just update the road map, so we'll do the new version. And I advocate for that being like a monthly thing and all they ever do is shift it a month to the right. Yeah, we didn't, we didn't actually do anything that was on it. We've just moved everything was on it to the right. Part of it, part of it comes down to not overloading what we're trying to do now, like actually being honest with ourselves in terms of capacity and what we're focusing on. Part of it comes down to, well, if these things are coming out of left field that we don't expect particular from customers and the and generally from the market, then we are not doing our job right. We're not getting out there and understanding the market. It should be the exception, not the rule that these things come out and derail things. That's the whole reason that products and discovery work exists is to not get, you know, surprised by these things. Yes, there are going to be Black Swan events, You know, COVID open, AI launching to an extent. Maybe it's not Black Swan because it's not so necessary, so negative, but it's an exceptional event that was hard to predict. And and so they're always going to be things like that. And we've got to have the ability to react and respond and change things, but getting ahead of ourselves and actually really genuine, if something is on that has made it onto that road map, it should be something that we absolutely believe is valuable. If we absolutely believe is valuable, it should be tied into the objectives that we have as an organization. And if we're then not achieving those objectives or if we're not delivering it and still achieving those objectives, why was it there? And if we're if we're not achieving them, then we've got to have a hard conversation with ourselves about we're not doing the right things. We're we're making poor priority calls. I mean, it's interesting. I've got a lot of conversations about decision making obviously happening at the moment. And a lot of the time they end up going down just the prioritization path. I start asking myself, it's like for me, decision making is a much broader church, but if people limited decisions to just priorities of should I do X or Y or should I just do X or should I not do X or should I do X? And I think there's a much bigger perspective of what is our overall direction, our strategy, what are the goals that we're going to measure ourselves by? And then did we make good decisions? In fact, that's came with a secret fourth stage to to decision making. That's only in the only in the conclusion, it's reviewing the decision quality like did it actually did we make a good choice? And if we didn't, then how do we improve our decision making going forwards? How do we make better choices? Yes, there will be times when you're going to take that deal and implement that feature. In fact, my favorite model there is radical dots, radical product thinking where you you're thinking about the survivability versus the vision. Like sometimes you're going to take a compromise on your vision because you need the cash to keep going or for some other reason. Like survivability in your organization might be getting to the next funding round and looking attractive. And therefore being profitable as opposed to necessarily needing the cash to survive per SE. And so making that choice and that trade off is super powerful and it needs to happen. You know, I'm working with an Ed tech company at the moment. I'm sure if Harvard turned up and says we need this feature, they they do it. But there's a very good reason, you know, it's give them a lighthouse customer that would, you know, then help them sell more deals and, you know, focus on their core and they'd probably pay them a pretty penny as well. It's got lots of positives. So it's just this hard. That's the reason why public work is hard because we're constantly making all those choices and it the expectation that you can foresee them all is in is, you know, is never going to work. And I know that that's back to that first question. That's part of the root of why many people from the agile community say, well, just don't bother wasting your time on it. The thing is, I don't find that road maps are a huge amount of time. They're an articulation of our direction of travel. And if I spend more than half an hour a month on a road map as a product person, I feel I'm doing something wrong because the decisions that ultimately create it are things I need to make throughout the month anyway. Yeah. Do you know what makes it hard? I think for people? And by the day I get to go out to my agile friends here who are working in these tech organizations that are trying to be more product like. Is that if you're in the in culture that predominantly cares about velocity and output, then Rd. mapping will take a long time and it will never be right and it will just be a list of what you're delivering and when. I think Rd. mapping is infinitely easier if we're able to say next six weeks, this is the impact slash business outcome we're trying to achieve. Are the things that we are doing getting us closer to that or? Not closer to that. So that's my, my, my, so my wife was just no worries. Here's two spicy tips on that one. Well, part of that is because Agile has been reduced to a delivery mechanism when it's so much more than that. And as a product person, not a pure agilist, I know that its goal is to learn quickly, deliver quickly, but deliver the right thing quickly. And we seem to have lost that aspect. We focus on the output and then there's the other aspect. Product teams seem to get held to this let's ship X on the on YD and it's an unfair sort of measure and it's usually the sales team are the ones who are giving you hassle to make sure you do that you don't hold sales to the yardstick. We say to sales sell X amount of products in this period of time. I drive this outcome in this amount by this date. We're just asking for the same thing. Give us an outcome to drive hold us to that instead of you know the the challenge I sometimes give to the sales organization when they start pushing for a feature on a date is I will do that if you'll guarantee you'll you'll close this particular deal on this particular date. If you want to be held to the if you want comparability, you want to be held to the same standard. Cool. If you'll work the same way, then I will, But how about instead we are both recognize that the outcome is the thing that matters. Let's hold ourselves to that standard. And that's the thing I think the alignment on that outcome is hard when to deal with the necessary or perhaps unnecessary complexity in your organization. If you've broken products or services or whatever, it may be down to nice, easy to manage pieces and as a consequence there's no focus. And as a consequence there's really not so many trying to bring it together. And as a consequence, sales can go off and sell what they like to who they like in whatever way they like. Because you're bringing a road map together. When you are kind of broken down in that way and add insult to injury, things are very output focused, creating a holistic road map which is really fixed on the right outcomes of the business. Just isn't possible, I don't think. And this is the work we're doing, me and the friend of mine, Saloni, on the product operating product, operating engagement models. We agree with you saying it's not possible. I'm just going to say it's hard. Yeah, it depends what scale like it's not possible as things are like. I think that I. Yeah, I would say that at least based on my experience, like when you have things that are broken down into little pieces which are easy to manage, invariably what that means is that they're going to lose customer focus. So they're going to be more technically oriented and people are going to be looking on going to delivering the output because they want the output to deliver. And I think that the culture I'm going to be, but maybe it's not impossible, maybe it is hard, but like it is. I think what you're talking about is one of the dysfunctions that's there of the assumption. We try and reduce knowledge work like developing products to a tailorist model of production. So someone at the top breaks it down, works out exactly what to deliver into all these things. Then we get down to the bottom and there we have the features to ship for the team as opposed to enabling descaling the work to to the team is driving the outcome instead of someone at the top deciding this is how we're going to deliver that outcome. Yeah, but this is a Taylorism is a choice, right? It's a perception. It's an easy one, but this is what, you know, Peter Sengi wrote about at length in the 5th discipline as as humans, in order to wrap our heads around things, we'll always break it down. You know, a gentleman called Andrew Kakapazi has spent the last 25 years researching board behaviour and organizational behaviour and written ideas. It's something insane about that book. 20 odd books are on the topic, you know, and he will say, and I think, but I agree with him, you're always going to have silos. We're always going to have to break things down. The question isn't, should we not break them down? The question is what mindset can we use to break them down? And then you're right, that tailorist approach when we're looking at, when we're striving for best practice, when we're looking for efficiency, like we'll learn that and we'll do things basically what makes sense. And I think one of the challenges is that the thing that makes sense to people, well, let me rephrase that a little bit. The, the thing the people that are charged with then how to break things down are the people in the more technology focused way. And the way that it makes sense for technology people to break things down by it's by the technical architecture, not by the customer need, customer demand, but trends. And then we end up in this situation where it's really easy to break down the tech by the architecture and then have lots of handoffs and lots of small little focused things which are just like getting the output done rather than a much more healthier ways. Actually we'll know what other the customer, what are our markets, what do our customers want, what binds them together. And that's design organization in the customer perspective, not in the technical perspective. Yeah, well, I mean, we're, I know we were talking about team topologies before we came on and like we're getting into that space and things like Conway's Law and stuff like that. And I remember a client sort of shift talking at length about how they were doing a reverse Conway move manoeuvre to kind of reorganize their structure. And then what I saw was a very component oriented structure. It's like actually you've you've just changed trying to change the lines of the components. They're not actually breaking them. Not putting that customer centric overview. Yeah. But let's just let's just come back a second to something we said earlier of we're talking about your people wanting those outcomes or their outputs, particular sales team. One of the kind of successful ways I've found to break that is. Actually step back a second. What they're really looking for is something to talk about with the customer to go in and have the conversation that enables them to have to win a deal because ultimately that's where they exist. Well, usually that's because we, we talk, we've for so many years launched features. So we go and talk about how we've got this feature this this is their our excuse to go and talk to a customer. So that focuses everything on the outputs. Well, there's another way. So that leads to a launch, which is, you know, feature centric. The the alternative way is to instead launch maybe a little later, but be talking about the benefits. So going through like EAP programs, LE access programs and really validating that it's delivering the value. And then the message isn't we've just delivered this, the messages have all this value today. So you can get these out benefits today. It slows things down a little bit as you make the transition because you've got to move from the feature I'll ship today to now, OK, the validated benefit they're going to get a little bit later. But once you stitch, you make that switch, you've got more powerful marketing message, you've got an easier message for them to go and they're less focused about getting the feature. It's like, what value can I tell them they're going to get? All of a sudden you're into the problem solving the problems for customers and that's the enabler for the conversation and that can help flip that conversation with the sales team as well for that push for outputs. I agree, man. I think this is something which, you know, I think I mentioned Jeff and Josh a lot because I spent the week of them, but you know, they've been banging about it's for since day one. You know, the respond element of what we do. Being able to look at what's gone out and validate or explore and then be able to make decisions based upon it was a hypothesis. How correct, how close were we? What have we now discovered that respond element? You know, I think it was always supposed to have been there, but I think people just got into this idea that it's about delivery. And unless it's get it delivered, when actually it's about, sure, it's about kind of delivering it, which I think it's a weird one like a postman. But then also then how do you respond? Yeah. How do you know that they've opened the letter, They've read the letter. What do they think of the letter? Was it what they wanted? Was it useful? You know, and that whole element, you know, that is another episode. Maybe we can talk about another time field, because I mean our time is up unfortunately. I'm just going to say you keep, you mentioned Jeff and Josh a few times. You mentioned your lean UX. My absolute favorite book for all for product people to read is actually their other books Sense and Respond. I recommend that to everybody from a mindset perspective about product work. And nice, I've got it open here. Actually, it's on my my tabs of things to read. Yeah, I mean, Jeff and Josh are launching Sense and respond learning and they're going to be doing much more about their their books and how people learn about their books. So yeah, people do check out Sense and respond by Jeff Got Health and Josh Seiden on recommendation of Phil. And if you like it, let Phil know on LinkedIn. If you don't like it, let Phil know on LinkedIn. Or do you know, if you just want to talk to Phil and ask him any questions about anything that we've spoken about, then Phil, they can contact you on LinkedIn. I understand. Absolutely. Yeah. Phil, thank you very much for taking this time. And it's lovely Friday morning to talk to me. You're in Sheffield in the UK. I'm in the southeast, so there's a a big geographical distance, but over the last hour, 50 odd minutes recording this and beforehand, I feel like I got to know you a little bit and it's been lovely. So thank you very much taking this time, been a pleasure. Have you got any other places and LinkedIn you want to push people towards to learn more about you? I mean, if people want to try talking Rd. maps.com, then that would be a great place to check out the podcast and all the stuff on road mapping. Alternatively, if they're interested in the book and maybe want to join the early reader program, they can go to the IT depends book.com and there's a sign up link there. Awesome. Well there, we'll do our best to get those links in the show notes. And yeah, people do check out both of those websites. I think you feel you think you're on a great thread here with the decision making element and like I can't wait to learn more. Say thank you very much for and everyone thank you for listening. Do let us know what you thought of this episode or any previous episodes on LinkedIn or TikTok. If you're going to go on TikTok, make sure you put really inflammatory comment because that's what people seem to enjoy doing. But at least do that aspect. Like what you think and what you like and loathe about this podcast is super important to me. So please do let me know. Phil, thank you very much for coming on everyone. Thank you very much for listening. This is the Product Agility podcast. Thanks everyone, make some good decisions.