What is the job-to-be-done of a roadmap? | Bob Moesta

In episode 53 of Talking Roadmaps, Phil Hornby interviews Bob Moesta, an expert in Jobs-To-Be-Done (JTBD) theory. They delve into the core function of a roadmap, discussing how it helps identify and solve customer struggles. Bob shares insights from his extensive experience in product development, highlighting practical applications of JTBD in creating successful products and services.

Bob is an influential entrepreneur and innovator known for his groundbreaking work in the field of Jobs-To-Be-Done (JTBD) theory. Born with a curious and analytical mind, Moesta has dedicated his career to understanding and solving customer struggles. He has started 8 companies and is currently the co-founder of the Re-Wired Group. He served as its CEO and president, helping companies of all sizes unlock hidden insights and create successful products and services.

Moesta's expertise lies in discovering the "job" customers are trying to accomplish and designing solutions that address those needs effectively. He has applied his JTBD framework across various industries, revolutionizing how businesses approach innovation and marketing. Through his workshops, coaching, and consulting, Moesta has empowered organizations to make customer-centric decisions that drive real growth.

Recognized as a thought leader, Moesta has co-authored the books "Demand-Side Sales 101"  and "Learning to Build” and shared his insights at numerous universities, conferences, and events. His passion for understanding customer motivations and experiences continues to inspire others to adopt a Jobs-To-Be-Done mindset. With his relentless pursuit of understanding what truly drives customer behavior, Bob Moesta has become a guiding force in the realm of innovation and customer-centricity.

Despite his success, Moesta remains humble and dedicated to his work. He continues to innovate and push the boundaries of product design, innovation, and entrepreneurship and his impact on the industry will be felt for years to come.

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

In the next episode we are talking to Melissa Appel, she is a Product Coach and Author. So watch out for Season 1 - Episode 54!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about all the good things, the bad things, and the ugly about road mapping. Today I'm joined by Bob. Bob, please introduce yourself.

  - Hi, I am Bob Moesta. I'm a product person. As my mom would tell you, I was an engineer out of the womb. I started breaking things by the time I was two. I started fixing things by the time I was five, and have been on the product path since then. I've worked on over 3,500 products. I've worked on things like the guidance system for the Patriot missile, Basecamp, and Pokemon mac and cheese and everything in between. So I'm one of those guys who just, I'm annoying, but at the same time I love to build stuff.

  - And you're also missing out a key part there, Bob. I know you are very well known in the jobs-to-be-done-space.

  - Yeah, yeah, yeah, yeah. So the other thing is I've had three close head brain injuries. I can't read and I can't write. And so jobs was a method that I had developed mostly for myself because of that disability, and ultimately, it's led me to teaching it to other people. And so I'm the co-architect of the jobs-to-be-done framework as well.

  - Love it, and I'm a big fan of jobs-to-be-done as a concept and putting them on your roadmap in particular.

  - Yes, we'll talk more about that. That's good.

  - [Phil] If you're enjoying the channel, subscribe, hit the bell and give us a like. I mean, I normally ask the question at the start, "What's the purpose of the roadmap?" I'm gonna rephrase that. What's the job to be done of a roadmap?

  - Yes, so it's a very interesting thing. So when you dig deep into a roadmap, a roadmap has multiple purposes, right? Part of it is a way in which to think about what we're gonna do in the future, right? It's a set of expectations we set to both management as well as investors of what we're gonna do, as well as it sets expectations for customers on what we're gonna do, right? And the hard part is that there's so much unknown between where you are and where you need to go, and that we end up making promises we can't deliver on. And so, to me, I'm a very big fan to realise, number one is we plan when we're the stupidest, and then management holds us accountable to our stupidity. Like if we thought we should change in like two weeks or three weeks 'cause we're now smarter, we can't most of the time because we made a commitment before. And so this whole thing is, to me, is a roadmap is about something that has to unfold or unroll, but it's this aspect of realising it's not something that's set in stone, but it's more about kind of the direction and magnitude in which we want to go to certain places. And so, to me, one is we talk about, so for me, when I think about, there's two types of roadmapping. There's the next 90 days, and then there's after 90 days, and between now and 90 days is typically where for, at least for me and my teams and that I work with, we end up being able to know exactly what we need to do over the next 90 days. We need to go build, what are the outcomes we're trying to get, kind of all that detail. But after 90 days, to be honest, we're, we're actually only talking about struggling moments we're gonna go after, not features we're gonna build, because the features themselves might be obsolete by the time we get there. And so ultimately, if you think about ChatGPT, it changed everybody's roadmap because at some point, and really it's a tool, it shouldn't change the roadmap. It shouldn't change the struggling moments we go after, but it might change the way we talk about a feature or the sequence of features we go build, because of the outcomes we want to go make. And so I start with the outcomes that we're trying to get to as opposed to the things we're trying to build.

  - Totally agree. I mean, I often joke that last year everyone had AI, and for probably the last five years, had AI in the three year out column on their long-term roadmap. Then suddenly it pulled into we need it now.

  - That's right, and they're like, "Well, where should we use it?" I'm well, "Where are people struggling?" It shouldn't be that hard. It should be something that slots in on top of it. And so what happens is when we start to make commitments of, oh, we're gonna build this feature, we're gonna build this widget, it's like, "Okay, why?" And a lot of times you start to realise, most of the time, at least again, I'm an engineer, and I was taught a lie. The lie I said is build it and they will come. And so every time I'd come up with a feature, it's like, "Well, somebody's gonna want that. We're gonna have to have that." And so we end up putting all these features on there, but we end up not realising kind of the implication, both from an investment perspective, but also from a market perspective. And so it's not just about what we can build, it's about what are they struggling with, because it's a two-sided problem. We have to be able to build something that we can execute on, but it has to go into a moment where people want to do something new or do something different because the old way doesn't work. And that's the other part that's always missing to me from roadmaps, is it's about what we can do versus what we should do.

  - Totally love it, and I love those different lenses. The 90 day and the beyond 90 day. Now, I wonder for the types of content that's on there and those different timeframes. Are there different audiences, different people looking at, different people care about those different views?

  - Yeah, this is to me always the hard part is how do you package the roadmap. Because at some point you need, it's not that you need three different ones, but you have to realise that three different audience are looking at them. And so ultimately the fact is that this is one of the things, and to me the most dangerous one is always the sales one. We're putting this on the roadmap, and we're telling people we're gonna sell this, we're gonna build this, and they can be able to buy it, but it forces people to wait. It forces people to you know, at some point in time, we really don't know what the feature is. There's a lot of kind of bad decisions that are made around kind of adding things to the roadmap just from sales perspective, right? So ultimately, I consider the roadmap a strategic document that requires input from all the different people as opposed to something that the product person is just pulling together to say, "This is what I wanted to go do," right? That's part of it, but at the same time, it's about what's the implications to the rest of the organisation as you build those things out.

  - So agree, so aligned there, Bob.

  - It's a living, breathing document. It's never done. It's something that's it's our latest look in today. We can use it to diagnose what we've done in the past and how well we're actually good at this. But it's a process, right? And so when it's a process, there's no end. And so we just have to realise it's not about perfection, it's about what is the real purpose of it, and I feel like half the time we're using it to measure millimetres when it's a yardstick, right? They're trying to be way too precise at the wrong places in time.

  - That phrase you used there, the roadmap is never done. It's the same as software, right? The software is never done, the product is never done. The roadmap is never done.

  - But partially is to realise, what are we going to do now? What are we gonna do with the? Time is the most precious of all our resources. We keep thinking about money, but really it's time. And what do we want the teams to spend time on, and what do we want 'em not to spend time on? And so to me, the roadmap is about helping prioritise the time and knowing the boundaries of when have we gone too far, when is it too much? And ultimately, this is why I subscribe to Ryan Singer's version of fixed time, variable scope as opposed to fixed scope variable time. Because what happens is if it's fixed scope, we are never done. But if we fix the time, we basically are saying, "What can we get done within this period of time that's most useful to the product or to the feature?" And we end up getting way more progress than trying to do it under a fixed scope and variable time.

  - I mean, that feels like we've only got two of the parts of the iron triangle. We've got the quality and the risk element on there.

  - Yeah, yeah. So there's quality, cost, and timing, right? Those are the three things. And so if we fix the time, right, in some cases we're fixing the cost, but ultimately, by shaping it in a space that we can actually think in and see in and be, so for example, the cycle, we're talking about are six weeks to eight week cycles, right? And so there are times where we can see what we have to build, but there's still a lot of unknown. And so it's not about, to me, roadmapping is not about product planning in terms of here's what everybody's gonna do every week. It's about kind of the direction we're going and what we're working on now and what we're not working on in the future, right? Or not working on until the future, if you will. And so it's about that prioritisation of our time and our focus. That's to me what the role of the roadmap is, and to realise how does it play out, and what is the sequence of things we need to build as opposed to just kind of thinking about them as one-off things that we just do.

  - Absolutely. Now you already started to hint at this, that quite often the roadmap is the list of desires that the product manager wants to create. So who owns it, who maintains it, whose artefact is it?

  - I think about it as it's the head of product. Ultimately, they're the person who owns the communication around it, and it's their job to pull everybody's input into it as well as to be able to kind of communicate it back out. And so to me it's, again, it's setting expectations and being able to kind of prioritise in a, if you will, time investments or prioritise what we're gonna do and when we're gonna do it, right? I think of it as it layers across the top. It's not all the details of what we're gonna do, but it's kind of this directional piece of where what we're doing, and, more importantly, what we're not doing.

  - And I guess layering maybe a layer above that, we've got strategy, vision, objectives. How do they link in then?

  - So to me, strategy is the almost like the game we have to play in terms of what we have to achieve in order to be competitive. The product roadmap is then the ways in which we can achieve competitive success through product. But there's also sales, there's also operations, there's still a whole bunch of other places we can achieve it. But think of it, the way I always thought about it is, product development was the engine to actually drive strategy. And so to me, the product roadmap is the engine that drives product strategy. And so ultimately the strategy is about the bigger business, the product strategy is what are we gonna do actually to contribute to that bigger strategy?

  - And so we've got the kinda the vision strategy and kind of objectives leading into it. And you talked about kind of the lower level execution level detail. What else links into the roadmap? I feel like it's this almost, it can act almost like a central hub to a lot of things to unify them.

  - So the thing is I think of, there's a. So I think of the stuff that we're building is more bets than for sure things, right? And so we plan like they're going to happen as opposed to plan like it's a bet. And so I think of road mapping, the other angle that I bring to this is it's more about reserving capacity. You could say it's budgeting, but it's really about reserving capacity for the work we have to do. And how are we gonna, actually, we're gonna work on this and not that, and here's what we're gonna focus on, and we've got this much time or this many resources to work on this problem or this opportunity. And so it's about reserving capacity as opposed to knowing exactly what we're gonna do. And having worked on so many products, I realise I would spend so much time planning and those plans would always change, but if I actually just planned a little bit differently, I could actually be way more effective with it and realise that I'll figure the details out in the work, not before the work.

  - Although there is that good old phrase of a plan is useless and planning is invaluable. I think the thought process,

  - It's a verb, it's a verb, it's not a noun. And so in some cases it's like that's why it's never done. It's never a document that's there. Planning is what we're talking about, not plans.

  - And I often say the same thing. Roadmapping is the activity, the roadmap just happens to fall out of it as an artefact and be useful.

  - Well, it's a sense-making exercise, right? To figure out kind of like, if we wanna do all these things, and typically we have 10 pounds of stuff to put into a 5-pound bag. And so part of this is the roadmap is about helping us kind of prioritise and sequence and realise what are those things that have to come before something else? And ultimately, how do we commit to the organisation so they know where we're going without actually detailing where we're going to go? And so to me, it's very similar to, in the military they have something called commander's intent. And commander's intent is about what we're trying to achieve, the outcomes we're trying to get to, and kind of the resources that we have. But it's not telling people what to do at each play of the mission, right? And so it's letting the people on the front lines make the decisions they need to make, but letting them have a framework around it so they're not going out of bounds. And so that's really what to me is we're trying to do, is realise like there's a lot more unknown here, and treating it like a bet and reserving capacity is better than saying it's a plan, and we have a goal , and we're gonna hit this launch date, right? Because we almost never hit the launch date.

  - Or we might hit the launch date, but we might change the scope if we go back to that fixed time, variable scope.

  - Exactly, exactly. So that's what I realised is that, it's better to, if you realise the 80-20 rule, right? And you iterate it. So if I get 20% of the things that get me 80% of the effects, and I do one iteration, I'm at 80. If I do another iteration, I got 20% left. I get 20% of that is what, 16. And so ultimately I'm able to get to basically 98% with two iterations. With three iterations, I can actually be way better off than I am trying to do it in one iteration. And this is the whole point is that we don't know everything until it starts to happen. And so this is where we keep thinking we know all the answers, but the reality is there's way more unknown than there is known. And we have to remember that as we're building.

  - Yeah, and I often like to put the bets or the hypotheses or these things onto the roadmap, possibly even the discovery that we're doing on the roadmap to understand things.

  - I think hypotheses are important, but to realise there's still a lot more unknown. This is where, for me, a lot of the jobs research that I do is I don't actually go in with hypotheses. I actually come out with hypotheses. And so it's a very different kind of research where most research is conducted under the notion that if you have a hypothesis, how do you prove it or disprove it depending on the method you're using? But ultimately, I would always say I'm not smart enough to even know how to form a hypothesis. How do I just go understand what causes your customer to say today's the day they're gonna buy. And so ultimately, it's about forming hypotheses. And so to me the roadmap should be about helping us put together the hypotheses an and be able to figure out what's the work we have to do to either prove out those hypotheses or form better hypotheses. I mean this is, how do I say, this is the nitty gritty, this is like, I love this part of the work. At the same time it's like I just do this work. I usually don't get a chance to talk about it. I don't tell many people about it. And I do it all the time, it's like second nature. So this is very refreshing to be able to kind of explain to you kind of how at least how I think about planning and looking forward and doing roadmaps. This is awesome.

  - Well, and that's the whole point of the channel is to get many views from many different angles to move the craft of roadmapping forwards.

  - I think that's a really good premise of it's a craft and you have to make it work for you. And just 'cause it works for me doesn't mean it works for you as well. And so part of this is to realise you have to find your way. And when you get really good at it, it's one of those things that then you have to pass it forward. And so my thing is we're all finding our way, and at the same time there's no, especially in the product space, there's virtually, there's some tools, but not many, right? And so we, we need, I'm not sure we're ready to standardise a road roadmapping tool, but I think we're better off actually thinking about roadmapping as a craft, like you said. I think that's really nice.

  - It's one of those things, I have come across organisations that have time-based, feature-based roadmaps who are kicking ass, delivering great value to their customers. But it's like, "If it ain't broke, let's not fix it."

  - That's right, well, and part of it is that at least study it to understand why is it useful, why is it successful. So you understand how to make sure that you can double down on the good stuff and as well as look backward. Any process should be improved, right? And so I'm not one to just like, "If it ain't broke, don't screw with it." But it's more about how do we think about where are the weaknesses in it, where are the struggling moments around it, where are the different things we can actually change to make it better? I think that's human nature. Our human nature is to make things better. It's just not everybody's aligned at the right time.

  - Yeah, and I guess that comes back to the jobs-to-be-done angle of like, actually, the roadmap is there to do a job. And what we have today might be working today, but we still might be able to do that job better by iterating on how we do it.

  - The way that I would say it is that the roadmap doesn't have a job. It does a job, right? And so it does a job for people. And so this is where you have to realise people are the only thing that have jobs. And so ultimately we wanna be able to understand, what are the people that are consuming the roadmap? What are the real progress you're making by using the roadmap? If the roadmap is the solution, what's the context in which I pull it out? What is the outcome I'm really seeking from it? And how do I make sure that that process is most useful for me? I feel like there's a lot of people who do roadmaps that are just useless, but they can't even call it useless, because at some point they just keep saying, "Well, this is what everybody else does, we should do it too." And it's not helping them. And so that at some point they have to actually figure that out. I call it whitewashing, a lot of people whitewash these concepts, and they don't realise they're deeper than they need to be, and if you whitewash it, you make it worse. Jobs is a very good example of that. You can sit around and think about the jobs your customer has, but I can guarantee, and I know that I'm wrong a 100% of the time. And so you have to realise that you have to go out and talk to people to get jobs.

  - If we've got this thing in front of us that's called a roadmap, what are the key elements that make it up? What's on the page?

  - The first orientation to me is time, right? And it's like, how are we looking at time? And, usually, for me, time is horizontal, not vertical. And it's where are we and where are we going. And it's about levels of clarity. Like almost the time horizon. Like how far out can I really see? And ultimately there's this first part that's on the left side that is about the next 90 days of things we have to do. And then as we play things out through time, they become less, I'll say, there's different elements to the roadmap. There's customer-facing features, there's processes, and then there's infrastructure. And we have to look at each one of those as in terms of the roadmap and how they sequence together, 'cause they all require engineers time. And so we have to look at capacity and capability in terms of those things as well. And so, as we start to think through the roadmap, we have to also think about kind of the load on the system and the capability and capacity of the system as we look at that roadmap. The organisation, I consider the product, the technical resources to go convert, the idea into code, right? We only have so many engineers, we only have so many designers, we only have so many who have different skill sets. And as I build projects, I have to manage that project set against the portfolio of all the other projects as well as the capability and capacity of the organisation. And so that's where, to me, roadmapping is about. It's a way in which to kind of see how things work, play things out, prototype things out, and then be able to see kind of how we need to sequence things and where are the interdependencies between them.

  - Yeah, I'm feeling an interplay of two earlier guests: Janna Bastow, who often calls a roadmap a prototype for your strategy. So there's that prototyping out. And then Simon Witkiss who talked about, it's also gotta be realistic and consider the capacity of the organisation to deliver, and those two things interplaying.

  - But that's ultimately the aspect of what I call the supply side and the demand side. The supply side is what can we do and what's the capacity we have? And the demand side is what do we need to build for whom and how fast do we need to build it? And so this is where you have to actually address the fact that if things are more important or need to be developed before something else, it literally has a dependency on the capacity, and you have to be able to play those things out. And so to me, these are all elements that to me are on part of the roadmap.

  - And so you talked about time going left to right, I've actually got my favourite visualisation at the strategic level these days is actually radial where it starts in the centre and goes out. 'Cause it makes people think a little bit longer because it's not that classic left-to-right timeline. And that pause I think is quite valuable. Beyond that, do you have any preferred ways of kind of visualising?

  - I don't, I think the most important thing is it's not how I want to visualise. What I've learned over the years is the way I wanna visualise it, nobody gets it. And so what I realised is like you have to design it for the consumer. And so I have to think about what makes sense to the engineers and to everybody else in the organisation as we go through it. And if I make it too, in some cases, too useful for me, I spend more time explaining what it is. And so I start to realise I have this balance of trade-offs I have to make between what's the best way for me to see it and where I can see it as a glance, and what's the best way for them to see it so they can actually make sense of it.

  - What sort of tool do you typically use to visualise it though?

  - Right now, so I work inside very large organisations and very small organisations, right? In large organisations, they have, I'll say, corporate tools to do that kind of thing. In startups we use mostly things like Miro and templates in Miro to basically walk through it. That way, we can actually keep it going and see how it evolves through time. The worst one is to do it in PowerPoint, right? I still see it in PowerPoint. I can't believe it, but I still see it in PowerPoint. And then there's some tools out there. I think June has some, there's some road roadmapping tools that are out there as well. But I haven't seen much of that. I've done mostly either big corporate stuff that's in, I'll say, things like Oracle and things like that. Or Miro is the most common tool that, I would say, most people are visualising it in.

  - I mean, there's a whole range of tools. Like even the physical product space, you have people like SharpCloud that are around you, but you've got people like ProdPad and Aha! and Productboard and Craft and Airfocus. There's a bunch of them. Funnily enough, all a number of guests in the near future or in the past mentioned there. I'll be honest, I go the other way to your perspective on PowerPoint. I don't want to host the data in PowerPoint, I want there to be a single source of truth somewhere, but I'm gonna render it probably in PowerPoint, 'cause it's the most flexible, so I can tune it for the appropriate audience.

  - Okay, to me it's a very limited space by which I can think through it. And so it's typically, I mean, so I'm very old school when it comes to like, I need to lay it out myself. So in my office here, I have whiteboards everywhere, and so that's, I have one room that's 360 degrees whiteboard, and that's where we do a lot of product planning, right? And so it's the fact that we can talk and argue and still whiteboard, but ultimately the fact is I need space. And so to me, PowerPoint just seems to be limited. I might render it, when I'm done, into PowerPoint, because the way people need to see it. But that's not true as much anymore.

  - And I think I'm with you. I'm seeing an increasing use of tools like Miro and Mural. Like yourself, I'm a big fan of whiteboards. There's a big one over there, a big one over there. Or going onto the virtual whiteboard as well. And that thinking space, I agree, but when I come to present or to share it, I usually end up backing PowerPoint.

  - So, I think that's the other part of this is to realise that it's a planning process. There are lots of tools you're gonna use as you go through it. And one of the tools is I need a way in which to capture the thoughts. Another way is I need a way in which to render it so other people can read it. It's just like any other design process. You have to think through who the customers are. You have to think through kind of what are the key deliverables that you're trying to get to, and then ultimately figure that out. And so it's very meta, if you will, about how we think about product. But we should be thinking about the roadmap as a product or as a process, and how do we design it to be most effective for us?

  - Even sometimes in an organisation, encourage a roadmap for the roadmap, for the evolution from where it is to where they want to be.

  - Yeah, I call that the second order, right? So I had some very, I'll say, good mentors. One of 'em was Dr. Deming who was the father of quality. And he would always say, "Whenever you have a problem, you don't actually have one problem, you have two problems. The first problem is you gotta solve the problem you've got. And then the second part is you gotta then prevent it from happening again." And those are two completely different types of efforts to figure those things out. So every time something doesn't work, we've got multiple things to do. And so that's why, to me, it's so important to understand both sides of this in terms of who are the audiences, and what do we really wanna build, and how do we actually figure out the interdependence between those two to figure out the roadmap. So the roadmap is really a thinking tool more than anything else.

  - So what do you consider to be best practise in roadmapping then, Bob?

  - This you can decide if you want to cut this or not, you don't have to cut this, but I actually do not like the concept of best practises. I actually hate them, because best practises, at least when I grew up, in the '80s and '90s, best practise is what meant we would figure out what the best practise was and then we'd never touch it again, because it's the best practise. And so it actually caused us to have stagnant thinking, because we seek to find what we would call the best practise. And the best practise is the best practise today. It doesn't mean the best practise tomorrow. And so we end up constantly stopping because we find the best practise and everybody follows the best practise. But then we work to the bottom as opposed to figuring out what's better, what's the next thing. And so to, what I can talk about is there's key elements that are part of these things, but I think ultimately you have to be able to get this to where this is a tool that's useful for you. and ultimately, it's not about best practise, it's the best practise for you, right? And so that's where I get very scared about talking about best practises. 'Cause it's kinda like the development process. Every organisation should have their own development process. Most people wanna talk about a generic one, but it doesn't help, right? So that's my little rant on best practises. So I don't think it's a useful concept for us to move towards as opposed to what are the key, the way I'd rephrase it, what are the key elements that have to be part of a good roadmap?

  - So maybe answer your own question then, Bob.

  - Yeah, there we go, okay. So I can answer that. I think the first part is, again, I go back to this 90-day piece of I wanna know, in this 90 days, we have fixed time, what's the scope we're gonna actually attack it at, what's the bet we're making with this 90 days of time? And so it's about thinking about that we've got this time, what's the best use of this time wherever we are in the business. And then ultimately the roadmap. So that's kinda like what we're working on and what's what's happening, if you will, in the next 90 days. After that, it's then about almost reassessing and saying what's now most important, but we've got reserve capacity to do certain things. And so it's about reserving capacity with the intent of getting outcomes, but it's not necessarily we've decided the way in which to do it. So a lot of times roadmapping is about figuring out the ways we're gonna do things, but it's kind of like budgeting. If you're gonna tell me I need to spend so much money next November, I'm guessing, I have no idea what I should be doing next November. And so this is where we have to be able to realise that most planning is guessing and that we can't create a level of precision to it when it's still guessing. And so this is where, as you move out farther, it's about actually having direction and magnitude than it is about the details of what we're gonna do because of the unknown. And so to me its, what are we do in the next 90 days? What are the struggling moments we're gonna hit, we're we're gonna be addressing after that, what are the big unknown questions we have to answer? And what's the capacity and capability of the system as we're using it? Those are the things that typically I have on the roadmap.

  - Makes good sense. So let's flip it on its head: What's the biggest mistakes that you see in people when they're road roadmapping, or people doing when they're roadmapping?

  - Well, I'll start with the consequences. When you have a bad roadmap, you end up having to explain it a lot over and over again. It's constantly changing, and so you're having to effect more and more expectations. And you're changing expectations, and so you end up becoming a slave to the roadmap, because, at some point in time, everybody wants a level of precision, they're treating it with a level of precision. You don't really have it, you're guessing it, and now you're adjusting all the time. As opposed to saying, "Look guys, this is guessing. This is where we think we're gonna be based on what we have right now in, let's say, January of 2024, this is what we're thinking about." But when we get to March of 2024, "Here's what we are thinking we were gonna do. Are we still gonna do that?" It's being able to do those things. And so I think part of this is that people think of roadmapping as a one year exercise as opposed to your point, a living, breathing document, a process. And it's about planning, not about the plan.

  - So whose advice on road mapping do you listen to, Bob?

  - So that's an interesting question, because this isn't something that I've studied a lot about, right? And it's not a rabbit hole I've gone down, and it's forcing me to think down this, but for the most part I've been one to seek experts. So like Marty Cagan, and Ryan Singer, and Jason Freed's another good one. Des Traynor's, another person I follow on that kind of thinking. And so I tend to have a network of people that I would call on to say like, "When I have this problem, what would I do?" And then they direct me in how I go. But like for the most part, I have an emergent notion of roadmapping. So it's about, again, direction of magnitude as opposed to precision. And there aren't many people I know that subscribe to that. So I haven't had much. It's the projects I work on that I use it this way, but my clients, at some point, I have to fall back to their planning process and their traditional roadmaps that I have to still work within. So I work within both.

  - So I think what you'll find, Bob, is actually your notion of roadmapping is more commonly believed in particular by the experts out there. Unfortunately, there's a lot of bad practise and existing corporate practise, I'm gonna say, that is a barrier to breakthrough.

  - What's so interesting is I'm doing some work in the HR space. Like what causes somebody to say, "Today's the day I'm gonna leave this company to go to that company," right? And the interesting part is that I feel like at some point accounting or finance are putting their hands in this, and they're trying to influence the level of precision because they wanted to relate back to money and, if you will, spend, as opposed to, "What do we wanna do?" And so you start to realise there's all these places where we're trying to account for something when there's nothing to account for yet, right? And so I think that's part of the thing is that people are pushing to make it more precise because accounting and finance, I call it the church of finance, wants to actually have their grip on it because it has implications to them. And when it changes, it changes their forecast, which has a huge set of implications. And so they start to realise, "We need this to be more precise," but it can't be.

  - Yeah, it's an interesting one, 'cause I very much, in the modern software, agile world, believe that you can't fund the project, you can't fund the product. You are funding the team, fundamentally. And what you're trying to do is get them to deliver the maximum value they can by solving the right customer problems. And, hopefully, the balance is that they're gonna deliver more value than they cost.

  - Well, so one of the things that I've been kind of harping on for a while is that we don't really have a good measure for the measure of good code. And so we're measuring everybody by the, if you will, the amount of keystrokes they make, the amount of code they write, there's all these, but those are all input metrics. Those aren't output metrics. And so you start to realise that, at some point in time, when we talk about quality, cost, and performance, you start to realise that the fact this is, at some point, we know how to do time and and cost, but the fact is we don't know how to measure the quality of the code, and these engineers are so expensive that we actually probably need a different way to work to actually help them think things through as opposed to just write code all the time. So I think that that's the revolution that I think that's gonna come is to look at a way in which to think about the quality of writing code, as opposed to, if you think about, how much code do they write that ends up in the final product. And you start to realise that there's a lot of code that's written that's just scrapped, which is poor quality from where I grew up. And so part of this is to realise how do we actually start to think about the measurement of good quality code and how to make code in a very different way than we do now. And I think that'll have a big impact on both capacity, capability, and the roadmapping process.

  - It's one of the tenets of scrum that you shouldn't be worried about, teams actually having slack and being a little idle. But if you go back to your church of finance again, they would look at that aghast. It's like, "No, we need to be lashing the whip to get as much out of this individual as possible."

  - That's right, and there's a rhythm. Anytime I've built something, there's a rhythm where you actually kind of there's intense paces, and then there's paces when you're apart, and then there's intense paces again. And so part of it's to realise that there's some merit to some of these things, and to try to actually just make it the machine that they want it to be as opposed to the act of creation is creativity, and you can't actually have that going all the time. You need this ebb and flow of thinking and perspectives to make all that happen. So tell me about some of the other guests you had and how they aligned to, to how I think about this. 'Cause again, I'm not an expert in this area. You're the first person to really ask me about it. I use it all the time, but it's one of those things I've never thought about in terms of other people doing it or using it

  - In particular, if we look at the software domain, because there are some differences in the physical product domain. The push towards a more outcome-oriented roadmap. And by outcomes, we have this whole mixture of what do we mean by an outcome. In the job-to-be-done world, we'd be talking about a user outcome, something that actually serves them. And that's what I love to see on a roadmap. But when some people in the product world are talking about outcomes, they're more talking about product outcomes or change of customer behaviour, something that's measurable like, I dunno, reducing churn. And for me, that's a great objective, but it's not very useful in terms of how I'm planning towards it, how I'm thinking about what user jobs can I serve that will help reduce churn. That's kind of the causal link. And if I'm talking to a customer with an external roadmap, they don't care about me reducing churn. They care about how am I helping them to do their job better, to live their life better. And so that kind of principle of bringing the outcomes onto the roadmap is definitely a growing area. There's no doubt a lot of pushback in particular often from the sales team, I find, more often than anybody else. The customer's usually quite relaxed about it, but the sales team themselves feel like, "Oh, you've gotta data.

  - The sales team wants features, they want features and benefits. And they want you to compete, as opposed to the outcome, because there might be four different features I could actually use to get to that outcome. And I have to actually assess which one it is. And sales just wants to push the next feature. I mean, that's how they're trained.

  - And in fact, one of the tenets I find quite interesting is if you put the job on the roadmap, or the outcome on the roadmap, it tends not to change that much. It tends to be quite a stable roadmap, because as we go along, we find one of those four optimum solutions instead of, saying, this is the feature we're gonna deliver, this is the solution. And then a week down the line, we've done some discovery, we realise, "Oh no, there's a better solution. We're still solving the same problem, but we've now gotta change our roadmap, 'cause we learned something."

  - The other thing is they make the roadmap dependent on technology. And so what happens is they're thinking about technology today for the future, but when they get to the future, there's now a different technology, and then they have to actually talk about four or five different ways to clarify everybody's expectations, 'cause they thought you were gonna go X and now you're gonna go Y. And you start to realise, at some point, the technological decisions don't need to be made there. It's more about the direction, and then you can make the decision in in the moment. But trying to think about the technology I'm gonna use a year from now is kind of like, "Wow." Those are tough decisions, especially in startup.

  - And the point is you wanna be giving the context to the technical leadership team of this is the direction of travel. So that then the technical leadership team can be thinking about, as they see new technologies, new opportunities, new ways that are working, "Ah, that could be a fit. Let's build the capabilities to be able to use it in 3, 6, 9, however, months time." If you had to distil your philosophy on roadmapping down into one or two sentences, what would it be?

  - Planning is guessing, and that what we're trying to do is figure out direction and magnitude, not precision. That would be like the overlying philosophy of it.

  - It's the classic question to ask, end anything with, is, is there anything else I should have asked you about roadmapping that I didn't?

  - I was shocked to hear the lack of role of finance or how finance integrates with the roadmapping process, because it feels like they've got their fingers in it, but I don't have facts around that quite yet. And so I was anticipating hearing a little bit more about kind of finance's need for the roadmap as opposed to products' need for the roadmap or sales' is need for the roadmap.

  - Yeah, I think I often see that need from sale, from finance, I should say. When it comes to the business case-level conversations, which may be something you develop in parallel to an initial roadmap when you are justifying some investment, and maybe you have to present a version of the roadmap on your annual budget round, that sort of thing. So that's quite common in large corporate.

  - Yep, it's the annualised process, and it's is just part of the budgeting process.

  - And I'll be honest, I consider a lot of it to be what I call corporate theatre.

  - That's exactly right. That's the best way to put it. I would say, I worked at Ford many, many years ago, and that's what I felt like half the time was all about getting, it was all theatre. There was technical pieces to it, but like to get anything done, it had to be some form of theatre. It was very interesting.

  - Always just like to close out with an opportunity for you to give a pitch about who you are or how can get in touch, how you could help.

  - I teach now, so I'm a professor, or an adjunct professor at the Kellogg School of Business in Chicago, or Evanston, Illinois. I have a very small consulting firm where I advise startups and corporations on innovation. And you can find me on LinkedIn. And then I've got a couple of books that might be of interest. One is called "Demand-Side Sales", which is to stop selling and just help your customers make progress. So it's using jobs-to-be-done to talk about the sales process. And then the other one is called "Learning to Build", which is the book I wrote around kind of homage to my mentors. I had four very powerful mentors, and they taught me five skills that kind of are the foundation of how I think and how I build. And so "Learning to Build" is the name of that book. And then we have the "Circuit Breaker" podcast, which is me and my business partner.

  - Been great having you on the show, Bob. Thanks for your time.

  - Thanks for having me on.