Is your roadmap a beautiful mess? | John Cutler

In episode 46 of Talking Roadmaps, Phil Hornby interviews John Cutler on the intricacies of product roadmapping. They explore the challenges of balancing structure with flexibility, the impact of company culture on roadmap success, and tips for maintaining alignment across teams. John shares insights from his diverse experience in product management, emphasizing the importance of embracing the 'beautiful mess' of product development.

John Cutler focuses on the messy overlaps and patterns of product—The Beautiful Mess (the title of his newsletter). Until recently, John supported product teams at Toast as Senior Director, Product Enablement. Prior to Toast, he was a product evangelist and coach at Amplitude where he interacted with diverse product teams and product leaders from around the world. There are few people in the world that have this kind of exposure, and if you follow John's writing over the last couple years I'm sure you can see the influence of this perspective. He has a background in product management and UX research, including B2B SaaS companies like Zendesk, Pendo, and AppFolio, and before that B2C, ad-tech, banking, and media. John is a prolific (or some might say obsessive) writer, with almost a thousand posts spread across various newsletters, blogs, Substack and Medium.

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

Is your roadmap a beautiful mess? | John Cutler

Phil Hornby and John Cutler

In the next episode we are talking to Becky Flint, CEO at Dragonboat. So watch out for Season 1 - Episode 47!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about everything roadmapping from the good, the bad, and the ugly. Today I'm joined by John Cutler. I'm pretty sure most of you will have heard of him, but John, give us an introduction anyway.

  - Hello everyone. My name is John. I have a background in product management and UX, and then before that, a life is a musician and startup founder, I guess. Early on, I made video games, which was kind of fun. Live in Santa Barbara with my partner and 5-year-old, and I love to write about product. I've been writing about product since maybe 2014 or 2015, probably written a post every couple days, every four, five, six days since then. I love exploring what I call the mess of products. I have a newsletter called "The Beautiful Mess," at the moment, and it's basically about how this is all a very messy, confusing space that we work in. And it pays for us to help to try to unravel that as we think about our work.

  - Absolutely. In fact, one of your tweets from, I think it was about 18 months ago, is one that kind of I refer to on a regular basis. If you're enjoying the channel, subscribe, hit the bell and give us a like. And it kind of goes to the first question I usually kick off with. I often ask, what's the purpose of a roadmap? But I remember your tweet was talking about, we ask the roadmap to do too many jobs. So, maybe I'll rephrase it as what's the job to be done of a roadmap?

  - Oh geez. So you're asking me, and I'm gonna list like 15 things. It really is contextual, and there are a number of jobs. So we could boil down some of the top-ranking jobs. I do think that for some users within your company, I'll put it that way, the roadmap is a way to communicate our current thinking on priorities, on sequence, on focus areas. If you maybe do it in the right way, on what we're more certain about and what we're less certain about. And for some of your quote unquote "users" internally, it's also communicating around when you think things might happen, realistically. I don't think that's something people want to hear, but there is a job to be done there related to timing and sequencing that people care about. The reason why I mentioned the jobs like that is how would you measure the efficacy of a roadmap? And is it doing that job? Is it catalysing the right conversations? For example, if your roadmaps never are a catalyst for a discussion about priorities, and if you still just have a million priorities, they're not really doing their job very well, are they? So I tend to break it down that way. There's a whole long tail of jobs. I think I was working with a friend recently, we listed, you know, 15 other jobs. But those are some of the top categories that I can think of. A great example of variations in a job is it's one thing to broadcast out something that you're generally sure people are bought into. It's another thing of when you're forming a roadmap, that early stage, when there's gonna be a lot of debate, there's gonna be a lot of tension and the conversations that you have are gonna be shaping what you do. So just that difference, if you overlay across all those jobs, whether you're diverging or converging, already you've got 12, 15 jobs. So it's an artefact that serves many roles within a company.

  - Totally agree. I know you call them users. And in fact, the next question I usually ask is, who's the audience? So who are those users, and who have those different views or different jobs, should we say?

  - Oh, I mean everyone. You know, there's been people on your team. You know, when you think about management, the management, there's so many directions in management. There's management up. There's management up and diagonal. There's managed to the side, where you're managing your peers. There's managing down diagonal, you're managing the people who work for your peers. You're managing the people who work for you. You're managing out to the customers in the world. You're managing out to the partners in the world. You're managing to the general company investors that you're doing. So there's a lot of who. I think you could draw some broad boundaries around, for example, the people who are involved in making the thing, designers, engineers, people who are involved in that, whatever you want to call it, the product org or IT for some people or R&D, or whatever you want to call it. That's sort of a boundary. And then, as you get, you know, you could say once you get outside that you have a myriad of roles, product marketing and folks in your other parts of your go-to-market organisation, sales. I think that one of the big questions for companies is how much to actually engage with customers themselves. So once you get outside, how much is this meant for outside the building? What I've found actually, which is funny is, and I tell this to all the people who make the roadmap software, whenever they reach out to me about, you know, "What's this mess all about," is I tell them that pretty much the PM's job is recontextualizing the same core bit of data in dozens of ways. So the idea that there's one roadmap, there's not one roadmap. There's sort of a core amount of information that gets recontextualized a dozen ways in your company. That's what makes picking tools for this kind of stuff very difficult, because it's very hard for a tool to handle that level of recontextualization. At that point, you might as well just write a document and put it in a slide. You know, that's usually why people end up that way.

  - Yeah, interesting. So, semantically, I think I phrase it slightly differently, but very much on the same page. I'll talk about how it being one roadmap, but multiple views. So it's that same core, single source of truth, but I'm communicating to a given audience and each audience cares about different things, needs to be communicated to in a different way. And that's that recontextualization you talked about there. So I think very much on the same page, subtly different language, but it's meaning the same thing.

  - One thing that comes to mind when you say that is this idea that there's even a source of truth. I mean, yeah, there is, but the source of truth is very messy. The source of truth is the combined, you know, assumptions and hypotheses and beliefs, and I think that people, they think, well, there probably is some source of truth, but it's the truth is messy. So it's a source of messy truth is realistically what's happening.

  - Yeah. And in that truth to me is the assumptions, the hypothesis. Everything is kind of through is a truth. You're making me think now that truth is too strong a word, but there is one data set, I think, as you phrased it, that we're rendering in different ways to communicate. And that's kind of the current, I think someone else in a previous sort of episode called it, "consensual reality." This is what we're all seeing is the reality. How close it is to reality is variable.

  - Yeah. Maybe it's the source of truths. Truths, right? Like yeah, that go on. I mean, a great example for that for people to dig into is, you know, the current level of confidence with something. I mean, I'm coming to the belief that our goal should not be alignment in organisations. In fact, I think that alignment becomes a sort of toxic thing. I think that the idea, you're gonna align on a set of truths, but it's this idea of like how to get along with people you disagree with. And he has this basic section in it, which I really like, which is, you know, "Simple collaboration requires alignment." Collaborating in any type of situation which is more complex requires coherence, essentially, where you can move forward while having very different beliefs on these things. So people who believe we have to agree on what the problem is and agree on the solution, he makes the argument, which is very persuasively that in fact we don't. We're not going to, and if you force that kind of agreement, it's gonna be difficult. And he gives example after example of countries that have worked through their problems or people who've worked through their problems, where having very different beliefs, are able to make progress and find things that meet their needs and things moving forward. And I think that that's something we don't talk enough about at work. We sort of have this veneer of alignment, assuming it exists, instead of being okay with that like source of truths. And I think that that's something that you have to constantly juggle when you're in this work environment It was compelling argument.

  - It sounds like alignment and agreement are being conflated a little bit there. Whereas, I would separate them still a little bit. We can be aligned that this is where we're going, even if we don't all agree.

  - Yeah, exactly. And that's where, you know, the words like congruence or coherence or, you know, you could have somewhat congruent strategies or coherent strategies that don't necessarily mean, you know, everyone agrees on every single item, or that's what the company should do. A good example is there'll be some people in your company who want to realise short term outcomes and benefits. And there'll other be people who are maybe tuned more into the long-term sustainability of the company. You know, you're not gonna, there's many reasons why everyone believes what they believe and do those things. And you know, the worst option would be to find the middling option, which tried to placate everyone. And the option of thinking about it more as a sort of polarity, or like a liminal space between these groups where it's like, yeah, guess what? Some people want short-term outcomes. Some people want long-term outcomes. Let's not bang our heads against the wall trying to find the best trade off between those things. Let's allow there to be that some level of dissonance as we're moving forward, and we'll learn our way forward. You know, we'll get through. So it is an interesting thing to, you know, bringing it back to roadmaps where it's okay to put big question marks on things. You know, it's okay to embrace that there could be tension between groups about, you know, about certain elements of a roadmap maybe. Of course you need to create an environment where it's friendly to that type of tension, but it's something to consider.

  - Yeah. And I guess that comes back to the whole, do we have psychological safety? Do we have trust type thing in terms of creating high performing teams, which then allows for that disagreement without it getting personal? So if we put all these things together, then John, how are they informed by vision, strategy, objectives? You know, we're saying that maybe we can't have fully aligned organisations, but we've gotta have a goal, a direction and be executing towards that. How's that work in your mind?

  - Here's one thing I've realised about this is that people assume that a narrative exists in a company, and that's not exactly how it works. So, for example, there are companies that pick these high level pillars that everyone nods their head at. And realistically, they were never meant to really align the org. It's just much more for show. It's a sort of show of like, here's some broad categories where we're generally aligned. But, what those companies are doing is they're pushing down the work of actually working out the details a couple layers down to different folks in their company, and they're working it out. And some companies do perfectly fine like that. In fact, the people in the company, if they say, "You know, we don't really look at those decks." Like that's the sort of ambiguous for show vision that we have. No one ever goes back and looks at the Vision doc. No one ever goes back and looks at the Mission document, but somehow it works itself out. And there are some orgs that do that. There's other organisations that insist on this very sort of strict cascade of things. You know, we believe this, and then, therefore we believe this. And this is why all our goals exist. And then, there we're gonna go, and we're gonna get aligned that way. The reason why I mention that is, you know, anytime I go on LinkedIn and someone is like, "Okay, we have gotta start with the why and the who or the thing." And anytime people put these little pyramids of, we're gonna start with a mission and vision, or anytime those layered thing, when you actually observe how companies work, they don't work like that. That's a high, that's an abstraction. That's not even an abstraction. It's just a narrative sort of thing. It's much more that if you go on Wikipedia, there's this great article about something called the Garbage Can Theory of Organisations. And you should check it out because what it says is that organisations are not this kind of logical entity that there's many cases where organisations are solutions looking for problems, that the people have solutions looking for problems, and we kind of work its way out. The reason why I mention this is that I think people over index on vision. They imagine that the strategy will be this book strategy. Like they read in "Good Strategy, Bad Strategy," and they'll leave themselves disappointed, because they're like, "My company doesn't have anything. It's so unclear. I don't know. We don't have a strategy like I've read about in the books." And people will say, "Well, where's the pyramid?" And then when you give them the pyramid, they'll say, "Well, this doesn't make any sense to me. It's just fluff." And they get all frustrated about these things. And so, I'm saying all this, because to get an organisation to move in a somewhat coherent direction, there's many ways to achieve that. And it's very cultural depending on how that's gonna happen to do those things. And often you move in that direction in spite of what you try to do. You know that there's just the magnetic pull of a particular direction, and that's why you move in that direction. So that all sounds very philosophical and like abstract, but I think that like, you know, from a very practical perspective, you need to feel out the real power of those things in your organisation and spend time on them accordingly. If you work in an organisation that has the sort of slide deck with the three pillars and the vision and the mission and the pyramid, and no one actually refers back to it ever again, don't waste your time trying to clarify that. The organisation has told you that that's not how it operates. Spend time trying to figure out how decisions really get made in your organisation and how the strategy really gets set, and focus your energy on that particular thing. And if it's the incentives, how budgets get put out, that's where you have to focus your energy to align. If it's the narrative with the board, that's where you need to focus your thing to align. Because, companies will have those four pillars, and no one tells you about the actual conversation in a back room that the board has with the founders of the company or something. So very practically, I believe in what you said, and I think that strategy, vision, mission stuff is important. However, I think that how that plays out in companies is very contextual. And as a product manager, you need to sort of not, don't waste your time on the places that don't mean anything, just find out where those decisions are actually getting made. If it's the sales goal, in a lot of companies, it's literally the sales goal that gets communicated to investors, a revenue goal. You know what? Not gonna change that, so might as well hack that system and figure out how it can help support your roadmap.

  - I've spent quite a lot of time kind of around product people in that particular space. And I do feel that they feel the need more than any other function to have this clear vision and strategy. I think because, as exactly as you said, they kind of feel like we don't really have one, and therefore we're not doing it right. We're not doing it properly. And what I almost feel like you just did is give them permission to have that messy setup.

  - Well, it's also understand how decisions really get made in your company, and then think about what you need to do around that particular thing to get that level of alignment. And this is where I think that it's just very, very difficult. You also need to then, once you understand how things really happen, you can think about the adjacent possibilities. Like, oh, there is this meeting where this type of thing happens, and basically it's all sort of, everyone just waits until the budget's approved, and then that ultimately informs the plan. That's a good opportunity to get the right insights into that particular meeting to see if you can do something better. The same thing is, even people with, I was chatting with someone who'd worked at Google for however many years, eight years. He's like, "Actually we suck at OKRs to do those things." So the same thing that if you're a PM and think, it's just about getting all our, if we could just get our goals straight, we would be aligned. No, it doesn't. So you have to think about like what is the, there's the stated way of aligning, which might be the OKRs, but then there's the real way of aligning, which might be through influence. It might be based on customer persona or the sales quota or the whatever. And you should find that, and that's probably a good bit of advice for folks.

  - Totally love it. I remember I used to talk a lot about corporate theatre, 'cause of having to play the games in the company to then create a more fruitful environment for my organisation. It's like, okay, I'll do the annual budget cycles. I'll worry about playing the corporate theatre. This is in a multi-billion euro kind of German organisation. And then how are we gonna actually take that budget and use it in the real world? Quite different, 'cause we're gonna try to execute in a more progressive model. Let's see how it goes. And then, but there was me acting as a layer to kind of give that theatre back to the organisation. Because it was otherwise stifling the things we were trying to do.

  - Well a great example of this is think how complicated we make it for ourselves. I mean, realistically, you should be able to go to each team and say, "Give me an honest one-year roadmap. You can use whatever system you need to be able to keep it honest, and just keep updating it. Keep it relatively updated." In theory, that's completely possible. In theory, that's completely possible. But do you notice what gets in the way of making that happen? You know, there's a period in around August, September when if you're on a yearly budgeting cycle where people say, "Well, I don't feel comfortable putting, I don't know, I can't put stuff in the roadmap for January and February, because," it's because of budgeting. You know, they're, they're worried, they don't wanna make these, they don't know what the priorities are. If you've also noticed in big companies in around March or April, you're only just getting going on the prior year's thing. So realistically the magic months of the year are March, April, May, June, July and August. You're only really working and aligned for six months out of the year. The back end of the year is trying to finish stuff up and sort of anticipating a big change in priorities. The front part is just trying to figure out how you're gonna work together to achieve those things. That's the reality. And so, I think it's funny, because conceptually the idea of like each team will have a roadmap. They'll have a general sense of where they're going. People will look at it, they'll comment on it. You'll revise it. You'll keep it aligned with the company priorities. All that's like terribly quaint. It's too simple to be real. Like, imagine if life could work that easily. It can, by the way, but we make it so much more complicated for ourselves because of these other, you know, the reality of how the flow of how it is for organisations. So I think that that's, you have to, you can either sort of fight that, or you can nudge against it, or you can go with the flow. And so, that's sort of an option that people have to work with.

  - It's interesting, I was reading "When" by Dan Pink recently, and he actually makes us quite a strong case for those rhythms and those kind of patterns that it's quite natural and human that we create those cycles. And Luke Hohmann in his book "Software Profit Streams" talks very much about the rhythms and the events of your industry on your organisation. Something I always used to do in my previous life was map the company calendar. Like what happens, it's like every August people seem to be surprised that we're going off into strategy season. Every October seem, people seem to be surprised that there's another budget cuts, yet it happens every single year.

  - You know, there are efforts, like this beyond budgeting thing, which is really interesting, and there are efforts to change that and to unpack these annual cycles into different things, which is very interesting. But, for many companies that might be a step too far, at least in the short term to do it. And so, I think that when it comes back to something like road roadmapping or whatever, you just have to be aware of your company rhythms and where these things fit in. I just wish people could just maybe even lean in to the theatre. I mean just have a big block on your roadmap that says, "pending the strategy reset." "Hey, we can't tell you what it is gonna be beyond six months, 'cause we don't know." Like, how funny would that be?

  - I think I almost went the other direction of I'm gonna assume I'm getting the money, and therefore I'm gonna plan for ahead and keep going, and almost make it reality. Because, if I'm talking to customers about that being the reality, the budget's gonna follow.

  - That is, and and this is, it's amazing you said that, because I do believe that that strategy for a lot of sort of senior PMs or frontline PMs, that's all you really can do. And I think I've been mentioning these question marks and mentioning this type of thing where, you know, you walk into a meeting and saying, "You know, based on the assumptions that this is still important to the company, that we're still gonna prioritise this persona based on the assumption that, you know, we're going to either, you know, keep our team size stable or grow our team slowly to be able to do it. This is the general direction." Another great point about this where people get into the roadmapping thing or it overlaps the road roadmapping discussion is, you know, I've seen people have these roadmaps, and then they'll do this kind of above the line below the line kind of thing where they say, you know, "Well if we get funding we can go here, but if we don't, we can go here." The mistake I think of that is that if you have a healthy team that's working and getting stuff out there, yes, maybe adding a person might generally move it a little, You know, you're moving it a little bit. You're continuing your mission, but you kind of maybe accelerate. And it's hard too, if you add someone to the team, honestly, sometimes it slows down. And you don't wanna add someone to every team. So the amount of the road roadmapping stuff that overlaps either delivery cadences or assumptions about velocity or assumptions about how fast the team is moving, the example that I give is, you know, I met with a team and they show me their 2024 roadmap, and it looks like they plan to finish 24 things. I just count. They happen to use a calendar roadmap, and I'm sort of following the end of every little row. And I said, "That's 24 things. Well how many things did you finish last year?" "Three." "So how is it gonna go from three to 24?" "Oh, everything, for sure, is gonna finish right in the beginning of the year to do that." And the interesting part about this is that was used as some form of budgeting. And so you need to be very sure about the job that your roadmap is being used for by the people you show it to, because there's probably a better way to visualise that in a way that will communicate the current sustainable pace or lack thereof of the team, so you're not like entering into a kind of budgeting hell to do that. So that's a tip for people is to know that your roadmap will also overlap the budgeting and finance discussion, so.

  - Absolutely. And yeah, we, funnily enough, you talk about different visualisations. My cohost and I, we've kind of identified 12 different visualisation styles that we're writing a set of visual guides based on at the moment. I started talking about it literally last week in Cologne at an event. And it's like some of them break that left or right, for example, time horizon or time channel, which helps break some of the mental models that people have, but it's still showing direction of travel.

  - It's funny. I didn't get up to 15, we can share it in the show notes. I remember, you know, this post I wrote, "11 Ways Different People Visualise It." And so it is true, there's so many different visualisations that can inspire different conversations. And I think that that's something that people don't realise the psychology of that. In fact, even the, I think for people who've done this a lot, they probably, this is very simple to them, but I met with a product leader recently who I just challenged them on this sort of swim lane, calendar-based roadmap. And the funny thing is that they pinpointed one of the problems with it is that having blank space on that roadmap makes it look like the team's not busy. So it's just on the most basic level, you have a visualisation out there, and it's got blank spaces. So someone will say, "Well, can't I play more Tetris with that calendar to do these things?" And then the other thing that's kind of funny is they're just very bad about communicating sequence and priorities and the overlap between maybe estimates about time. So if you were to actually re-visualize that in a now, next later roadmap, you'd be forced to maybe force rank these things by their priority. Whereas, if you look at a calendar roadmap, you're like, "Well, is that starting after that, before that because it's a lower priority, or just because when we think we're gonna finish that thing?" "And oh, I'm making the assumption that you must have five people on your team." It's like, "No, no, the swim lanes are actually priorities." And so you can just see how these very minute differences in visualisation can inspire vastly different conversations, and or not trigger the conversations that are necessary for you to have. So you need to be hyper, hyper aware of that. And I think a lot of people know it, intuitively, because they find themselves a little bit nervous. You know, they'll they'll say on LinkedIn like, "Don't put dates on your work or whatever." And what I say to that is, "Hey, guess what? Generally wanting to know the sequence of when things might be done is a completely valid need in your company. However, you conflating that visualisation is what's getting you into a trouble." There's another way to visualise cones of uncertainty and when generally you might think things might land in a way that doesn't hurt you, and you just need to know about that. So I think it's just, the visualisation side is something I'm really fascinated about.

  - Likewise. One of the things I've come to realise is I did a lot of graphical visualisation in my teens, and I'm suddenly realising how important that set of principles and things that I learned there as I'm starting to see the value of them now as I'm a lot older. I kinda liken it, I know I'm not liking myself to him, but how Steve Jobs did a class on typography at college, and then that informed his sort of desire to have great typography on the Macintosh.

  - That's awesome. You've taken your teenage obsessions on to your professional life. That's great.

  - So, we started to talk a little bit about the visualisation. So, if we're thinking about a roadmap, let's get concrete. What's on this thing? What's it made up of?

  - Depends. I mean, you can do, I've seen roadmaps at like five different levels. Some of the ways that I divide up a roadmap, I think that is probably similar to other people is there is this sort of level of things. And so, you know, an example is I'll say to a team, "Let's get up at the level of," I have this system of one to threes, which has always worked well for me. So you can think about work just in terms of time. And it goes from, you know, one to three hours, one to three days, one to three weeks, one to three months, one to three quarters, one to three years, and one to three decades. So, one simple way you could think of a roadmap is like what level are we on? Are we in the like one to three quarter range here, where you'd only expect, you know, you get a team, it's like there's six things on it. Like, once you're at the one to three quarter range max, you're gonna have like six bets, whatever we want to call them, units of thinking, units of energy. You're gonna be at one level to do that. I find that generally a roadmap that goes anywhere below the one to three month range is probably not gonna do the team much good. It's already getting pretty too tactical on that sense to think about things. The one to three year level is really, really interesting, because it kind of talks about the broad strokes and forces you to think on that particular level. So that's like one way I've thought about like the level and what goes on it. And I just call them bets, but I could just call them foos, because I'm tired of believing they should be called just one thing. I think companies should name this stuff what they want. You know, there's, you know, like for example, there is a difference between a project and just a general stream of initiatives that are going towards a goal. You know, so what do we want to call one an initiative? Want to call it a project, that, you know, I like the word bets. I wish that everyone would just call everything on their roadmap a bet, but that's just me to do these things. And so, I think you have to think about what the container is that you're talking about. And time is one way to do those particular things. I think realistically too that, you know, I have this framework called mandate levels, which sort of talks about what level you're working on. Is it a do this type thing that is it a do something that does this type thing? Is it a help this set of personas achieve some type of goal? Is it move a metric known to improve long-term business outcomes? Or is it all the way up to, you know, own a financial outcome over multiple years? That's another way you could think about roadmaps. It's just sort of the sphere or the mandate of the work involved in that. One thing I've learned is everyone argues about, you know, problems versus solutions or output or, you know, outputs and outcomes and all that. It's all there no matter what you do. It's just the level that you show it. Someone's gonna come to work wondering what the it is, and someone's gonna come to work interested in what the outcome is. So I've kind of thrown up my hands and come to the conclusion that it's gonna be a mess no matter what you do, and you just have to work across all these spectrums anytime anyway. So that gives, you know, you can put anything on it as long as you're consistent and it helps the discussion, and it's relatively consistent with what they're doing. One thing we learned a lot, I learned a lot from doing all these North Star workshops is that one thing that's missing from a lot of roadmaps is a roadmap itself is, if you think about, I call them frames, but you could think about there's the work frame of the world, the value frame of the world, the budget frame of the world, the team view of the world, the goal view of the world, the sort of highly customer centric view of the world in terms of their outcomes. There's many views. There's the architectural view of the world. There's many different frames we can think about the work that we do. I think most roadmaps give a little bit of lip service to maybe the value, the stable value view of the world, but maybe don't as much as they they could. And so, what I mean by that is when we did the North Star workshops, you figure out this kind of North Star metric, which is leading indicator of sustainable differentiated growth. You think about a series of inputs that guide into that, that are stable. You know, at Amplitude, I remember our North Star and our inputs were stable for four years. They're not changing. They're the same mental model for value. And then, you could link in roadmaps into those particular things. So that's what's missing I think for a lot of companies on what to put into it is they'll have roadmaps and they'll have goals, and then they might even have like delivery plans or they might do that, but I'm not seeing the stable thing that you're hanging all that stuff on, the stable model that you're hanging that stuff on for in the span of years to do those things. So it becomes this very reactive cascading kind of thing, you know, where, you know, if you can't figure out a model that remains, or set of models, and it can be a customer journey map, it could be a North Star framework. It could be a funnel, it could be some customer health model that you have. It could be a list of capabilities that are gonna last for a long time. If you can't come up with that model that stays foundational and stable, it undermines the efficacy of all these things, and then it causes teams to overburden their roadmap or overburden the goals, because there's this missing... You know, so one practical way to think about this is teams often have, you know, swim lanes in the roadmap that are centred around some kind of goal, but you don't really know how that goal fits in to the broader scheme of the company. It's a little bit disconnected. So I don't know if that helps, also, people think about it is that, you know, don't overburden your roadmaps necessarily to try to fit all of those frames. It pays to be specific and to flesh out the rest of it, so that you can make sense of what you're doing.

  - Yeah, I guess those frames may relatively well overlap with the different views that some of those different audiences or users care about from earlier.

  - I love that. But, one of the things that you hinted at there, which is incredible, is that when you're small and you're a startup, these frames overlap to the point where you don't think different. So here's an example, like the architectural view of what you're doing and the team view of what you're doing and the work view of what you're doing, the goals view, when you've got this just one team, you just look at the team, and that's called the App Growth team. I don't need to see their roadmap. I don't need to see their roadmap. They're called the App Growth team. Just tell me what your goal is, explain what the model is, explain what growth is, and tell me how you're gonna move those particular metrics and like, and then give me a reasonable like just heads up about what's coming down the pike to the rest of the company. And all those frames are together, right? The like, oh, that's why you budget that team to do app growth. That's their goals must be around growth. Oh, their architecture must be the stuff related to how we're gonna get growth. As companies grow though, real world is that these frames sometimes drift apart. And this sounds very abstract, but it's very practical for people, which is when you're in a company that feels like there might be debt or there's disconnectedness between the org chart and the work, or you know, you've got, when you feel that tension like there's lack, there's this incoherence problem, it's because these frames have been drifting apart and have tension. And that's really kind of the job of these, it's never perfect. You're never gonna have a perfect thing. You're always gonna have these projects that overlap all the teams in your company. And so, when you think about your roadmapping and stuff, just realise that when things are growing fast and there's a lot of things, you need to accommodate the fact that these views aren't always one and the same of what you're doing. Because, when you're small, you can just have one view and everything's okay, and it's good.

  - Yeah, I mean, and interestingly, it brings me back to one of your earlier points where you talked about how when the roadmap can look too empty and people feel like people aren't doing anything. Sometimes, taking things from one of those other frames, one of those other views is what happens to stuff it in to make it look full. We're doing this rearchitecting work, so we'll put that on there, because now they know what we're doing, and we don't look like we're not doing anything.

  - Oh, and well one of my pet peeves is not having just one roadmap for the engineering. And like when I used to hear people say, "Well we've got our customer facing roadmap, and then we've got our tech roadmap." This is a great test case for what we're talking about. They've separated the roadmap for a reason. Now, when I've talked to people who are in that situation, one thing that the technology side of the house will say is they'll say, "You know what, we don't want this to be micromanaged the same way that PMs are micromanaging their customer facing roadmaps." So, you know, the PM's going to show the rest of the company, here's the roadmap. Now, if you included the technology items on that roadmap, what question does that trigger? Some executive is gonna look at it and say, "But why are you doing all this other stuff?" And so I had a CTO one time tell me it was super funny. They're like, "Oh I don't wanna put my work up on that, because if I do it's gonna be micromanaged away. I think it's necessary. I think it's important. Product, you take 50% of the capacity to do whatever you want to do with it. I will manage the other 50%, and no, I don't want it visualised by the rest of the company." So this is a good example of where, in theory, back to keeping it simple and how this world could be completely uncomplicated, if we could all be exactly the same and think exactly the same, you'd be like, "Well why not just put it all on the roadmap? I mean, how can you know where your chips are being played if you don't have it on one roadmap?" In the real world, it's like, "No, I don't wanna put it on that roadmap, because I don't want to be micromanaged to do those things." Back to that point though, I do believe bringing those views together if you can, is smart, if you can create an environment with that type of safety, because the downsides I think outweigh the upsides. And then, of course, the internal product, product managers come back a year later and say, "No one respects our work." And it's because, yes, because your bosses decided that they didn't want it on the same roadmap. So there's always, you know, it's never a free lunch for this kind of stuff, but it is a good example of how these frames and stuff can make life easier and complicated at the same time.

  - Yeah, I mean I guess that's where it comes to my different views. Like, some audiences I would show the technical side, but maybe not with the customer. Again, it's like, 'cause they probably don't care.

  - Yeah, that's a perfect, and another thing too is how much detail do you want in there? If the technology org is generally making it easier to deploy and put stuff and the product to be more stable, and you might wanna put a performance thing on that roadmap that you shared to customers, because it's gonna mean something. And you know what? You might just wanna have one lane, which is basically like keeping our team shipping quickly, shipping fast for your benefit. You don't need to break down all the nitty gritty of those internal things, but you could hint at it to have a good discussion with your customers about, "Hey, we might not be shipping as quickly as you think we should be shipping. However, that's 'cause we're allocating some percentage of our time to making sure that we can keep shipping this way from now until eternity, right, to do this." So I think that you can make strategic decisions about what you display depending on the audience. That's a good maybe takeaway.

  - So, let's go a little bit philosophical. We've already gone there a little bit already, John. What do you consider best practise when it comes to roadmapping?

  - To me, best practise is basically building the house, and then layering the roadmap on top of that. And so what I mean by that is like building the foundation is maybe a better way to put it. We talked before about strategy and mission and things like that, but I do think that, I tend to think about this as kind of a loop, this data informed product, which is something I thought a lot about while I was at Amplitude. And first you need some kind of strategy, some kind of opinionated belief on how you're gonna win or like whichever philosophy you buy into, you need some kind of strategy over it. Then, I think you need to translate that into one or more accessible models in your company. And like I said, that could be a range of like a driver tree or customer journey or customer health, like something that then you can talk about, 'cause strategy can be pretty vague. And then, if you translate a strategy immediately into projects or actions, that's sort of skipping over a loop, you know, so that's kind of making the big jump already to what you wanna build or what you wanna do. So I think that the intermediary step is translating that strategy to one or more accessible models the team can think about. Then you need to add some level of measurement to that for those models. So, very practically, you start with a strategy. You say, "You know what? We're gonna use a customer journey mental model of how things are. We're going to use a customer maturity model of how things are. We want to nudge our customers up their levels of maturity and their use of our product, and we're gonna use a general sort of growth-oriented driver tree." So those might be the three models that you pick. So the next step is just make sure you can reasonably measure that stuff, either qualitatively or quantitatively. Like, do we know what the parts of the model are? And then, this is where the roadmap comes in. At that point you have to identify your leverage points. Like where are you gonna be able to have the most impact given the models you have and the strategy you have to be able to nudge the organisation forward? And the reason why I mentioned those three things before is I think without those three things, your roadmaps are gonna be doing too much work. You're gonna be overburdening them with both the model. You're gonna be trying to inject some strategy into them, and it's gonna be difficult. If you do that legwork before, then you get to a fairly straightforward, like what are our opportunities and leverage points across different time horizons, like one to three years or one to three, whatever. And then, what are we gonna try? What bets are we gonna run? What experiments are we gonna do? What are we gonna build to move that? And then, you have to kind of measure the impact of that and go back. When I say best practise though, I think it's very important to know you can achieve those primitives in many different ways. So the words that I'm using like bet or leverage point or whatever might seem arcane to you, and that's completely fine. But, I think that the general idea is like, we need to have a general sense of strategy. We need to get it out of our head into some set of of models. We need to then think about what our our opportunities are, set goals around those opportunities, where are the leverage points, then we need to go and think about where we're gonna get to. So I think how this translates into a roadmap is generally your roadmap should have, or when I've seen best practise is at least is that the team is pretty adept at going from both the leverage point view of the world, what are the opportunities down to what they're gonna try the more work-like stuff. And then, I think when it comes to communicating to the rest of the org about timing and sequencing, I think generally the best practise is doing that without screwing yourself up. Like, how do you give an honest appraisal about where things are and what's flowing through the system so that other people in your company can plan for it without glossing the stuff over and making it feel like it's realer than it is? Or, you know, you just gotta communicate responsibly and reasonably to a particular company. And then, I think finally, is just getting the right types of feedback across all those things I just discussed to make sure that the team, you know, you're not surprising the team, or you're aligning people in the right way. So, I don't know, I just described it like a sort of process, but that's how I generally build the house for teams, you know, build the foundations to get teams to the right spot.

  - I know process is an evil word to many people, but actually it's a super important part. I think I quote an old boss of saying, "Good process shouldn't get in the way of good work or good business, but it is there to enable and empower us."

  - Well the other thing, I think yes, process gets maligned. I think that, yes, because sometimes people don't agree that you can achieve these things in different ways, right? They're very prescriptive about how you would go about doing it. I also think that if we just change the word process, and we said like somewhat of a common vocabulary. If you don't, forget about process for a second, can you have the discussions that you need to have and are you reducing the cognitive load of team members? And are you giving them an interface to interact with the rest of the company and the rest of the environment? I think that people assume that process means centralization and standardisation in ways that are gonna reduce the productivity of teams or reduce the creativity of teams or do that, but try driving down a road without road signs. You know? Imagine you go to the supermarket, and there's no way to check out really. You just have to find someone and tell them that you want to buy it, and then they sort of try to think about, I mean, it wouldn't, you have to find those things. Another example of that is imagine you're in a company, and I say, "bets," and the other person says, "initiatives," things. Now, the danger of course are in some companies they say, "Well, we're gonna call everything a project, or we're gonna force everything into this scheme." And then if it doesn't reflect, the tip, the thing I've learned in the last couple years is if it doesn't reflect reality, people will either phone it in and pretend. They'll just do whatever they want to do and just decide, you know, just check the box on whatever sort of standard language you have, or you'll take the creativity out of the room. You'll force people into a different reality. And so, generally, with the stuff process, and a great example is people will say, "Okay, every team needs a strategy, and every team needs a vision." Now, if you're looking at the strategy and vision, and there's something missing for what you need, like maybe it doesn't reflect reality, you'll either just zone out from the company and be like, "Oh God, I've seen that deck again for the million times. I'm just gonna do whatever I want to do." Or you'll just conform to it and just check checkbox kind of way to do it. So I definitely am a process believer, but I think that if you think of it as common language, if you think about it as the lightest amount of central language or centralization, you need to do that. If you think about it reducing cognitive load for people instead of increasing it, then you're just, it's like an internal product. Forget the word process. Like it's just how we work can be a decent way. And I think actually in it's pretty uncertain times these days with how companies are and the funding and whatever for the company is. The last thing people on your team want to be doing is knowing how to plug in to whatever you're doing and participate. And so, that's a quick win to just make it accessible and not have people scrambling in certain ways. That's my take at least.

  - If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Think of them as products.

  - And is there anything I should have asked you about roadmapping that I haven't?

  - I think there's probably a good question around seniority in a company, and what's reasonable to expect from a frontline product manager for their space. You know, so I think that one thing that's come up a lot is that this information is all very available to people. And you have folks who are, you know, PM working with their team in a much larger company. And I think they're aware of some of the practises, and they're aware of maybe how one could be more outcome focused or things, and maybe their company is not bought into those ways of working. But, I think there's probably a good question around, okay, you get this all, and you've internalised it, and you're sort of, you're there on your team, but that's just not how you work. You know, you're on the hook to give this, you know, annual roadmap. All the frames are collapsed into each other, and no one even acknowledges that, you know, what to do? I think that the answer for those folks is a little bit what you are getting at, which is maybe hack the system a bit. You know, maybe your company requires things, you know, like list all the projects you want or something. The advice that I tend to give there is no one's gonna fire you if you do an extra layer of work. You know, so you could always go in there and say like, "Okay, I did this thing you want, the projects, but I've augmented the roadmap view you want with the three customer problems that I told you about." Or adding a little assumption line at the top like, this assumes this and this. Or, when you, they, you might be asked for this prescriptive thing, but you fold those under the key levers that you exist. So that's a very practical example. It's like, well we need this very prescriptive, project-based roadmap for the year. Please give it to us in a calendar format about when you think things will be done. And that you can just nudge the system a little bit. For example, you could add confidence intervals at the ends of the row, at the ends of your work items. So you're like, "Well that's, it could range this way." You could do a scenario plan, and you could say, "Oh, we ran a Monte Carlo experiment, and this is like this is the distribution of think times that these things could take assuming that we're asked to do this." You could add like row row labels to this, or like tags on top of them that this hits these strategy points. So, just hack the system, you know. Throw in an extra slide that said if we view this as a map, or you know, graph of some kind, here's where all the items would fit. That's an example of one that I've seen in person that just worked great. Where people, you know, they show the calendar roadmap, and they said, "If we were to view this in this other way, latched onto something like a driver tree or some other things." And then basically, all the work are these little solutions, you know, in the opportunity solution tree thing, it would be these little solutions of the leaves. And it kind of blows people's minds, you know, they're like, "Oh, I love this calendar based roadmap," and the next thing you show, it's like, this is how it all lines up. Sometimes people who do that in that meeting, the people say, "I like that view." And sometimes it's even an executive, because the executive isn't mired down in this whole world of like, why does the engineering team require these estimates, and why do they think they need to put it in Jira in a certain way and all this. And they see that value-based view, and they say, "I want that for my next presentation. Can you give me that?" So just think about how to hack the system is sort of how I generally think about it.

  - We often even suggest you might think about a roadmap for your roadmapping, where you are now to where you want to get to when thinking about the stages between there.

  - One other tip there is, I really, there's a book by someone named Julie Dirksen, and she wrote, she's written two books, "Designing for How People Learn," I think is the first one. And then, the next one is called "Talk to the Elephant." It's a kind of behaviour design book. And if you want to think who's influencing me about road roadmapping at the moment and thinking about it, it's actually books in behaviour design and other things, 'Cause I tend to think of them as a product and what behaviours would we observe if this is working? So that's a very good question for your team. Like what behaviours would we observe on our team if whatever these things we call roadmaps, whatever are working in the way we wanted them to work? And you might say, "Well, we'd be having more discussions about customer value." You know, we would be having more clear understandings of our priorities, and, but even that's not a behaviour. What does that mean, we'd have more clear understanding what the priorities are? Try to get even more specific to the behaviour. You know, we would be in a position where we said, "no" more often, but we would point to the artefact that we have, And generally the person that we said, "no" to would understand why and how that fits. So I love the book, because he talks about specific behaviours. And that's a hard question, because you notice, even when I was just telling you that, the first thing I said was not a behaviour. Like we would prioritise stuff that means X. I guess that's a behaviour, but you're not telling me what we would see and observe. The reason why I mention that is if you're thinking about a roadmap for your roadmapping, a good way to think of it is how often are we experiencing either the behaviours that are working for us or not working for us? A great example here is the kind of thrash that happens on a quarterly basis. You know, where people, they don't, you've done all this work to create all this roadmap, and yet, right before the end of the quarter, none of them are like up to date enough to understand the state of the world. And then, it causes this big disruptive quarterly hit to what people are doing. That's a great example of like what behaviours would we observe if it was working better. And it would be like, well you know what, this is an example where teams who have this dialled in, the end of their quarters are non-events. Things have changed a little bit. The roadmaps were still there, just like they were before. They've hit some goals, but they're setting goals on the next things. The difference between a company that has this dialled in and hits the end of the quarter, and a company that's struggling is massive. Like the difference between, say they have 1,000 people, the difference between spending maybe two, three, 4,000 hours across 1,000 people at the end of the quarter, which is very, very expensive. Or having to spend 20, 30, 40,000 hours at the end of the thing. So, when people think about, oh, this stuff doesn't mean much difference, think about how many employees you have and how much thrash that they have, and then multiply that by what you could be spending your time on. And then, you start to get to some of the behaviours you might observe if your roadmap was working.

  - So, John, I think we'll wind it up there. Always at the end of the session, love to give people a chance to pitch themselves. How people can get hold of you, how you can help. Fire away.

  - Well I think pitching for me is I just love chatting with people. I think LinkedIn is the best we got at the moment. You know, so if you wanna reach out and connect on LinkedIn, mention the show, and we could have a conversation or chat or get on the phone. I think that, yeah, that's the degree that's gonna give me the most joy at the moment is just chatting with people who have diverse perspectives on this stuff. And so, yeah, get in touch.

  - Been a pleasure. Thanks very much.

  - Yep, you too. Bye.