What's big enough to get on your roadmap? | Luke Hohmann

In episode 22 of Talking Roadmaps, Luke Hohmann, Chief Innovation Officer at Applied Frameworks, discusses strategic product roadmapping and its evolution with Phil Hornby. He explores concepts from his books, including "Beyond Software Architecture" and "Software Profit Streams," emphasizing customer-centric approaches and using roadmaps to guide pricing, revenue, and business model changes. Luke shares insights on creating inclusionary roadmaps and the importance of constant review and feedback in developing effective strategies.

Luke is Chief Innovation Officer of Applied Frameworks, a boutique consulting firm helping companies create more profitable software-enabled solutions. A serial entrepreneur, Luke founded, bootstrapped, and sold Conteneo, an enterprise software company that helped global companies manage investment portfolios using Participatory Budgeting.

Luke is one of six people in the world recognized as a Principal Contributor to the Scaled Agile Framework, one of the world’s most widely adopted Agile Software Development frameworks. A prolific author and creator, Luke’s contributions to the global agile community include five books, Profit Streams™, Innovation Games®, and a pattern language for market-driven roadmapping. Luke is also co-founder of Every Voice Engaged Foundation, where he partnered with The Kettering Foundation to create Common Ground for Action, the world’s first scalable platform for deliberative decision-making.

Luke is a former National Junior Pairs Figure Skating Champion and has an M.S.E. in Computer Science and Engineering from the University of Michigan. Luke loves his wife and four kids, his wife’s cooking, and long runs in the California sunshine and Santa Cruz mountains.

“If you would put out a press release about it, then it belongs on your roadmap”

— Luke Hohmann

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

Next up we have Dave Martin is a fractional CPO and Product Coach who helps companies become outcome led at Right to Left. So watch out for Episode 23!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about everything Roadmapping, the good, the bag, and the ugly. Today I'm joined by Luke Hohmann. Luke, introduce yourself.

  - Well, hi everyone. I love Roadmaps. I wrote the first pattern language for strategic product Roadmapping in my book "Beyond Software Architecture" that introduced some pretty important concepts in the world and of Roadmapping. I'm known for the innovation game "Prune the Product Tree," which is a way to do customer centric or inclusionary Roadmapping from a growth perspective. And in the new book that we're gonna talk about, "Software Profit Streams," we extend Roadmaps even further to talk about the when can I use my Roadmap to help guide pricing changes and revenue changes and business model changes as opposed to just like, when do I deliver features or when do I serve a particular market segment? So, I'm really excited. We're only gonna talk about the good stuff about Roadmapping, we, we're not, we're not gonna talk about all that bad stuff.

  - You mentioned three books there. Two of them are on my bookshelf. I know the third one will be soon, having already helped review it. That's, I know it's full of good stuff.

  - Thank you, by the way, we think, we think we, we've had about 500 reviewers globally review the book in a, a new cohort each month. And so the book has really benefited from the, from the fairly challenging at times feedback from some of the really lovely thinkers and leaders we have in around the world, like yourself. And so we really, we're really excited.

  - So obviously we are a YouTube channel and a podcast, so I do have to ask people out there to like, subscribe, hit that bell icon, to stay in touch and hear what's going on, and if you'd like to join us here, reach out 'cause we'd love to have you on the channel. So let's start with what's the purpose of a Roadmap?

  - Oh wow. There's a lot of ways that which you might define it. And I'm going to kind of do a little freestyle because people might compare this podcast to what I wrote in the book. And I, and I think that it's okay to have slightly different variations of the, of the meaning of the Roadmap. A Roadmap is a tool to help you navigate an uncertain future, to create an intention about the future that will guide and serve you and your customers. I think that there are too many authors out there who look at, in a sense, poor representations of Roadmaps or poor uses of Roadmap and then rail against Roadmapping at, at all, like don't Roadmap. And you're like, well that, that seems kind of daft if if I want to perform or do something in the future. I, I think the, the Agile Manifesto, I'm an agilist, right? I help form the first Agile conference, I've served on the board of the Agile Alliance. The Agile Manifesto says we value responding to change over a plan. And we never said don't have a plan. And, and the way I like to say it is, I'm an Agilist, how can I experience the joy and thrill of changing my plan if I don't have a plan in the first place? So I think a Roadmap is, is a powerful, incredibly powerful tool for internal stakeholders for our customers to, for investors, if I'm gonna make an investment as an angel investor, or if I'm gonna make an investor as a venture capitalist, or if I'm gonna make an investment as a private equity firm, or if I'm gonna invest in the stock market, I'm investing because I have a certain perspective or belief about the future. So when, when you get people who are like, oh, you know, you shouldn't product Roadmap, you should say, okay, so you don't invest, right? You, you have no investments in of, of any personal kind. Oh, you, you own stock. Why would you own stock? You don't believe in the future, do you?

  - I love that, that kind of way of phrasing. 'Cause I've always talked about my Roadmap is plan A and I start working on plan B tomorrow. But yeah, that kind of, that joy of actually accepting that I'm going to change the plan and actually accepting that that is part of the journey. I, I love that, that viewpoint.

  - Yeah, yeah, absolutely. And I think the other thing, there's a corollary, I do a lot of work in portfolio management 'cause portfolio management and Roadmapping are, are correlated. And one of the mindsets that I like to promote is that a lot of people approach Roadmapping and portfolio management from a scarcity mindset. As in, I don't have enough resources to do what I want to do. And I've consulted to some of the world's most successful companies, right? I've had Google as a client or I've had Cisco as a client and I've had BMW as a client. And what's really funny is, is near, as I can tell, all of those companies have more money than God. So the idea that they're resource-constrained seems kind of questionable when you're looking at it from the outside. And so, what I find more helpful is you approach this from an abundance mindset, not a scarcity mindset. And what you have is you have an abundance of opportunity, you have an abundance of possibility, you have an abundance of things that you can do. And so the Roadmap is one of the many tools that we use to help us hone in on the, the most valuable items. You go to the supermarket and there's an abundance of fruit. So you get to pick the fruit that you like to eat and then you walk over, you know, to the oranges and you're like, oh, okay, well I want these kinds of oranges 'cause you're picking from an abundance mindset, not a scarcity mindset.

  - So true, and I mean you've already started talking about audience, so you talked about customer, you talked about management. Are there any other audiences we need to consider for looking at our Roadmap as well?

  - Wow, there's, there's your dev team, there's your product development team, there's your marketing, there's your sales, there's your customers, I mean, Roadmapping. And you know this, I mean, you, you, it's not that, by the way, for people listening, this isn't just a talk Roadmap podcast. This is a get S, you know, get stuff done with Roadmap podcast because the advice that Phil lays down and shares across the episodes is, is pretty great. So when you think about the, the, the, like, the utility of a Roadmap, the utility of a Roadmap is, if I'm a developer, I'd kinda like to know where we're heading. If I'm an architect and I'm trying to collaborate with my product management peers or my business leader peers, I kind of wanna know where they're heading so I can kind of be sensitised to technological changes in infrastructure that might be important to our company and our success. If I'm a customer, and maybe admittedly maybe less so for the business market, for the consumer market, you know, if I'm, if I'm preparing a Roadmap for say, tax processing in the United States or retirement planning, well I'm, I may not have a responsibility to individual consumers and, and that may not be the right market. But when you're in the B2B space, and I've spent a considerable amount of my career in the B2B space, you really do have a responsibility to help your customers know where you're intended so that they can prepare, so that they can be ready for, for changes in the environment, for changes if, if I'm a payment processor and I'm working on some important new fraud detection algorithms, or if I'm working on some new blockchain backend infrastructure that's gonna provide certain capabilities to my customers, I wanna communicate to that to my customers. I wanna have a conversation with them, I want them to be prepared because I might be tying revenue to an upgrade. If my customers aren't prepared for the upgrade, I'm gonna delay my revenue. Why would I want to delay my own revenue? So there's so many positive outcomes from Roadmaps that, that you can just kind of go through each functional area and look at the collaborative nature of everyone kind of coming together into that Roadmapping process.

  - I seem to remember in "Beyond Software Architecture" there was some talk about some, possibly some different Roadmaps, but some of those different audiences.

  - I've looked at, so, so there are some Roadmapping gurus out there who do talk about having multiple kinds of distinct Roadmaps. And I've had certain environments where the Roadmapping has been very, very specialised. I tend to not do that as much anymore. I tend to try and look for the ways where the Roadmapping isn't multiple Roadmaps, but is a single unified Roadmap. However, I'll give you a couple of areas where Roadmapping has, I think, more specialised applications and therefore there are specialised Roadmaps. One is in the evolution and management of intellectual property portfolios as expressed through patents and patent literature and patent mapping. So there's a sub-branch of, of strategy associated with patents and that's where you'll look at a single patent and you'll look at the patents that reference that and you create what's known as a patent citation tree analysis. And then you, and this is actually a, a technique that I developed myself when I, about 25 years ago when I was working for designing the world's first patent portfolio analysis system for a company, Origin Systems. And so what we would do is we would do a technology closure. So we would look at a patent, we would look at the patents that reference it, then we would look at the structure of those patents and then we would start to say, well this pocket of technologies is likely to evolve in this kind of vector. And so that is a very specialised kind of Roadmapping, but that would go into like the large scale corporate R&D where people are putting in hundreds of millions of dollars in, in, in, in a sense basic or core technology. Most of the Roadmapping that we tend to talk about is more solution centric Roadmapping or product centric Roadmapping where we're using the Roadmap as a tool to integrate different groups of, of people together around a common purpose or a common objective. So there are some very specialised Roadmaps, but those tend to be not what we're talking about.

  - Ultimately, you said it's about communication and tends to be one of my schools a thought of I want one source of truth, but I might render it different for the different audience.

  - Absolutely, and, and we actually talk about that. The way that we talk about that in the, the new book, "Software Profit Streams" is you can think of a mathematical equation like, in your head there's a mathematical equation and we'll pick different representations. I could give you a formula Y equals X squared, I could give you a visual picture of a parabola or I could give you a table of numbers. And each of those representations of that single concept have utility and we think the same way. And we write a little bit about that in the book. So I could, I definitely agree with you. Now, are there tools that automatically do that? And, and not that I know of. So, what you'll often find is that product managers will create different representations of their Roadmap. For example, I might create a lens or a perspective of my Roadmap that's appropriate for investors, which is slightly different than the lens or perspective that I create internally, because internally I might be willing to talk about more optionality with my technical team so I can understand what my choices are, whereas externally, I might not talk about the options that I'm going after. I might talk about more of the, the direction in which I'm headed in terms of the problems I'm solving for my customers.

  - You've mentioned product managers, so they're the people who own this road, this artefact?

  - Typically, in certain organisations, other people own Roadmaps, but the vast majority of the time it's, it's product management that owns the Roadmap.

  - There are many other artefacts that kind of kind of interlinked to a Roadmap. Vision, strategy, objectives, and probably a hundred other things. Can you maybe talk a little bit to the relationship of a Roadmap to these other things and-

  - One of the challenges that we've found over the years of doing Roadmaps is that there are these other artefacts and we don't often see the, an explicit or intentional relationship between the Roadmap and these other artefacts. And in the new book, "Software Profit Streams," we wanted to help the reader kind of, in a sense, situate yourself. And I have a friend, Pete Barons, who has another great podcast in leadership in the Agile community. And we were talking and what emerged from that conversation was this idea that Roadmaps are helping us navigate fog. I'm, I've gotta navigate to an uncertain future. I can't even see it, I've, I'm a long distance runner and so if I'm running a marathon, it's 26 miles, I can't see 26 miles ahead of me. So I need tools to navigate, and I need mechanisms by which I navigate. So when you think about the navigational structure, I can either, and I'm, let's say I am gonna run with the analogy which we do in the book, which is I'm navigating the fog to a destination, happier customers, greater profits, et cetera. Well, how do I navigate the fog in the real world? Well, one thing that we do to navigate fog is we create a tool that allows us to navigate relative to an external object. So I might have the North Star and in the middle of the ocean I have a sextant. And so, the North Star is often known as the vision or often known as the vision and product. So I have a vision for the accomplishment that my software will create for my customer. Like, how will I help my customer be happier or better? That's my vision typically. I, and typically if you're in Silicon Valley, the vision really is for, for a better world of some, some, some way. So that vision guides us through the fog, but I still need mechanisms to get from where I'm at to where I think the vision is and that's where Roadmap kicks in. I also can use mapping of the terrain to get through the fog. So there's different tools that we use. The tools that we think are very important for product managers is of course vision, which we've talked about. But an awareness of where you are in the industry life cycle and an awareness of where your solution is in the solution life cycle relative to the industry life cycle. From there, there's a few more tools. There's the tabular representation of a Roadmap that we're very comfortable with. where we, where we see rows which represent some aspect of the business and columns, which typically represent time, right? There's that kind of Roadmap. And then there's the "Prune the Product Tree" representation of the Roadmap where we represent a Roadmap more organically and we talk about the holistic notions. And one of the important features of a "Prune the Product Tree" representation, especially for executives, is that many times executives think that when a feature is shipped, it's done. And many product managers know that when a feature is shipped, it's the start of that conversation and the start of that evolution. So sometimes the example I use when I'm teaching Roadmapping is I said, look, when when the first automobiles were created, they didn't have windows. They were the horseless carriage. Then we created windows, but they were fixed. Then we had windows that were with a hand crank and that hand crank window lasted for decades. Then we had power windows. And pretty soon you're gonna see windows that are gonna be climate-controlled based on your personal driving preferences and the speed of the car. Because we now know that the aerodynamic shape of a car, if you have the window down and you're driving too fast, it gets too loud. But when you slow down off the highway, you want your window lower because it's a beautiful day. So you're gonna see cars continue to evolve through software-enabled capabilities and sensors and your personal preferences so that when I'm kind of driving where I live in sunny California and I'm driving down the, the, the street in, in the neighbourhood, my windows are down, I've got the fresh air, I get to the highway, I won't even have to touch my window and it'll automatically raise. That notion of evolution and growth and change is a really great representation of, or a really well represented in "Prune the Product Tree" because we talk about the growth and evolution of this capability in a very natural way. And it also serves to help executives understand that the product that we're creating is this organic thing that needs to have new features added and features pruned. And, and I wanna point out, Phil, that that there's sometimes people change the name of "Prune the Product Tree" and they call it "Product Tree." That's okay, right? But I want people to really know, I didn't name the innovation game and I didn't name the technique "add more crappy features to your crappy product product tree." I called it "Prune the Product Tree" because we prune a tree to create, you know, we don't want a hundred apples, we want 70 luscious, beautiful apples. And we prune so that we concentrate energy into creating something better. So we prune the product tree to remove the features so that we can concentrate our energy on the features that really create the most impact for our customers.

  - And I, I always, yeah, I've always found it quite useful from the pruning side, but also the evolution side, as you say yourself, and I often use different coloured Post-its or stickies as I'm doing that and kind of the take things away, add things in and what are we missing as part of that conversation, in particular with customers? I found that super powerful to find blind spots.

  - Oh absolutely, yeah. I, the, the traditional Roadmap does get a little presentation fancy, if you will, and you get what I call a show up and throw up. The customers show up to your event, you throw up your PowerPoint Roadmap and then everyone vomits. And the reason they vomit is because you're saying to them, how, what do you think about my Roadmap? But you're using a presentation format. And so customers who, and it's kind of like a bad romantic comedy. You've got one person who desperately wants to date the other person, and you've got the other person who desperately wants to date the same person and they can't come together through some mechanism that's preventing them from falling in love. And in this case, the presentation of PowerPoint and using, using the wrong media is preventing us from, from our customers from coming together. "Prune the Product Tree," when done as described in my book, "Innovation Games" is literally a physical activity where you're printing trees, you are writing things down on Post-its. Customers can go up to the tree and you can say, this is our Roadmap, this is how we think it should evolve. Would you change it? And because of the presentation, it's the same information. Different form, but the mechanism of that presentation enables customers, as you pointed out, to interact, and to create, and give you feedback. Now, do you do it automatically? I don't know, I don't know what the feedback is. It, product managers, you know, you still have a job to do. Customers may move things around on your tree and you might go, thank you very much and we're not gonna change. Or they may move things around and you go, oh, okay, yeah, that's fine, that's even better, let's do it that way. So the, the act of getting feedback doesn't mean you're abdicating your responsibility. In fact, you're doing your job as a product manager 'cause part of your job is to get feedback.

  - And that, taking that critical eye to kind of judge, what I've just learned, and does it make sense in the broader context, that bigger picture of understanding the market, understanding what's going on. Now, that probably rings me to a great point for, I know in the, in the metaphors and the models that you talk about within, within "Software Profit Streams," you talk about market cycles, market events and how that relates to a Roadmap.

  - Yeah, in the original pattern language that I wrote about Roadmapping way back in 2002 in my book "Beyond Software Architecture," I introduced a concept that even today I don't see a lot of Roadmapping heavyweights talk about. And that is the notion of market events and market rhythms. Let's talk about market rhythms first. Humans are time centric creatures. We're tribal, we're time centric. We've been recording the height of the Nile for more than 5,000 years, right? And that mattered because it mattered with food and it mattered with planting and it mattered with our survival. So, when you look at how markets evolve, every market that I've worked in and every customer that I've worked with can identify a set of patterns that govern how their market works. And what's really interesting is that even when it's a new market and we don't have patterns, we create patterns precisely because we want to have these, these understandable rhythms of our market. So the first thing that we like to do when we're working with teen, I don't know if it's the first thing, but one of the first things that we like to do with, with customers when we're working on Roadmaps with them or teaching them how to Roadmap effectively, is we just start to say, look, draw a graph where on the Y axis it's the value of a release in terms of your customer's perspective. And on the X axis it's just time in terms of one year. Where is it more beneficial versus less beneficial to release? And the, I, I grew up in Buffalo, New York. It's very cold, it gets a lot of snow. And what I let people know is no one in Buffalo, New York is buying swimsuits in January because it's snowing, right? So we have the capability to deliver swimsuits in January, right, we have fast fashion, we can deliver clothing anywhere of any kind at any time. And that's where the Agile community is. When Agile started, we were like super happy that people were getting to done at the end of the sprint. We were super happy that we were moving from 18 month release cycles to nine month release cycles to six month release cycles. Now, we have continuous deployment, CICD, we have IOT, we have hardware devices that can automatically have downloadable updates. We have all of this capability. And, so now, it's kind of table stakes to just say, I can release when I wanna release. So it's really incumbent upon the product management leadership to say, when should I release? If I can release at any time I want with acceptable quality, which is table stakes in Agile, then when should I release? That's where the rhythms and the events come in. So the rhythms are the ones that occur every year. They're kind of how an industry organises. If you're in consumer electronics, it's might be the CES show in the United States. And there's another big one in Europe. If you're in, if you're in automotive, you have usually the annual new release of the cars. And we expect to have new cars every year. If you're in ed tech, you're gonna have the, the cycle of the kids going back to school and summer vacations. If you're at higher level post-secondary education, you're gonna have the graduation cycles of people finding new jobs and entering the job. Like every, every market has these rhythms. The second thing that every market has is we have regular, we have events. One class of events are regulatory events. I have every industry has some aspect of laws and that's, that's a vector that's gonna increase in technology. We're gonna be more regulated, not less regulated. So we've got things like GDPR, we've got laws about privacy and data. We've got emerging laws of, of, in, in FinTech we've got, you know, the various securities and exchange laws. We've got all of these events that are coming. We've got technological events. I'm using flutter and fudder, flutter upgrades from version two to version three. I'm backending my API in times of Stripe or PayPal or Adyen and my payment processor is gonna have an event where they're gonna do an upgrade in the API. So, I have two things that I wanna put into my Roadmap. One is my market rhythms and the second is my market events. And then as a product leader, I have choices. Do I wanna release before an event to help my customers prepare like there's a law change or a regulatory change and I wanna get my solution out there so they're still in compliance? Or do I wanna lag an event? The API provider produces a new API and I might wanna let it settle for a, a release or a minor upgrade and then I adopt, or I might wanna go right when they adopt so that I pick up the benefit of the new API. Those are all choices that product leaders need to make and they're all based on, I see other Roadmapping techniques talk about events, but I don't really think, think they, I don't really see them talk about these rhythms and, and the creation and management of the rhythms.

  - Kind of lines up with a comment. You talked about CICD, I think Nicole Forsgren, who's a, a DevOps kind of fault leader and someone mentioned in the training course to me years ago, a quote from her that was, "Delivering should be, you know, just a capability, we should be able to deliver anytime, anywhere. However, choosing to deliver to a customer is a business choice." It's...

  - It is. It's not just, well we've finished the code, we've checked it in, it's passed all the tests, now we can put it out there. It's when is the right time to put it into a customer's hands?

  - That's right. And, and and frankly, we're, we're, we make a lot of awkward, a lot of times it's like, you know, developers go to a party and they're the awkward person in their conversation or whatever. Product leaders make these awkward choices about when to release 'cause they get excited that they can, and then they release outside the rhythm and they don't, they don't know why something happens. I've worked, for example, in the payment processing industry and one of my customers was, in fact, two of my customers were the world's largest terminal providers. And so, when you think about a, you, you, you do a card swipe on a payment terminal at a store, you are dealing with a computer, right? It's got a hard, it's got keyboard, it may be a limited keyboard, but it's got a keyboard, it's got a screen, it's got an operating system, it's got applications, which means it's also a huge attack vector for security vulnerabilities inside a corporation, right? It's an endpoint that's an attack vector. And it also means that there are times where that corporation needs to be on lockdown. I don't care how much quality you have, it's unlikely that the retailers are gonna upgrade their terminal software on December 25th or December 24th or here in America, it's Valentine's Day today. Happy Valentine's Day. And we're recording on Valentine's Day. It's pretty unlikely that a terminal or a retailer is gonna upgrade the software on their terminals on Valentine's Day. I don't care how much quality you have, I don't have, I don't care what your CIDC pipeline has. That, that rhythm, right? Is, is overpowering in terms of everything else that we do because the risk isn't worth it. It's like, I'll really, great, your software's ready on February 10th. I'll put it in a production on February 20th. I'm good. Right? And that's what, that's what I think. So I, I'm in totally violent agreement. The, the capability to release at any time anywhere is table stakes in Agile, it's part of what we do in DevOps, it's part of what we do in modern sec DevOps and, and CICD pipelines. When we actually choose to release is, in fact, a business decision. And by understanding market rhythms and market events, you make better business decisions.

  - Yeah, and I mean, reading that kind of expressed something that had been in here for a while, but I've not had the language to express, which is why I love it and why I, we wanted to bring it out in particular.

  - I'm glad you did because it's one of those things where, and and I, I'll, I'll, I'll be kind of candid. I've gone into environments where I don't know the domain and I'm thinking to myself, oh, I don't know of this one. Maybe this is the one that doesn't have a rhythm, right? And I remember very clearly, one of my customers and it's in the book was United Technology Aerospace Systems. So I don't know exactly what they did until I went there, but what they do is they build the landing gear sub-assembly for aeroplanes . So it's so, so there's like the fuselage and then you kind of bolt in the landing gear and it's really wild. They're, they're like a $13 billion business, which with, with 60 customers, right? Like Boeing is their customer, right? Or Airbus is their customer or McDonald Douglass or so these huge airlines. And I'm thinking, okay, we're gonna do Agile transformation, we're helping them through their thing. And I'm like, let's do some Roadmapping. And I said, okay, here's how to do market rhythms. Go, and I'm thinking this is the one that's gonna fail. I, because I can't imagine rhythms. And they're like, oh yeah, there's these two air shows. That's where all the negotiations take place. That's where, and it's just, and I'm, I, I had a half hour in my class allocated to like, trying to find rhythms. They were done in five minutes. And they're like, thank you for having us do this. Because those of us more experienced people are always teaching the, the new people what the rhythms are. Now that we've, we've written them down, we have something that we can immediately share. So that thing that's in the back of your head is what it really is, is this experience. That thing in your head is experience. And what you're saying Phil is oh, you've given me a way to share my experience and share my wisdom so that other people can get access to it beyond tribal, just talking about it. And that's one of the things that Roadmaps do. Roadmaps help us share our wisdom. They help us share our experience for people who are new to an environment or new to our company.

  - We've naturally answered a lot of questions that I would've asked, so I'm, I'm gonna kind of skip ahead in what I was thinking. Luke, what if you were to name best practise, it's something around best practise for Roadmapping, what would it be?

  - We have a, about a dozen, what I consider to be best practises in our book. I'll pick out a few that I've found to be extremely durable over the years. One is that I don't version Roadmaps. I, I version source code because you have a legal requirement to be able to recreate source code if you got into a legal disagreement about its capabilities or functionality. Even cloud providers have to version, for example, their terms of service with their source code because the terms of service were what I signed up for when I signed up for it. And if I have a disagreement, I'm gonna, I have to know the, the, the agreement that was in effect, if you will, at the time I signed up. So we version source code, we version legal agreements, etc. But typically, and, and I strongly recommend that we don't version the Roadmap because a Roadmap is a forward posture tool in, I don't really care about the past. What I care about is where am I going now? And what's interesting is when people care about the past, they start to use Roadmaps inappropriately because it's, when I have that past representation that can use Roadmaps as like, oh, you didn't deliver what you said you were, well the market changed, I was being agile. So one of the things that I like to do is I like to put into my Roadmap a date and a phrase that says, "Next update on... specific date." So we're recording, as I said, on on Valentine's Day, it's February 14th, it'll be published later, we get that. So I might have in my Roadmap next update on April 15th or April 20th. And so that way my, my internal organisation has this feeling of a forward posture and they know that there's a commitment, there's a cadence of updates that aligns with the cadence of releases or the cadence of portfolio management. So that I have this feeling of a forward posture and this feeling of progression. I think that that's a absolutely a, a best practise is to have this, this feeling of the future associated with my Roadmap.

  - Yeah, I mean I sometimes call that the best before date. That's when it's gonna get updated. So the the old one is out of date at that point.

  - That's right. And I think the second, a second thing that you can look at as a best practise is, and this is a new practise for me, so I don't, I don't wanna imply that, that I've had all the answers for all the years because like all of us, we're learning and growing and improving. But the thing that we added in the book was we had an explicit swim lane for profit and pricing and revenue changes. And what I, the reason I'm doing this is because I, I feel that the Agile community has kind of swung the pendulum too much into this, this ill-defined concept of I'm delivering value. I have a value stream, I'm gonna deliver value. Okay, great, well I'm kind of old school. The the value kinda needs to be profit because companies can't survive without profit. So I've been asking some very simple and questions and it's sometimes funny, Phil, how the simple questions are what throw people off. Because if you ask them a complex question, they can give you a complex obvious skated answer. But if you ask them a simple question, it's sometimes interesting to watch how people struggle with a simple answer to a simple question. So here's the simple question. You've been delivering value, great. When was the last time that that value motivated a price point change that enabled you to have greater profit? Ahh um, ahh... Right, so it's interesting to see how, a very simple question, if I've got this Roadmap that's projecting a forward future and that forward future is better and I'm producing more value, okay, when did you get a price point change?

  - Or least you should be able to communicate why you haven't dropped your price because of commoditization in the market. So we've been able to maintain our price, our price level at least at the very least, you know, to show that.

  - Yeah, I, I'll take that. Like, I'll take that as a reply like, yeah, Luke, we haven't raised our prices but our competitors have dropped and we haven't because we've been able to demonstrate that we're still a better value for the price point and our, and and that would be more aligned with say like the MRR model of a B2C company. But in a B2B company, even then you're, you're gonna be looking at adjusting prices and, and there is a time centricity that's associated with Roadmap updates about, we were working recently with one startup that hadn't adjusted their prices in two and a half years. I'm like, okay, we might wanna, we might wanna raise your prices. And they're like, oh, it's feels scary.

  - It's okay, we've got some best practise in there. What about the biggest mistakes you see on a Roadmap?

  - Well, I think the biggest mistake is, so there are people who, who say you shouldn't Roadmap, and they say they, you shouldn't run because of they're, they're, I guess they're, they're scarred soul past is that people used Roadmaps improperly. Like, people use Roadmaps in an un-agile manner as a firm hard commit as, as something that is in violate in terms of the team. And frankly there, there's always a choice, right? I, I talk about the kind of commitments that people make. Let's say, and I'll give you a personal example. When I was CEO of Conteneo, a collaboration software company, this was a few years ago, GDPR was coming out. And you knew GDPR was coming, right? You, you had a very clear date, May 28th, right? It was very clear or May 25th, but it was very clear. Now you have a choice for that market event. You could be GDPR compliant or you could not be GDPR compliant. And you're choosing to take on risk, kind of like when you're driving down the road, there's a speed limit. You can choose to speed or you can choose to do the speed limit. Sometimes I choose to speed 'cause I have reasons why. I'm not saying they're good reasons, but they're, they're the choice I've made. So I think that, that the, the... the negative application of Roadmaps are really people just fooling themselves, right? If you create a Roadmap and you choose to use it in un-agile manner, that's not a fault of the Roadmap. That's the way you've chosen to use it. And it's not a best practise. It's a, it is a problem. And that's typically people not wanting to acknowledge that life doesn't always, you know, unfold as your plan said it should . Which is why we're agile, right? Which is, so that's, that's probably the single worst practise of Roadmaps. And then you, you get overcompensating responses where people say, well because you use a Roadmap improperly don't Roadmap. No, that's not the way to do it. How about because you used a Roadmap properly, run a retrospective, reflect on what happened, and choose to be better.

  - We throw things out because of misuse and we blame the item itself as opposed to the usage. And...

  - That's right.

  - We've heard some of your advice on Roadmapping. Whose advice on Roadmapping do you listen to?

  - Wow. Whose advice do I listen to on Roadmapping? Well, I have a friend, Harry Max. And I would really recommend that he become a guest because he's such a dynamic and interesting person. But he's, he's writing an entire book on prioritisation and about the meaning and, and techniques about prioritisation. And I listen to Harry. There's another book that I think is a very, very deep philosophical book on, on how time influences called "Tempo." And "Tempo," I believe the author is Venkatesh Rao. And I think that his deeper perspectives on Roadmapping and markets are, are pretty interesting in, in the book "Tempo." It doesn't say, like, do a Roadmap, it's more of like, what are some of the underlying psychological factors that go into Roadmapping. I think Janna Bastow over at Prod, ProdPad, she's got some really interesting perspectives of the, of the now, next, never or now, next, later Roadmapping format. And I think that that has certain virtues, especially when you're moving, really, if you're moving super fast, if you know that, that now, next, never or now, next, later Roadmap is really appealing because you can absorb things. So I think Janna's got some interesting perspectives. My friends, Rich Mironov, Roman Pichler, they have some great perspectives on Roadmapping. You've got impact mapping with Roadmapping, so you can see some nice correlates between the impact mapping technique and when you might wanna pull something into a Roadmap. So I think that there's a number of thought leaders and, and people who are talking that, that are pretty smart about Roadmapping and can use some really useful, or can grab some really interesting techniques together.

  - What I love is I've just, I've just found two new ones for me. At least three of the people you named are previous guests, so that's awesome, but yeah.

  - Well, one of the things that Harry talks about is he talks about, he has a TED Talk called "The Problem Is Not the Problem." And one of the things that Harry points out is that there's a difference between things that you can solve versus things that you need to manage. So I can't solve my security posture. I can solve a bug. I, I wrote a bug, fixed the bug, problem solved. I can't solve my security posture because in the, any technology stack, the sophistication of the stack requires us to always be managing security. So there's a big, there's a big difference conceptually between something I solve and something I manage. And I think that that alone is worth its weight in gold.

  - Interesting, I'm gonna have to dig into that one. If you had to distil your philosophy on Roadmapping into one or two sentences, what would it be?

  - Roadmapping is a set of tools and techniques to help you navigate an uncertain future to a desired outcome.

  - I love it. So what should I have asked you about Roadmapping that I haven't?

  - I would say that the question that you didn't ask was what's the, what's the relationship between the Roadmap and, and the backlog? And I think that this is where people, especially junior Agilists or people who are less experienced with Agile, they expect that I have this Roadmap here and I have this backlog here, and what's in the backlog is what's in the Roadmap. And there's this kind of direct correlation. That's not a best practise at all. That's not even how close to reality. The Roadmap represents these big, chunky things. And, and the other best practise is I have what I call the press release test. If you would put it on a press release, that's probably what you would put on your Roadmap. Your backlog, however, is gonna have additional things that aren't associated with the Roadmap. They're gonna get feedback from the team, they're gonna be local fixes, there's gonna be local bugs. And so the idea of the Roadmap being the only thing that controls the backlog is actually a huge mistake. And it, it creates a very slow moving sclerotic Agile because it's forcing connections between things that should be loosely coupled. It's, it's creating a tight coupling between entities or, or artefacts that should be loosely coupled. And that's what we didn't talk about and we should, because if, if I tightly couple my backlog to the Roadmap, I'm actually creating less agility in the organisation. I'm creating less ability for those teams to respond. And that's often where the teams, when you really start to dig into, oh, we hate our Roadmaps, why? Well, because I can't do anything unless it's on the Roadmap. Well, okay, now I've coupled, like, those are language, like you, you get good at, at dissecting the challenges of the organisation through the language of the organisation. And when people start saying things like that, you're like, okay, I don't think you've, you're using Roadmaps and backlogs the right way. Let's, let's talk about that. Because those entities are, they are certainly related, but they're not coupled. And that's, that's something that I, I do see happening.

  - Love it, and I love the answer. It's been great talking to you today. Learned a lot. Just wanted to give you a, an opportunity to pitch yourself maybe the new book, and how people, how you can help people.

  - Sure, this is a stunningly beautiful book and Phil will agree that this book is a technology book about a topic on pricing and licencing. And there's a lot of books out there about pricing and licencing for traditional stuff. And it's, what I say is, it was written by boomers for boomers. It's, they're text heavy and dense and frankly, like, kind of snoozy. We wrote a book that is beautiful and I, I like to joke that it was a caveman writing and what I meant, what I mean by that is the book was literally written by hand. And then we took photos of what we wanted with sketches and we, we shared it with our designer, Frederico Gonzalez and Frederico created these beautiful images based on our sketches and we would go back and forth. So two things are really powerful about "Software Profit Streams." The first is that it's the content itself, but the second is that it is stunningly and beautifully presented in a way that everyone can grasp and put to work very quickly.

  - Totally agree, and I, I'm looking forward to getting a hold of my copy. I'm consuming it in final edit as opposed to the earlier versions, but it's, I'm sure it's gonna be awesome. Luke, it's been an absolute pleasure having you here today.

  - Thank you so much.