Can your roadmap be implicit? | Ryan Singer

In episode 58 of Talking Roadmaps, Ryan Singer discusses the concept of implicit roadmaps and their role in product strategy with Phil Hornby. He explores how roadmaps can be fluid, shaped by ongoing framing and shaping processes rather than rigid timelines. The conversation covers the challenges of aligning teams around implicit roadmaps, the importance of framing in setting strategic priorities, and the pitfalls of over-committing to specific features.

Ryan has worked on all levels of the software stack, from UI design to programming to strategy. Over 17 years at 37signals, he designed features used by millions and eventually became Head of Strategy. He is the author of Shape Up. In 2021, he founded Felt Presence to help teams stop running in circles and regain the thrill of building.

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 Cliff Hazell, he’s a Leadership Coach, Advisor and Speaker. So watch out for Season 1 - Episode 59!

• Transcript

  - At Basecamp, there was no written roadmap anywhere and there was no visual roadmap anywhere. I'm not actually advocating for an implicit roadmap. It's not better. The one thing that I've learned from all the work we've been doing helping teams of very different sizes and from different organisations apply, "Shape Up," is that-

  - Welcome to, "Talking Roadmaps," channel, where we talk about everything road roadmapping, the good, the bad and the ugly. Today I'm joined by Ryan Singer, Ryan, introduce yourself.

  - Hey Phil, nice to be here. So I wrote a book called, "Shape Up," and what's in the book has been a starting point for a lot of people who are kind of tired of the ways they've learned to work. You know, like scrum and a lot of heavy meetings and a lot of time consuming rituals and stuff like that. It's also been a starting point for folks who are kind of in an unstructured startup world where there's only like three people or five people and they want to figure out kind of as they grow, kind of what is the more repeatable way that they're gonna do their product development process and all of that. And what's in the book is born out of my experiences. You know, being in the software industry the last 20 years, I started off doing UI design and interface design. Got into programming, kind of became the bridge between those two, eventually into product strategy and into kind of figuring out what are the things we're gonna focus on over the next, you know, six weeks to quarter, to what are the big kind of things we're going to, the big mysteries we're going to solve about, you know, how to do this or that in the feature set, you know, over the next year. Those kind of things. And I was head of strategy at 37 Signals for about 17 of those years. And a lot of what I learned and went into the book came out of my experiences there.

  - [Phil Hornby] If you're enjoying the channel, subscribe, hit the bell and give us a like. And interesting to hear kind of that kind of journey of creating or codifying I should say, how you guys work and that kind of best practise. I remember trying to do something similar in an organisation myself in the days kind of pre-agile, even really being on the radar. It was just like this, we were just really hearing about it, at least on this side of the pond. So it definitely wasn't so much part of the thought process. It was much more waterfall, the kind of mindset that we were kind of using as an organisation. But we were trying to codify how this core team of great engineers, we're about 15 of us, was doing and delivering great work. And as we scaled and brought in another 10 to 20 engineers, everything just went wrong.

  - All the things that you took for granted didn't work anymore. And now how do we define the way that we work in a way that we all kind of know what we're doing and we have a common language and we can sort of see what is the input to this step and the output of that step and how does it also all come together in the actual, the time that we intend it to and at the level of quality that we need it to, you know, there's a lot of puzzles to solve there.

  - Yeah, it was an interesting challenge. I think I even named our approach, Aims, I mean, because it was, Accu Test was the company name and it was like integrated management system or something like that. But it had that of this is what we're aiming to do as well as kind of giving a meaningful name to it. But it just, yeah, it's interesting that I see lots of people trying to kind of codify their ways of working to try and find that better way, 'cause I don't think there's one right way, but there are a lot of good ways and there's some better ways of doing things.

  - Well, yeah, and we get into situations where either the team realises that they're not delivering the way they need to be and there starts to be some finger pointing and there's kind of this feeling of like, "Oh, we have to get out of this situation. We actually can't continue this way." So it can be kind of delivery problems, quality problems, projects dragging. That's one thing that kind of motivates a team where, "Okay, we actually have to focus on the way that we work." The other thing is where sometimes things are going fine, but what's going fine for five people doesn't work when you bring on 10, 15, 20 people. And so you have to be able to formalise the things that were happening intuitively or organically in a way that doesn't kill what was working before, but also allows you to grow. You know, so these things happen.

  - Yeah, and that I do find myself increasingly working with companies in that kind of scale up space and helping them kind of navigate those challenges. So it's definitely an interesting one. It's always interesting, I find, how the things you did much earlier in your career start to suddenly come back and you see yourself repeating it now, helping people find their way through it. I mean, obviously it's a channel called, "Talking Roadmaps." We've probably gotta bring some roadmaps into this a little bit. So maybe let's start with just a fundamental question. Where do roadmaps factor into the Shape Up process, if at all?

  - I mean, this is a little bit of a, there's a misconception there because if you look at what's in the book, I kind of stressed the idea that we don't have what people sometimes call a roadmap, in the sense that we don't have a fixed plan that on this day we will deliver this exact feature and then on this day we'll deliver that feature and so on. You know, and at Basecamp, you know, where the book was kind of born out of, there was no written roadmap anywhere and there was no visual roadmap anywhere. There was no kind of thing you could look at that would tell you what the future looked like on the quarter, or half year, or year long kind of timescale. The only thing that was really announced and visible was the very next six weeks. But actually it doesn't mean that there wasn't a roadmap, it's just that there wasn't something that was explicit. And the thing was that if you had a conversation with the partners, there were things that were more important than other things for the next six months that were going to get time and effort and attention and that were certain other things that weren't gonna get effort and attention. You know? And so I think that when we talk about like, what does it mean to have a roadmap, it's the first thing that I can say definitively, 'cause it's so different in everybody's context, is that there's a level of management and planning and work, which we can call the kind of project level. You know, we're in a particular effort and we can see the end of it. We know what work has to be done, you know, so for example, the kind of ideal of that in the Shape Up world would be we have a particular, let's say, time box, which is not bigger than six weeks, and we've shaped what it is that we're going to do so that we get the outcome that we wanna hit. So we've actually figured out what we're going to do to kind of hit that target inside that six week time. And we can say kind of very clearly, this is the time and this is the work we're doing, this is what it looks like to be done, you know. But of course that work has to belong to some kind of a bigger strategy or a bigger understanding of what it is that we're trying to do, you know. And the book talked a lot about this notion of shaping, which is if we have a given time box, you know, we don't want to just start the project with a very, very rough understanding of some conversations we've had. And now let's jump straight to building. And it also doesn't work if we have a lot of, just a bunch of detailed drawings and Figma files, you know, telling us where every pixel should go, but we don't actually understand the kind of technical decisions and the architecture underneath it, you know. So a lot of this shaping work is actually about how to get through a particular project successfully. But there's this question of like, "Well, why did we shape this feature or this project for this six weeks instead of something else? Why is that the thing that we're working on right now," and we've been teaching in the shaping and real life course, this is something that wasn't really spelled out in the book because at Basecamp it happened so kind of invisibly, you know, through conversations. And it wasn't spelled out like I said, but there's this other work that we call framing. And framing is like the definition of the project in terms of why is this the thing to be doing right now? How do we know when we're done? What is the outcome we're trying to get? What makes this more important than other things? How do we, you know, where does this belong in our strategy? That kind of a thing. So framing is more like the business reason for doing the project, and then shaping is more like the technical solution. So you could think of framing, like if we're buying a house, like why do we need to go buy a house now? Can it wait two years or three years? Well, you know, the baby is coming or this and that life changing is happening and like, look, sorry, we have to move, you know, even if it's not good timing. But then when it comes to actually choosing the house, or designing the house, or building the house, there's a million decisions that have to be made. And you can't just show up to the building site with a pile of wood and some hammer and nails and then think you're gonna start building a house. You do have to have a kind of architecture or plan, you know? So the shaping is the technical approach to doing that project. The framing is a kind of business motivation for doing that project. Why are we doing this and what are we gonna get out of it? And what makes it the thing to do now? The place where this kind of connects to the topic of roadmaps, is that there needs to be some kind of, well, actually there doesn't have to be, we can be in a situation where maybe we are so free and relaxed that we can just frame one thing, shape it, do it, frame the next thing, shape it and do it. But we find ourselves in different situations where that's not enough and we need to have a longer timeframe agreement or conversation or coordination, you know? And there's very many, actually, it's surprising, it's interesting. There's very different reasons why we might find ourselves kind of forced into a quarterly planning conversation. You know, of course there's the kind that is led by having investors or people who are funding you, and they want to have some kind of answers from you about what you're gonna be spending your time on. Right? Over the longer chunk. Yeah. Over the next quarter or half. There's also situations where you might be, for example, a bootstrapped company. You don't have investors who are pressuring you to hit any target or give them an explanation about what you're doing, but you realise that quarter after quarter has gone by and that ambitious feature that you've talked about doing, or that new product that you've talked about doing, it keeps not happening. And you realise if we're ever gonna actually do this thing, we actually need to make different decisions about how we spend our time over the next quarter. You know, if we want to end, let's say it's the beginning of 2024 and we realise like, "Man, we really need to have a prototype of this feature that we've been talking about by summer, we need to have this thing live. You know, like, we're not gonna let another year go by." So then you look at the year, and you have to actually kind of then work backward of, well, what are the other commitments we have? What are the things that we kind of know that we have to do? And how does the puzzle fit together so that we end up with that big thing actually happening in the amount of time that we need it to happen in, you know? So this is when we move up to this level of conversation about what's important at the level of the quarter or the half year or so on, on the one side, it's a coordination problem. It's a puzzle piece problem. What capacity, what availability, you know, kind of what can we do with who is available when, but it's also very much a strategy conversation. Why is this important? How do we align on doing this instead of that, you know, so I tried to put a few things on the table so that you can kind of lead us where you want to go, because these are quite different directions of conversation, right? The strategy aspect of this versus the puzzle piece aspect and also how this relates at the high altitude of the quarter strategy down to what are we actually framing and shaping to actually go execute, you know, in the next two weeks or four weeks or six weeks or what have you.

  - It's super interesting, like just thinking of that implicit roadmap as opposed to explicit roadmap. And that the biggest challenge I find there is making sure that everyone's on the same page, like something explicit is easier to align everyone around. So maybe let's start there in terms of what challenges you've experienced or how you've overcome those challenges of making sure everyone's aligned. You said it just kind of happened.

  - Well, there were a lot of structural factors at Basecamp that made that work. The thing is, I'm not actually advocating for an implicit roadmap. It's not better. The one thing that I've learned from all the work we've been doing helping teams of very different sizes and from different organisations apply Shape Up, is that there's so many details of how you do things that depend on the structure of your organisation. When it comes to shaping projects, the kind of thing that we identified as the constant that's always true, is if you need to deliver something by a certain date, then you can't jump into it not knowing what it is, you know? And so we have to figure out how to make this shaping step happen and this framing step happen so we can more clearly get that alignment and define what it is that we need to do so that we hit that deadline. And then we found kind of, we have a suite of methods and things that we teach to do that following the principles from the book, but also kind of more concretely, how do we actually hold a shaping session? What do these different steps of work look like? What I'm learning, I wasn't even interested in roadmaps or long-term planning for the first couple years of doing this. I didn't even realise it was relevant. But then, you know, the same question started to come up. So like, for example, question came up, how do we do this with a new product? You can't build a whole new product, you know, in a single cycle. You can't do a whole product in four weeks or six weeks. And that's kind of the unit that we shape as, right? So this is an example where I've been in this situation before, I was working on a side project, no formal organisation really, it's like three people working together, you know, and we didn't have a formal road mapping process, but all of a sudden we were agreeing, 'Okay, we are agreeing that we're gonna invest our time part-time for probably a year to get this new product built." And we weren't just going to pretend like we didn't need to use this time intelligently and just start on the one thing and then see how it goes. We needed to have some kind of an understanding, you know? So even without thinking that I was doing road mapping, we naturally started having conversations once a quarter about what are the things that we have to accomplish this quarter, right? And what I noticed was that it was not very different from what we do when we do shaping sessions. You know, in the shaping session we say, if we're gonna have, let's say four weeks of capacity to build something and this is the outcome we need, then we are figuring out, well, what are the pieces that are gonna go together that add up to something that's meaningful inside of that, let's say four week appetite that we have. If we're looking at, on the standpoint of a quarter, it's not really different. It's what we're doing then is we're not shaping the technical approach of here is how this screen is gonna connect to that screen, or we're gonna call this API or whatever in the context of a project. When we're at this quarterly level, what we're actually doing is shaping what the projects might be. You know, so this is a little bit more, so like for example, we were working on building this product, which does a specific kind of technical analysis on demand side interviews. It takes the outputs of a specific interview method into the app, and then it puts them into a kind of, actually, it's not so different in principle from how an embedding works in a machine learning or an AI context. It kind of puts all these things into an embedding. So you can do clusters and then you can kind of get to the three main groups of the jobs to be done, of the customers you interviewed, so that you can then take that into your product strategy. So we wanted to build this tool, and there's a lot of moving parts. There's some mathy stuff, there's kind of an algorithm that has to work. There's a bunch of UI steps that kind of, I had never seen done before that where we needed to innovate. There was going to be a lot of polishing work to make this look like a real product and not just a rough, you know, researchy prototype thing. There was like so much work that had to happen. So one of the things that we did first was we said, Okay, what are the biggest unknowns that we have to solve to know that we are even going down the right approach and this is gonna be viable, right? So what can we do if we have a year where we are gonna invest in this product? What are we gonna do in this first quarter that is going to help us to actually eliminate the biggest unknowns and get to something that kind of hangs together? You know, the first quarter means more or less, not more than really like two or three major things getting built out, you know? And so what we ended up doing was we kind of framed what the outcome would be if we had a very rough version of the thing that allowed you to input the interview data. If we had a very, very rough, something we would never ship, but just something that would allow us to do this thing that we called affinitizing. And we knew that we didn't even want to design the experience for it, it was just that we needed the data of this step. So it's like we're gonna see if we can do a decent interview input experience. We need the affinitizing data, but we don't care about the experience at all. But then we're gonna have to do this clustering algorithm, and we need to make sure that we can run the affinitized groups through the clustering algorithm. And if the clustering algorithm, if you can just pull the crank and it gives you an answer in the console, that's a success. And if we get these three things kind of plugs together in the machine works, that'll be a great starting point for Q2.

  - Yeah, I mean, so it sounds to me like the highest risk you had there was very much at the feasibility level. And yeah, what I'm hearing is you're taking the biggest risks first, which is always what I advocate, but so often people start the opposite end with the small risks. It's like, let's get some progress.

  - Well, yeah, it's easy to want to feel the progress of doing the things you already know how to do, right? But that's not the progress that the project needs because, you know, we want to be reinvesting in Q2 consciously, because we eliminated all of those things that might have killed the project in Q1, right. Or where we would've needed to go down a very different path.

  - Yeah, or where you might have had to kill it in Q4 because you didn't address them early and all that earlier work is wasted.

  - That's what we don't want. Exactly, exactly. So that's one example of, you know, of kind of road mapping, aside from the formality of road mapping, but responding to the reality of we needed to have a strategy of how we were gonna spend our time and what kind of outcomes we needed to reach, you know, and it didn't mean that we made promises about specific features, it was more like, these aspects of functionality need to hang together. Another big part of this was that we defined what was out. So like, this doesn't need to be polished, like it looks pretty perspective at all. And not only that, but the second to the two areas that I mentioned, the affinitizing, doesn't even need to be the actual real user interface. We just need to get the data from A to B so that we can try out the clustering. You know, so this was like, we were very explicit about what was in and what was out. Another version of this is something I saw my friends at Auto Books doing, they're also very good at having this kind of, organic approach to the roadmap, you know, where it's very much based on kind of what's actually driving us to talk about planning at this level. And they would have a quarter coming where they would start to talk about, well, we don't actually know what in particular we're going to say yes to, you know, in terms of potential projects or whatever for the next quarter. We don't know what exact feature modifications or growth oriented changes we're gonna make. We don't know what those things are, but they would say, what we do know is that for what's happening in the wider context of the business in this quarter, we are going to say yes to things that improve activation, and we're gonna say no to things that are anything else, right? Because we are in this kind of bigger strategic context. So that's something different. Whereas the example I gave about building the new product was a little bit more like we were kind of sequencing the functionality that we needed to create. This was more of like a filter on the kind of ideas that could come up over the quarter. And it was a kind of, you can almost call it, it wasn't a plan, it was more like guidance, you know, so that was a situation where they, instead of being three people working on a little side project, it was an organisation with a bunch of product managers and quite a few people. And they're saying, look, all the different PMs can come to us with different ideas throughout the quarter for, you know, something we can do in one week, in two weeks, maybe in three weeks, then in one week again, you know, very targeted improvements, but they should be about activation here, right? And then in the next quarter it was totally different. It wasn't about activation anymore, it was about how do we make our process of doing integrations with our partners faster? There's a certain kind of integration work that has to happen and we need to figure out how can we do that with less of a time investment and less back and forth. So that's a very different kind of investment in different kinds of work, but people can identify what progress would mean and what it means to actually move forward on that kind of a thing, you know, in this bigger timeframe.

  - Well, I would hope that that visibility, what was changing in the next quarter was a little bit known in advance as well, because like you said, some things take longer. Now, time chugging in six weeks is great. I've worked on things that were going to take 18 months to deliver. We knew that from day one and we can time chunk and kinda see your earlier deliverables and get the benefits of it. But we knew that really we couldn't deliver the value to our customers in any real terms, in anything other than like an early access programme for quite a long time. But if the goalposts moved like that, that would make it quite hard. Whereas in a more mature product, I can absolutely see that change of objective, you know, it's usually aligned with the cycle of, right, we're going after activation. And that to me is the essence of strategies. Like this is what we're saying yes to, these are the filters, the guidelines or the guardrails for everyone to be able to make the right decisions, to bring me the right things to say yes to instead of bring me a tonne of the wrong things.

  - Yeah, those are two, there's a lot of contrast there. The situation you described with the kind of 18 month project, that's like the new product development I was talking about, we needed to have, we couldn't just say bring me things to say yes to. We actually needed to have a kind of bigger picture understanding of what the architecture was of the thing that we were trying to pursue. You know, it has to do this, this, this, and this. And those things all have to come together to produce the value to the point where we can give this to somebody else to go use, you know, versus the situation of strategically we're focusing more on activation versus bringing more leads in, versus making our integration more efficient or whatever. Those are things which are a little bit more like categories as opposed to like a sequence of functions that all have to add up to some kind of bigger, you know, Voltron.

  - Yeah, I mean, one of the startups I was working with last year, they're building an ERP in a specific segment, and they very much, they were struggling with, well, when is it enough that it delivers enough value for our clients to actually use this thing? Because one module on its own didn't feel enough like there was enough value there because the clients kind of needed the whole thing to be able to do their job, which felt like something very large in a very large investment that they were hoping to get out to market faster. It was an interesting challenge trying to bridge and find that sweet spot of big enough and valuable enough.

  - This is where, yeah, this question of kind of when can we get to a point where we've done something that matters? When have we gotten to a point where we've done something valuable? It helps, I've found to flip between two very different ways of looking at the whole business. You know, there's the supply side, which is the question of, well, what are we gonna make, right? And how are we structured and like what do we do? And there's the demand side, which is what's going on in the world where anybody cares. And the split between kind of shaping what to do versus framing the problem and opportunity, falls into that same division. The shaping is the supply side of what to go do. And the framing is identifying what's going on in the demand side. That means that somebody is going to care. And sometimes the demand comes to us in a very, very fuzzy form, you know, that like everybody says the customers need, we need to have, for example, I worked on a project last year and the start of the project was some stakeholders saying, "We need notifications, we need a mobile app with notifications," right? And it's like, okay, if you need notifications, let's just kind of unpack what that means. And like nobody could see any way that we were gonna build that with the capacity they had on the engineering side. It was gonna be like a two year project to kind of build this whole thing out, you know, and to get everyone aligned and to do that. And my first instinct in that situation was to say like, "this doesn't feel kind of crispy enough. It doesn't feel small and concrete enough that I could really get my hands around why the status quo isn't good enough and how a notification is gonna make a difference." So in this case, we rather than kind of doing one approach is we could say this is a legitimate approach. You know, if you had the time and the people, you could say, well, they say they want notifications and their requirements are a little complicated in what they gave us, but we are just gonna be the heroes who do it. So we are going to pull out our Gantt chart and we are gonna make the giant plan that builds the giant thing and we'll see you in two years. That's a legitimate supply side approach. And there might be cases where that makes sense, especially in a situation where we are time constrained, when we are resource constrained and we need to kind of show progress in smaller units. It helps to do more work on the demand side. So what work on the demand side means, okay, so I'm hearing that you want notifications, and I'm sure you're right. Can you tell me if you don't have notifications in the next three months, six months, what starts to break? This is a question about their worlds not about what to build. Another question, for example, is you've been talking about needing notifications for two years. There's been a lot of other stuff that keeps kind of winning in terms of what you spend time on. And there's this feeling like, okay, we really finally have to build out this notifications infrastructure. What happened? What's going on that made now the time? Why are you choosing this over other things, right? So what is this competing with? When we dug into this, what we actually found out was that the organisation had a 20-year-old email mailing list. And this mailing list had tens of thousands of people on it that who knew if they should even be on this list anymore. And, you know what I mean? Like, it was just this ancient system and when they said notifications, it turned out their concern was like, we can't keep sending our strategic updates on this mailing list and we don't even know who gets it anymore. And we don't have control over filtering it. And like the board isn't comfortable sending stuff out on this list. So like what they really needed was a way to send announcements that went through their SSO system that tied into their kind of permission infrastructure so they knew who was who. And it was kind of going through that other system, you know, and it wasn't just the raw mailing list. So when we actually did the work on the demand side to really detail what the context was, what was breaking, what was going wrong, why the urgency was there, and we identified a nearer outcome, which is that we're gonna be able to send a blast out and not worry about who's getting it and if it's going to the right people or not. Then all of a sudden the shaping work, the supply side work of how we're gonna execute that was like, and we built a six week project, it still sent emails, it was a mailing list alternative, but it plugged into their SSO infrastructure so that it was using the identity system they had and everything like that. And it totally made this pain go away. And then what was also interesting was that even though that was kind of the end of the promise, the end of the commitment, the end of the plan, you know, this kind of six week effort, it turned out that it also gave them better footing for doing the mobile apps and the notifications and stuff, the push notifications that they wanted to do. So I think this is a really key thing is that when we start talking about long-term planning and road mapping and so on, it so easily falls on the supply side of what we just need to have a higher resolution picture of who was doing what when and then we're gonna get through the project, you know. And unless your project and your team meet very, very specific structural requirements, you know, that kind of almost like a construction plan, is usually not going to work out. And there's much bigger gains to be had by flipping over to the demand side.

  - So I'm gonna bring this a little bit back, 'cause you've used the term shaping and framing a bit and the framing sounds very much like the vision, the strategy objective side of things. And so maybe you can just kind of unpack a little bit more of what the sort of content you'd have there and how that kind of might link into a roadmap in the loose sense of the word.

  - Yeah, that's interesting. So this is actually an area where, I haven't yet formalised it, you know, so this is a little bit like the bleeding edge in terms of 'cause what's in the book, "Shape Up," and what we teach in shaping in real life, the course that we teach now is, it's 20 years of iterating and formalising, you know, and testing across a lot of different companies inside the boundaries of projects. And what we are now in is kind of the early phase of formalising how this connects up to the level of the quarterly planning and the half year and so on. So this is actually a super new area. And so I don't have like a speech for you yet on this. What I can tell you that's really interesting is that what we're seeing is there's a lot of similarities. It's that the quarterly planning is very much like framing a project, except the puzzle pieces that we then have to shape inside of that frame. So you can think about a frame as like, if we're gonna work on this thing for four weeks, let's say like how do we know that we did the right thing, right? What was the problem we were solving? What's the outcome? What are the metrics? If we can frame that work and we say, if these things happen, then the problem is gone. You can think of it just very simply as an acceptance test. Imagine just writing an acceptance test for the project, right? So that's a frame. If we zoom out to the level of a quarter, what we're looking then is what's the acceptance test for all the projects that are gonna get happened in that quarter, right? So, for example, we just had a kind of a very informal, my wife Kaya and I worked together on designing and building this shaping in real life course. And you see it just happens naturally again, like the talk around New Years, you know, of like what's coming up in the beginning of the year. And we identified like, you know what, we really want to do those iterations on the course that we were talking about doing for the last six months. Like, we really want to do those and we don't wanna let this slide anymore. So then we thought, okay, if in the first quarter we are really gonna make progress on doing these iterations to the course material, what does that actually mean? We have to set up the filming studio again so that we can record new lessons and revisions to the lessons, we have to pull together all those different things that we've talked about changing and kind of actually identify what are the most important ones that we need to change, right, out of the million iterations to the course we could make, what are the two or three things that we actually would do first, right? And we realised that, ah, we don't actually know how to answer that question. We don't know which changes are the most important and relevant for people. We need to do that interview project we've been talking about doing. So we basically framed the first quarter as we are gonna get the studio set up so that we can do another round of filming and changes and updates. We are going to get a new interview project going with people who've already done the course, but with a different focus then on past interview projects. So we're gonna learn kind of where the course wasn't working for people and what it clearer about the very specific ways that they measure progress when they come out of the course so that we can say which of all these different things are actually going to make the biggest difference, you know, to the results that people are getting when they do the course. So yeah, so we kind of figured out, okay, we're gonna do these interviews, we have to do the studio setup, and there were a couple other things. And then you look at the quarter and you realise like, okay, if I'm gonna do interviews, I need lead time to recruit people and blah blah blah, right? If we're gonna do this studio setup, then I can't be doing the interviews at the same time because blah, blah, blah. And then already we kind of started to get to kind of a rough picture of like, these are the things that are important, you know, so this is an example of the broad framing of like, what's most important for this quarter is we need to iterate more on the course, we don't want to continue to have the same lessons as before, right? And then we identified kind of the big chunks of work that we're gonna make progress on in order to get there. And then, you know, January first, second, third, they came and we kind of started working on the first thing on the studio setup. And then it was maybe, you know, three weeks into January and of course I started to realise like, oh man, if we're gonna make these interviews happen, I have to actually figure out where this is gonna belong on the calendar. So this moment came of, it's not enough to have the strategic conversation, we had that, it's not enough to kind of shape a little bit of what these projects are going to be inside of that for the quarter. I actually need to get a little bit down into the details of like, okay, when am I travelling and not travelling and like, when can we actually put this unbroken time of the two weeks to do the interview analysis and so on, right?

  - So I'm gonna change tack a little bit, I think, Ryan, let's go here. Yeah, what do you believe is best practise when it comes to road mapping?

  - If we try to make a lot of promises about different projects that we're going to build. Like if we're going to say that, I think, I'm sure you already know this and your audience already knows this. If we make a lot of promises that we're gonna build, these are the top five feature requests that customers had, and we're gonna build them all. And, you know, at the end of this much time, all these features are gonna ship, you know, or our customers keep asking us for all these things. And so we're gonna promise our customers that these are the things that we're gonna build next, 'cause it's what you asked for, or we're trying to tell people that we're gonna build these things because it's coming up in sales conversations, you know. The problem with those is that you're batching together a bunch of unrelated work, you know, and you might find that when you're in the middle of one piece of that work that you sketched out, you discover the thing that is 10 x more important than all those other things that you wrote, you know? And so if there is a best practise here, it's more important to understand your strategy for the next quarter, than it is to make commitments to specific projects. 'Cause at the end of the day, the specifics of what you're working on might get thrown out the window for a lot of different reasons. If you keep making adjustments in the pursuit of a consistent strategy for that quarter, of this is the thing that's important, you know, then you won't reach the end of the quarter and then think we wasted our time and we didn't get anywhere you know? Versus if you make a lot of promises to the specifics of projects and then the projects start to get hairy, then what can happen is six months can go by and you were just digging and digging and dragging in the same piece of work and you weren't actually delivering the value that strategically is needed either to the business stakeholders or, you know, in terms of the demand of the customer, you know? So giving oneself that optionality, I think is the number one most important thing, but optionality without framing is just chaos. You know what I mean? So, you know, if there is a best practise here, it's having the quarterly conversation, which is less about the projects and more about what needs to change in terms of strategically what needs to change, you know, are we still pursuing fit and we haven't found it yet? Do we have fit, but we're having issues with conversion and activation and stuff like that? Like, is there an unknown, a research area that we want to really have an answer to that we never had time to before? Is there a new product that we want to start understanding? If we wanna build a new product later this year, do we need to have certain inputs that are gonna allow us to do that? Like certain kinds of user research or prototyping, you know, like these bigger conversations about what we're trying to accomplish this year are really the important things.

  - Let's flip it the other way around, what's the biggest mistakes you've seen happening?

  - I would say two. One is what I mentioned of making a lot of very specific commitments to specific projects, that these are the 10 features that we're gonna ship them all by this date, you know. The other one is too often the road mapping happens as a kind of bullet list. You know, we're gonna do this and this and this and this and this. And the problem with bullets is they don't compete for resources. So when we're in a shaping session for a specific project, we can have a concept of like, we're gonna use this library and we're gonna use that API and then we're gonna show this on that screen. But we have to, before we say that we're done, we have to actually add up the work and say, "Can we do these 10 things inside of four weeks or not," right? And the same thing is true on road mapping. To actually know if this is a real realistic plan, we've gotta put it out of the bullet points and translate it into time boxes, right? What would it look like if we gave each one of those things that we said we're going to do a time box and can we, even in a very rough way, put the puzzle together in a way that seems believable, right? And simply moving from bullet points to time boxes and sliding those back and forth, even inside of Miro or something like that, you know, is usually an eye opening moment, you know what I mean? That like, okay, maybe this doesn't all fit in the first quarter and then this is a wonderful moment then to say, because it doesn't all fit, it means that we have to have a crispier conversation about what is important for us in this period of time.

  - I think one of our earlier guests, Simon Witkus, said something very similar along the lines of, it's gotta be grounded in reality. There's no point in committing or making plans of things that you just have no chance of doing. If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?

  - Wrestle with what is truly possible and leave latitude for unknowns.

  - And I love the thoughtfulness there as I watched you thinking, some people choose to ramble and then get to the clarity. Other people choose to pause and get to the clarity, as you did. It's always interesting to see how people's process works. And I have to do my Steve Blank at the end here. Is there anything I should have asked you about road mapping that I haven't?

  - A lot of the road mapping conversation, it easily goes to this place of like, what is our strategy and what should we be doing and so on. The reality for a lot of people who create a roadmap in this world is that they are not the ones actually in the strategy seat. They're not the ones who are deciding anything, but they actually have to get through a kind of moment with a superior where they have to demonstrate that they know what they're doing. So there's a very big difference between we need to define a strategy for Q3, versus being pulled into a meeting and saying, "Do you have your act together so that you can execute by the end of Q3?" And the roadmap is very much, I've actually done some research on this. The roadmap is as an artefact, is very much hired for the latter case, not the former. The strategy conversation is more the bullet points and the executive horse trading. The roadmaps, when we talk about people building this thing that looks like a timeline with boxes and stuff, this is actually someone who is in a management role, project manager or a product manager who is trying to resolve a whole bunch of conflicting constraints and put a complicated world into order, so that they can either say, "Yes, I'm on top of it, look, I have an answer to everything." Or so that they can manage the scheduling and the capacity nightmare of figuring out how to catch all the people at the right time so that the work actually gets done.

  - Love it. And I believe it can be used for both of those purposes, but I think you're right, it is predominantly used for those second worlds. And I think that mismatch of, dare I say the two jobs to be done of a roadmap, is part of the challenge of why it's often misunderstood that some people are expecting one and others are expecting the other.

  - Yeah. A big mismatch is that a lot of folks who are in the PM role talk about strategy, but their work isn't strategy. And it would be very helpful that we start to untangle these things and say, if you are in an executive role in your setting strategy, let's talk about setting strategy. If you're a PM and you're actually responsible for delivery, let's talk about how to get better at delivery, right? And if you can get better at delivery and you can start to actually have a few hours in your week where you could think, now we can start to introduce some strategy, right? But to really deal with these things, you know, I think in a more frank way, kind of to how they really are, rather than having a lot of like la la la conversation about strategy that doesn't get put into practise, because there's just too much puzzle piecing and horse trading and stuff that's taking up the time.

  - I mean, one of my theories is, product managers, just as product managers, if we go back 15, 20 years, were truly doing that strategy work, but the role is kind of what used to be a product manager is almost a director of or plus of product these days. And there's a whole new operational layer with that more delivery centric focus that, I'm not saying it's a bad thing, it's just, it's a change to the role, but some people are still using the term to refer to the job it used to be.

  - Yeah, that's a very good point. You know, we are actually just simply in a new context, the number of engineers who are out there working as employees and building software, I mean, we've never had that before. It's exploded in the last 10 years, you know, and of course you cannot just hire a million people without starting to improvise, let's say a coordination layer, you know? So I think a lot of this is that we are very new in the current context of like, how do we actually do coordination and how do we actually figure out what it is that we are asking all of these technical people to do.

  - Maybe a conversation for picking up another time. Ryan, it's been absolutely awesome having you today. I always like to finish with giving you an opportunity to pitch yourself, how people can get in touch, how they can find you, and how you can help them, fire away.

  - If anyone's curious about Shape Up, there's a short video called, Shaping in a nutshell, on YouTube that gives you kind of the 17 minute introduction to some of the ideas. My website is feltpresence.com, and if you want to figure out kind of how to actually do this stuff with the team that you have and the time pressures you have, then our course, "Shaping in real life," is a really good way to get clarity on what this looks like end to end and pull out some specific skills you can learn and things that you can start to apply.

  - Awesome. We'll make sure some of those links are down below for people to find them as well. Ryan, it's been great having you here today. Thank you very much.

  - Yeah, thanks a lot. Cheers.re