Can a roadmap connect the dots to the outcomes your leaders want? | Jeff Gothelf

In episode 42 of Talking Roadmaps, Jeff Gothelf and Phil Hornby discuss the critical role of roadmaps in aligning product development with desired business outcomes. Jeff shares insights on creating effective roadmaps, bridging gaps between teams, and fostering a culture that prioritizes customer-centric design and agile methodologies. The conversation also touches on common pitfalls in roadmapping and strategies to overcome them.

Jeff helps organizations build better products and executives build the cultures that build better products. He is the co-author of the award-winning book Lean UX (now in it’s 3rd edition) and the Harvard Business Review Press book Sense & Respond.

Starting off as a software designer, Jeff now works as a coach, consultant and keynote speaker helping companies bridge the gaps between business agility, digital transformation, product management and human-centred design.

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

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

Can a roadmap connect the dots to the outcomes your leaders want? | Jeff Gothelf

Phil Hornby and Jeff Gothelf

In the next episode we are talking to Donna Lichaw, Executive Coach. So watch out for Season 1 - Episode 43!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about the good, the bad, and the ugly, and everything about roadmapping. Today, I'm joined by Jeff Gothelf. Jeff, I'm sure people don't need an introduction, but give us one anyway.

  - Sure, Phil, thanks so much for having me. Jeff Gothelf, I am a former UX designer and product manager and leader, product leader and team leader, a bit of an entrepreneur. Over the years, I've written a few books with Josh Seiden, usually, called "Lean UX," "Sense and Respond." Phil's favourite, as I now know, "Forever Employable," and Josh Seiden and I are working on our third book together called "Who Does What By How Much," which is a book about objectives and key results. And we're super excited to have that coming out later this year, I'm sorry, early next year in March of 2024. And these days, I work as a public speaker and as a trainer and a coach, typically, for large organisations dealing with building a product management practise, integrating design product and agile. And then really working on OKRs a lot these days as well.

  - If you're enjoying the channel, subscribe, hit the Bell, and give us a, like, and I'm sure we're gonna bring an OKR, an outcome of output, outputs-oriented slant to the conversation here. Let's just go straight to it. What's the purpose of a roadmap in your opinion?

  - That's really interesting because, you know, the interesting part about that is that there is a sort of like the original purpose of a roadmap, and then I think there's what it should be today, right? So if we think about it from the original purpose, right, I think the original purpose of a roadmap was to communicate with some level of real or fake confidence, what we're building and when it will go live. And that way, we can set expectations with customers and with the market and with our sales organisation, et cetera, about the features that our product and services we're going to have. Realistically today, I think the purpose of a roadmap is to communicate intent, it's to communicate direction, and it's to communicate the, in many ways, I think the corporate strategy for the upcoming time period, right, six months, 12 months, et cetera. So strategically for the next 12 months, we're focused on increasing market share in Europe. Okay, so that's what the roadmap theme, is themed around that. And then to do that, we're going to focus on, you know, increasing our presence in Southern Europe, in Spain, and Portugal, and a little bit in Eastern Europe as well. And then, using those themes to put forward a series of potential hypotheses about what you might build to do that. But the commitment is to those themes and to those goals rather than to a fixed set of features, okay?

  - So yeah, I totally agree. That tool or roadmap being about alignment and kind of the key themes as opposed to a commitment to when we're doing things is so, so, so much the way the model roadmaps. I wonder though, if we're talking about themes, we're talking about direction, who are we talking about that with? What's the audience?

  - The audience for the roadmap? I think the audience for roadmap is both. It, well, if I think about it for five more seconds, it seems to me that an audience for the roadmap is both internal and external. It's both up and down and out as well, right? So I think in the most tactical terms, it's something that we share with the team, the team that's working on these themes and these strategic goals. I think it's a tool for communicating up to leadership and stakeholders, clients perhaps, about what we're planning to do and where we're headed and how we think we're going to get there. I think it's an out or kind of a sideways communication tool to sales and marketing to say, "This is our focus, here's where we think we're headed, these are the problems that we're solving for," and so as you're out there selling and marketing, this is the pitch. The pitch is, "We're solving this user problem. We're making this easier, this more delightful," or whatever it is. And I think ultimately, there is an external communication component to this as well, right? To the markets, to our competition, to our shareholders, to whoever's paying attention to what we're doing that says, "This is where we're headed in the coming year, 18 months, whatever it is as well." So, it does have to carry a lot of weight, I think, as a communication tool. I'd argue that perhaps you don't have to show everything to everybody all the time, right? There's probably layers of a roadmap that you can reveal or hide, depending on the audience. But as a document, it definitely carries a lot of weight.

  - I think it's really interesting what you made, the point you made there, Jeff, about not necessarily showing the same thing to everyone at the same time or every time. Now, I wonder, as someone who kind of definitely is a promoter of outcomes over outputs, I'm guessing that might change what we put onto our roadmap as well. What are we putting on the roadmap?

  - Yeah, and so look, for me, you know, again, I think what people expect to see is we are building the mobile app, and the mobile app will be done on June 30th, and it will be blue and it will do these 10 things. Realistically, what I just said, as generic as it was, is filled with a lot of risk. And putting that on a roadmap, certainly lends some confidence and predictability to what the team is doing, but it doesn't necessarily lend any confidence to whether or not we're solving a real problem for a real customer in a meaningful way if we're delivering any value to our end users and to the company. And so, the things that I would love to see that I like to see on roadmaps are these strategic themes, right? So, essentially, they end up being objectives, right? So qualitative goals that are strategic and important to the team and support the higher purpose of the organisation, right? So, if you're on the authentication team, right, our strategic goal for 2024, the objective for the roadmap is simplicity and user self-service, something like that, right, that those, that's kind of like our strategic goal. You could write that as an objective statement and make that pretty clear about the direction that the team is heading in. I then would love to see on a, we'll say, quarterly basis because quarters are the most common, but if they don't work in your industry, you know, use the cycle time, that makes sense. But on a quarterly basis, I'd love to see a team-wide commitment to a specific set of key results. So behaviour changes, outcomes in the target audience that we're serving. So how do we know that we're building a more simple and easier to self-service authentication offering for our product? Well, we want to see a reduction by 90% of the number of people calling customer service to, who can't sign in, and a 50% reduction in password retrieval from the website itself, okay? Right, that's what I'd like to see sort of at the top of every roadmap. And then, maybe the KRs change over time. We think we can hit, you know, we can hit these first KRs in the first couple of quarters, and then in the third and fourth quarter we think we might hit. We might work on some other behaviours that are less of a focus right now, but may become more important in the future. And then the final thing I'd love to see, well, there's actually two more things I'd love to see on the roadmap. One are the hypotheses that you believe as a team, will help you achieve those behaviour changes. And in addition to those hypotheses, I'd like to see the questions, the doubts, the risks that you have as a team that might challenge your success in each quarter as well, right? So we've got strategic theme, we've got the key results, we've got a list of hypotheses, and then a set of questions or risks that say, "Look, we think that building one click Authentica or Magic Link, right, What is it that Slack does, right?" Magic Link Authentication is gonna help. That's our hypothesis, right, but the risks are that we're catering to a very young audience that doesn't use email. So we have to make sure that we deliver that link most successfully. Like how to, we have to figure out how to most successfully deliver that link, right? That's a question that I'd like to see in that. The interesting part about that, so those are the components right? Now, one more thing about that. The interesting part about those components is that in the immediate subsequent timeframe, so this quarter and maybe the next one, you can make a set of reasonable guesses about what those hypotheses and questions should be. We have evidence, we've got a backlog, we've got a sense of what's important right now as you start to look further out in time, three quarters from now, four quarters from now, the number of guesses, which is what we're doing, right? We're guessing, you know, let's be super clear, right? The number of guesses that we have about what we will be working on in nine months, in six months, in 12 months should reduce significantly. Because the reality is we don't know, right, that the level of confidence that we have in our guesses looking out six, nine, and 12 months is significantly lower than the level of confidence we have in the guesses that we would work on over the next six months. And so, I would expect to see fewer and fewer guesses, fewer hypotheses as we move forward in time. And what I would expect to see with these teams is checking in on a regular basis, and then asking what have we learned? How are we tracking towards our key results? Does our direction still makes sense? What are we gonna continue to work on? What are we not going to work on? What new things have we discovered that we should work on? And then sort of that confident planning window shifts forward a quarter, right? So let's say it encompasses about two quarters, it shifts forward a quarter, and then we work, and then we shift forward a quarter. So the roadmap is a living document and all those elements that I described-

  - Now, it's really interesting. There's a couple of things I'd love to unpack there, Jeff, because I guess the first one is it felt very internal-centric. I'm not sure, would I share that view with the hypotheses, with the risks with a client?

  - Well, so, you know, as I mentioned earlier, we don't have to reveal everything to everybody, right? I think we definitely want, like, if we're communicating externally, I think we definitely wanna reveal the sort of the objective, the strategic objective that we're working towards and the problems that we're solving. Maybe we don't want to get into specific numbers. Like, we know that we're getting a lot of calls about not being able to sign in to our website, right? And so, instead of saying, "Look, we get 15,000 calls a day, we wanna reduce that by 90%," we're gonna say, "Look, one of our main focuses is making our experience the smoothest to onboard and to sign in. And so, that's, our focus is really reducing any friction for getting into the system, right? Something along those lines, that's the same thing, just worded for an external audience. The risks and the doubts and the hypotheses. I don't think those need to be, those are important for public consumption. Yeah, so I think the things that you reveal differ by audience.

  - Yeah, almost the rephrasing you went to there is often where I go for the customer problem or the other use of the word outcome as a user outcome or a job to be done that we might put on the roadmap because we take the solution away, but we say what, how we wanna help the customer.

  - Exactly, like people keep trying to sign into our system and we wanna make that as easy as possible.

  - And I guess I can agree, but also disagree, 'agree a little bit with the how you have less in the long term. My assumption is we've probably got a lot of guesses in the long term because there's a lot more uncertainty. The question is whether we should write them down.

  - You know, there's no shortage of ideas, right? Everyone has ideas, a lot of ideas, and if we were going to ask a team to fill out their roadmap completely with their ideas, they would, right? And I don't think they'd have any issues doing it. It's a lie, right? It's, that's the, like, let's... And I don't feel like we should be putting our folks in a position where they have to simply manufacture stuff solely to complete, to make a document appear complete. Yeah. Just as a, I'll tell you a quick story. Years ago, I had a friend who worked at a hardware startup that got acquired by a big Korean tech company that does lots of other things.

  - I wonder who they might be.

  - And, you know, and they were like a 33, right, exactly. Let's not name names. But they were like a 35-person startup, and they worked pretty, you know, in a very lean way, in a very agile way. You know, they had documentation, but they communicated very well with each other because they were relatively small company, they were nimbling. When they got acquired, there was this demand for filling out the documents, fill out the roadmaps, fill out the budgets, fill out these presentations so that we can distribute them broadly across the organisation. And the reality is that the company that got acquired, they didn't, A, they didn't wanna do the work. But B, they didn't really have the answers for these folks, but not doing it wasn't an option. So, they just filled it out, right, for the sake of filling it out. My friend who worked there described it, you know how like in the old Westerns and old Western movies, like there was the facade of the town, right? There was like, it looked like the storefront to the saloon or, you know, the Inn or whatever it was. But behind it, there was nothing. That's what that stuff was, right? They just filled it out for the sake of filling it out because somebody wanted to see it filled out. But the content was a lie. And I think forcing our teams to do that today without clear evidence that this is something they should be doing and that it's currently relevant and important to be doing, is forcing them to lie or to make stuff up that inevitably is going to change in the future, and we're going to put them in an uncomfortable position in the future that says, "Yeah, yeah, yeah, I know we told you six months ago we were gonna build all this stuff, right, but now we have to change that," which is an equally uncomfortable position to be in.

  - Yeah, I think that reminds me of the quote from David Cansell, "If I give you what I promised you six months ago, then either it's not what you wanted anymore, or I lied to you 'cause I did delivered something else." And I think that that's one of the biggest challenges with roadmaps. I tend to think of it as Plan A, and I started working on Plan B yesterday. And if you get it, then most people, then you are, and you're okay with that reality, then it works. But the challenge becomes when people coming from more traditional way of working or mindset, don't understand that and take it as a committed plan.

  - Look, this is, and this is the issue, right? The issue is that folks who make digital products and services are battling against a century of historical inertia about how to build and optimise a business. That century of thought leadership of experience comes from manufacturing. It comes from the industrial era. And if you're building a factory and you're trying to maximise the efficiency of that factory, yes, let's use that 100 years of knowledge and get better at it. But the thing that I try to impress upon the folks that I work with, the leaders that I work with, the teams that I work with, it's, you know, and it's kind of like, it's telling them something they already know, but when it's reflected back to them, it seems a bit more obvious. And it's this, we work particularly, you know, we... Look, I've been building digital products for 25 years, but particularly in the last decade, right? The fundamental nature of digital products and services changed, right? It changed from building static versions of the product, right, and shipping that static version to continuous improvement, continuous learning, continuous iteration, right, DevOps, basically, DevOps gave us the capability to continuously work on these products. And why it's fundamental is because the stuff that we work on today, technically never ends. We are building infinitely continuous systems. And if that sounds daunting or stupid or scary, just ask yourself the question, right? When is Google done? Right, like, this is like, everybody. And that's everybody's reaction, right? And like, when is Netflix done, right? When is Amazon done? Like, you think about like the, you know, the digitally native leaders in our space right now, this idea that they're done doesn't make any sense. And that's true in every organisation that builds software, because we're building these continuous systems, the pace with which we can update those systems is insane.

  - Yeah, these days, literally, it's as fast as you want, right? That's the answer these days. As fast as you would like to update the system, you can. And so what that means is that the making of a thing, right, the deployment of the feature is a non-event. It's not the thing that we celebrate anymore because it's a thing that we do every sprint, every week, every day, every hour, depending on where you work, right? And so, we need a different measure of success, of putting a feature in a roadmap. If you're Amazon and you're shipping code to production every second, which they do, how do you maintain that roadmap, right? It's, it's insane. And so this idea of saying, "Look," and so, it's fundamentally changing what we qualify as value, right? The value is we made the authentication process easier, and we know that because people are authenticating with less issues and we see that in their behaviour rather than Magic Link or one click Sign On, or, you know, thumbprint scanner or whatever.

  - I found in the last couple of years since Theresa published around the Opportunity Solution Tree, pulling that out to kind of, sure, well, here's the outcome we're running towards. Here's our understanding of the problem space, and here's the, let's list all the 10,000 ideas you've got for solutions. Great. Now let's go and prove which one makes sense to us.

  - Yeah, I mean, look, I mean, again, like we said a second ago, right? Everyone has ideas. You have ideas, I have ideas, our bosses have ideas, marketing guaranteed, has ideas, sales has ideas, right? Your partner at home has an idea if you work on a B or C product, right? Whose idea is best, right? In the past it was, well, it was the person who shouted the loudest or got paid the most, right? Their idea was best, or not, but whatever, we built it, right? We have the tools, the capabilities and the responsibility frankly, to find out which is the best combination of code, copy, and design that's gonna solve this user problem that we're focused on now.

  - And I Love the fact you brought in the copy in there as well, it's not just the tech. The previous guest on the show was April Dunford, and we were talking about her new book "Sales Pitch" as well, and very much, if everything's not integrated when we're talking about the products, too much of fine products these days are driven into the tech space and, mm, like our, the need to really look holistically at how we communicating about the product, not just building new stuff. Sometimes the right thing to do is just market it differently.

  - 100%, I always joke, I teach a lot of classes and I teach them all on Zoom these days, which is fantastic, by the way. As people line up in the waiting room in Zoom to let them in, the button, the little text link that you click says Admit All, right, which makes sense in English, but it also means other things. Like, I'm gonna admit everything to these people. Like what? Right? Like, it's copy like that, right? It makes you think like, was this the right, was this the best choice? You know, I can't think of a better option, but in any case, copy is crucial to the success of your products.

  - Now you started to talk a little there about who makes the decision. So I guess circling back, who owns the roadmap? Who maintains it? Who are the people who are kinda looking after this thing?

  - I think it's a product manager. I don't think we need to, well, my opinion is, I don't think we need to... I don't think it requires a heavy debate. I think the product roadmap is the responsibility of the product manager. Now that said, they shouldn't work in a vacuum. They need to collaborate with design and engineering and marketing and sales and strategy and whoever else, right? But the owner of the document is the product manager, the, you know, the person responsible for helping the team navigate the uncertainty of digital product development.

  - Now, we talked a little bit earlier about you brought objectives into the roadmap. What about vision and strategy? How did they link in?

  - So look, I'm gonna talk about strategy. I'm less clear on vision, you know, well, if we think about it, right? So, I guess vision is sort of like the long-term plan, not plan, but the long-term sort of approach for the business. Like, organise the world's data or whatever it was for Google, right? That was their vision for a while. Strategy, I think about a lot, and I teach strategy to a lot of the teams that I work with, product strategy. And strategy, to me, it's important that my favourite article description of "Strategy," comes from Roger Martin, and it's his 2014 Harvard Business Review piece called "The Big Lie of Strategic Planning." If you haven't read it, you should, it's not that long, but I'll give you the summary. Now, Martin says, "Strategy is a hypothesis. Strategy is not a plan, strategy revenue is not strategy. And basically, it boils down to being a explicit about the logic in our strategic direction. So how will we know we're achieving the strategy? And answering two key questions, where will you play? And how will you win? Where will you play being so your target audience, your target market, the geographic zone, the what, you know, kind of we're targeting 18 to 34-year-old male gamers, you know, who love first-person shooters, right? That's where we'll play. And how will you win, is your competitive advantage, your unique value proposition? How you believe you're going to win this part of the market? And maybe it's a marketing approach, maybe it's a product approach, or a service approach, or a pricing approach or whatever it is, right? But that essentially forms the basis for your strategic hypothesis. And as an organisation, you can start to base your organizational-level goals or OKRs on that strategy. You need to have that strategy if you want alignment across the organisation. And so, at the organisational level, once you've got a strategic direction, formulating objectives, and key results or goals out of that is fairly easy. The strategic aspect of it, the sort of the, where will you play and how will you win becomes your objective, right? We're going to become the, you know, we're gonna... Our goal is to produce the most fun first-person shooters for, you know, for 18 34-year-old male gamers. And then the key results are going to be the behaviour changer that we're looking for to tell us that we've done that. Now, to answer your question about where does that fit into the roadmap, I think at a corporate level, right? If we're looking kind of a high-level roadmap for the organisation that sits right at the top, right? The objective is that strategic theme for the roadmap that we talked about before. And then the key results line up on a quarterly basis about maybe it's acquiring new players and getting them to try it, and then ultimately paying for it and telling their friends that type of thing. I think if you work lower down in the organisation, you should be able to tell a compelling story as the product manager who owns your team's roadmaps. Let's come back to my example of authentication. As the product manager for the authentication team, you could have a strategy for your portion of the customer journey that you work on, but you have to be able to tell a compelling story that connects your strategic direction with the corporate strategy, right? How does this support the higher objective as an organisation? And I think that if you can do that successfully, then you're aligning your team, and then you're aligned with the organisation. And that should please your bosses, I think is as you move forward. But that's where I think this comes into the roadmap conversation is if you are, and I think like most folks not in charge of the entire thing, then you should be able to tell a story about how the direction, the strategic direction that you're taking, you're taking your team in maps to the overall goal, the overall strategic goal.

  - So totally agree. I was working with a scale-up until very recently as we were pulling together their company-level strategy, their company, or the product-level strategy, and then each of the individual team strategies, and it's like the key message to what all the product managers was, show that direct lineup. How are you aligning with the, you know, the high-level themes from the corporate strategy, how are you aligning with the high-level, with the top-level OKRs? How are you aligning also with your, the set of product principles that we put in place, kind of, if you can box in what you are doing on those things and show that it, that shows that you're aligned with the overall company's thinking.

  - Look, and I think it's crucial, right, because if I'm your boss, that's the first question I'm asking you, right? Why are you doing this work? Like, why are you proposing to do this work, Right? And what I want to hear is how you connect the dots, right? That's the thing that I care about because somebody's gonna come to me, I'm not the CEO, right? My boss is gonna come to me, and say, "Hey, Jeff, what are your teams working on?" Yeah, and I'll say, "Well, you know, Phil's team is building this." "Okay, why?" "Well, because Phil told me that if they fix this, it's a leading indicator for activating dormant users, right? People who've signed up and left and never came back. And since that's our goal is not so much active acquiring new customers, but activating dormant customers. That's why Phil's team is doing that," right? That makes me as your boss look like a hero. And that's, then I like you.

  - And what I find is if you can show that when you're having the strategic conversation and the road roadmapping conversation, then the day-to-day conversations become so much easier because they just trust that you're making aligned decisions.

  - Yeah, and look, you build your credibility, right? We all talk about product managers and how everybody likes to believe that product managers lead with authority. They don't, right? Generally speaking, most product managers don't have the authority to tell anybody what to do, much less hire or fire people or any of those things, right? We lead with influence, and the way that we influence is with compelling storytelling, right? And if you can tell a compelling story that says, "We are doing this work because it's a leading indicator for the overall goal, right, and this is how we plan on achieving that," you're gonna take your team along with you, your stakeholders, your clients, et cetera, and it's powerful.

  - And I think, so taking that storytelling element, I always think that a visual is a powerful thing to go with storytelling. So how do you like to visualise a roadmap?

  - To me, there are, you know, the... I don't think we're gonna get away from a linear time-based approach to the roadmap. I'm not sure that we should, right? I think that is a visualisation that everybody expects, is comfortable with. I'm open to new ideas, but I think for now, I think that it makes sense as long as the contents of it are realistic and tied to measurable key results. And that we believe that this thing isn't written in stone. And so, whatever the tool is that you use to create the roadmap should make it easy to update, should make it easy to change, should make it, you know, back in the day, and this is a long time ago, we used to make these roadmaps and customer journey maps and all this stuff, and then we'd get a plotter, right? One of those large-scale printers, you know, and then we'd print these beautiful things out and put 'em up on the wall. And in that state, those deliverables took a long time to make. And they were really nice, right? They were really nice looking and nobody wanted to mess with 'em, nobody wanted to print another one of those or change those things. And so it truly hindered our ability to pivot and to adjust course based on what we're learning. And so whatever tool you're using to visualise and share your roadmap, it should be collaborative, it should be simple to update it. There should be no barrier to improving the roadmap based on new information. And so, we've talked about what goes in it, you know, beyond that, use the tool that makes sense for you.

  - Let's go kind of big hitters best-practicing roadmapping. If you had to kinda put that into a short statement.

  - The biggest thing you can do is frame your ideas, the things that you wanna make as hypotheses, because hypotheses reflect the real-world doubt that is inherent in the work that we do. We like to speak very confidently and we're often pushed to speak confident. What are you building, right, what's it gonna do, how's it gonna do it? If you deliver the responses to that as a hypothesis, you are by default, injecting doubt into that conversation, right? Instead of saying, "We are going to build a mobile app and it will be blue, and it will do these three things and we will ship it by Friday." We say, "We believe that will increase the number of dormant users, like the conversion of dormant to active user, you know, by 30%." If, you know, dormant users are incentivized to come back in some, you know, to the service with new features that this feature that connects it with the tool that they already use. Whatever it is, I'm struggling to come up with it, but what we're doing there is, we're not saying, "We are absolutely building this and it will do it this way," we're saying, "We believe we should build this thing because we think it's going to change this behaviour." And so the definition of done, the measure of success is not making the thing anymore, it's changing the behaviour. So it leaves the door open, which inevitably we're gonna have to walk through 'cause we're gonna be wrong to some extent for us to come back and say, "I know we told you we're gonna build that thing, right? It turns out though, that the implementation that we were thinking about isn't going to work, or the exact design approach that we took wasn't working as well as we thought, here's what we're trying next, right?" And so that, to me, is the roadmap, best practise is anything you put on a roadmap should be phrased as a hypothesis.

  - Interesting, yeah, and going back to that point about confidence, I think many product managers are almost hired because they are able to communicate in a way that is huge confidence, which then leads to that desire for them to continue sounding like they're confident even when they're not.

  - Look, I think, look, I think there's an expectation, right? You're the product manager, right, like what are we doing? Right, and for you to be like, "I don't know," right, that's not a good look, right? That's gonna go reportedly. And let's look, and I'm gonna say it again, like the reality is, look, I'm not gonna say that product managers don't know what we're going to build, right? We have very, very good guesses about what we should be working on right now, you know, and again, the timescale for right now varies based on your industry and context and all that stuff, right? But the reality is, beyond that, we're gonna find out, right? We're gonna collect evidence, we're gonna talk to customers, we're gonna see what happens in the market. You know, February of 2020, mid-February 2020, I was sitting at Barrister Stadium, right, Camping now with 100,000 other people watching a football match. 100,000 people, like if you've ever been in that, they've just torn it down, right? But that the seats in there were tiny. There was like, you're literally sitting on top of each other, there's 100,000 of us just screaming, blowing out air into, you know, and a month later, I can't go walk my dog more than a kilometre from my house, right? Like, we just cannot predict the future, right? And pandemics are one thing, right? Geopolitical instability is another thing. But look, competitive advantages, you know, technological improvements. Where was AI a year ago?

  - Three years out on the roadmap.

  - Yeah, exactly right. Like Web3 was all the noise a year ago. Who's talking about Web3 today? Like literally no one, right? And so we just were pushed as product managers to have this confidence, right? But the reality is that we only know so much, right? And the more honest we can be about that, the more agile the organisation can be, the more realistic we can be about those course corrections.

  - So taking the opposite side of the coin, what are the biggest Antipas or bad practise that you encounter on road roadmapping?

  - The toughest part is that folks perceive them as written in stone. And, again, I just, this comes again from manufacturing, right? When you like this sense of being a feature factory, right? We've heard this term before, right? Like we just, we're cranking out the widgets, the software widgets. The reality is, right? With digital products and services, we want to produce the least amount of software to deliver the highest amount of value. Why, because we have to maintain that software forever. Remember continuous systems.

  - Yep.

  - Right, and so the fewer lines of code that we have to maintain, the easier everyone's lives are in the future. And that is fundamentally at odds with this manufacturing mentality that dominates, you know, leadership in most companies, and so what I think the biggest anti-pattern is folks thinking that these roadmaps are written in stone, and then making it incredibly difficult for their teams to change course when conditions shift in the marketplace. So they've learned something new. And that's a real issue. And it's endemic and prevalent in almost all the organisations I work in still.

  - Whose advice on roadmapping do you listen to?

  - I try to listen to practitioners more than anybody else these days. I'd love to see what people are actually doing. You know, there's a lot of, sort of consultants like me and authors and thought leaders who are out there, putting out their ideas. I'm always curious to see what people are actually doing inside companies, and how they're navigating this balance of, my boss needs to know what we're building for the next 18 months versus I have no idea what we're building beyond the next three sprints, right? Like that's, you know, and so how do you balance that is interesting to me. And so, it's not so much advice is I am hungry for case studies and stories from the trenches. And I get like, one of the perks of being a consultant is you get that I work with a lot of companies and I see how a lot of folks do it. And the reality is that the things that people like me share aren't silver bullets, but they're templates to start from. And what's fascinating for me to see is how people evolve those templates in-house so that it makes sense in the context of this financial services company or of that, you know, real estate company or that e-commerce, fashion retailer, whatever it is. And so, to me, that's where the good stuff is. And then I try to absorb all of that, synthesise it, and then put it back out there as an iteration to moving that conversation forward.

  - So resonates with a conversation I had last week. I ran a workshop for an organisation that knows, mentioned in your book. And the success criteria I was given by the product leader before we started the session was, I want the team to feel like they can roadmap in such a way that is close enough to a plan that senior stakeholders will be satisfied, but not pinning them down too much. It's like finding that balance point.

  - Yeah, and look, and that's gonna vary based on your culture, the culture of your company. It's gonna vary based on your national culture, right? Like doing this in the United States, for example, it's gonna be different than doing it in Japan, right, or in other countries. And it's gonna vary on the individuals as well. I've had great bosses who totally got this and made it easier for me to do my job, and I've had crap bosses who didn't, you know, just wanted to be right and prescriptive and made this really difficult.

  - And I've experienced those same bosses myself. I think we all have. So I'm gonna start wrapping this up, Jeff.

  - Okay.

  - I always like to ask the two hard questions at the end. So the first of those two is, if you had to distil your philosophy on roadmapping into one or two sentences, what would it be?

  - I think my philosophy on road roadmapping would be manage to outcomes and it's a living document. So, commit to outcomes and it's a living document.

  - And is there anything else that we should have asked you or that I should have asked you that I haven't?

  - I'm gonna bounce back to this topic of OKRs and I'll tell you why. I believe that OKRs are the gateway to organisational agility and to the kind of roadmap conversations that we've been promoting in this conversation. The reason for that is because the objectives and the key results don't commit a team to features. They commit a team to behaviour change, to outcomes, In order to figure out what we're going to make, a team just, look, a team can just blindly say, "We're gonna build these five things and it's gonna work." They're gonna be wrong, right? The team has to practise product discovery. Let's go figure out what the best combination is of code, copy, and design that achieves these behaviour changes. And as we kill some of our hypotheses or pivot from some of our hypotheses, we collect evidence and then we change course based on evidence, and then that affects our roadmaps, right? In a good way, right? It makes them more accurate, and changing course based on evidence is agile. It's being agile, right, it is agility. And so, OKRs, when we use them correctly and set them as our goals, enable agility in our roadmaps. And to me, that's crucial to our success because we can't predict the future, everything we've talked about so far, right? So to me, that's the thing that I wanted to connect the dots there, right? These aren't like, yes, OKRs are a thing and roadmaps are a thing, and can they exist without each other? 100%. But when you connect them and you do them right, you actually enable agility to take place. And we need that to survive in the world today. We need to be able to change course as quickly as possible based on new information.

  - Absolutely love it, Jeff, I couldn't agree more. I always like to give people an opportunity at the end just to pitch themselves how they can help you, what they've got coming up, how people can get in touch, et cetera, fire away.

  - Sure, so perhaps not surprisingly, Josh Seiden and I are writing a book on objectives and key results. It's called "Who Does What By How Much?" If you go to okr-book.com, you will be able to sign up for our mailing list. The goal is to publish the book in March of 2024. If you follow me on LinkedIn, I've abandoned what used to be Twitter, and like a lot of folks, so please join me on LinkedIn. I've got an email newsletter on my blog at jeffgothealth.com where I write every week, and the newsletter comes out once every two weeks with a different article. So lots of places, LinkedIn, the blog and then, of course, okr-book.com, and yeah, otherwise, and feel free to reach out.

  - Jeff, it's been absolutely wonderful having you here today. Love the conversation. Thanks very much for your time. Phil, it was a pleasure. Thanks for having me.