When Your Product Roadmap Works Against You

Product roadmaps are supposed to create stability when you're delivering software on a product engineering team. The idea is that if you decide what you're going to build and then work out what sequence you're going to build things in and put them onto a product roadmap, you can get buy-in and sign off for the roadmap from your stakeholders. You can then get on with actually putting your heads down and building the work. The product roadmap is there to protect your team from noise, from friction and from things changing because you've all agreed, including your stakeholders, what you're going to build and when. But what happens when that protection goes a little bit too far and actually prevents your team from learning from new information as you go along? That's something we call the roadmap shield. When a roadmap can act so much like a shield that it doesn't only protect your team from disruption, it also protects it from adapting to new information. And that's what we're talking about today on this week's episode of the Product Engineering Podcast. (Music) Hi, my name is James Charlesworth. Welcome back to another solo episode of the Product Engineering Podcast where we're talking about the protective properties of roadmaps. Now, product roadmaps are really good because of the idea of stability. The basic principle of a product roadmap is that it's a contract between the engineering and the product engineering team and the stakeholders. So the engineering team or the product managers will decide what you're going to build, you'll work out what the scope is in what order you're going to build them and you'll get buy-in from stakeholders and perhaps with customers, you know, communicate the roadmap externally as well. Once everybody's agreed, you can then filter out all of the noise and go about delivering the roadmap. So that protective property of a roadmap to prevent noise entering the teams and random customer commits and stuff like that is really, really useful. But engineering does need heads down time to deliver something. But what happens when all of those protective layers of a roadmap actually go a little bit too far and they prevent the team from actually opening their eyes and seeing what's going on in the world around them? That's what the roadmap shield is. The roadmap shield is the multiple layers of protection that get built up around a proposed solution to the point where it's not just disrupting them from noise, it's actually preventing new information, changing what we're going to build. And it happens in layers. There's different layers of shielding that a roadmap gives to an engineering team and each one makes it a little bit harder for information to get through to the team as they're building. The four layers are scope, estimates, communication of timelines and then delivery pressure. And we'll talk through those in order. The first thing that a roadmap protects is scope. So let's consider you're building a new feature and you decide what's the proposed scope of this feature? What are we actually going to build to try and solve this first problem? Now, good engineering teams and good product managers should be able to reduce the scope to a kind of MVP type state where they're only committing the smallest amount of scope that they need to deliver the highest amount of value. And that's usually a back and forth process that happens between engineering and product and stakeholders where everybody gets together with a problem and the proposed solution. They say, how much do we need to deliver to be able to try and solve this problem? And that's your scope. So you'll write that scope down and you might write it as like some acceptance criteria or something like that. You'll write that down and we'll say this is what we're committing to delivering these features, these elements to this feature is what we're going to ship. So that's your scope. And once you've written that down and made it part of your roadmap, that scope is there to protect the team from things like scope creep. So scope creep is the idea that you're halfway through delivering something and somebody comes along and says, oh, wouldn't it be great if it had export to PDF functionality? Or something like that, right? Scope creep is where extra features that didn't go through that initial balancing process to work out what should be in that feature. Extra things come along and we just feel pressure to add them in. So protecting scope is part of roadmap driven engineering where we decided to start how much scope we're going to put into the roadmap and then we try and lock that down. Like, okay, occasionally things will come in and we will have to change the scope, but as much as possible, you want the scope written down before you start work. And that's the first layer of the roadmap shield, because once scope is written down, you can use that scope definition as the agreed contract of what we said we would deliver. And anything that comes in as an extra request, you can largely say no to because it wasn't part of what we had delivered. So there's that layer, which is scope. And then after something's scoped out, it then goes into estimation. So a product manager and an engineering team have decided what they want to put into a feature. They've decided their scope. The engineering team then have to estimate how much time is it going to take to do that amount of work. Now, there is a little bit of back and forth here as there should be. It could be often the case that product managers will propose too much scope and the engineering estimate will come back and it will be really long. And so they'll have to have a little bit back and forth between product and engineering where they decide, can we trim some of this scope out and get that estimate down. So let's say you've done that and you really reduced the scope to something that we're comfortable with the amount of time it's going to take to deliver it. You then write down an estimate. Now, engineering teams and engineer managers like to give estimates that they can hold themselves accountable to. So they do put a lot of effort and probably more effort than product managers realize, but they do put a lot of effort into making sure that those estimates are realistic and they can hold themselves accountable to them. That estimate also goes onto the product roadmap. So if you're drawing a roadmap out on a road mapping tool, then the length of the box on a product roadmap will be the estimate for the amount of time. So you have the amount of scope that's going into a feature and then you have the amount of time that the team thinks it's going to build. And those two things become two different layers of the roadmap shield because once the time has been estimated, the amount of time is on a roadmap, then nothing that comes in can really change that. You can communicate that timeline out. You can say to customers, you're going to have this feature in five weeks time because that's what our estimate said. We've maybe built a little bit of buffer time into there, but our estimate says five weeks time and that becomes a commitment. And so the next part of the roadmap shield is when you actually communicate out what those commitments are. So let's say we've decided what the feature is going to be. We've decided how much scope is going into this piece of work and we've decided when it's going to be delivered five weeks. We then communicate that out. So we've decided that we're going to have this feature in five weeks time. Once that communication has happened, it's very difficult to roll it back. So that becomes another layer of the shield because once you've said to people you will have this work in five weeks time, that becomes a commitment that's set in stone. And with roadmap driven engineering, that's usually okay because the commitment can also protect the team. If a stakeholder comes in and tries to improve their work, then they can use it to make sure that they're not getting the right time. So if we're trying to employ, impose scope creep on the team, the team can say, well, we could do this PDF export feature, but we've already committed this date. And so doing that will cause us to miss our date commitment. So that date commitment, that communicated timeline becomes a layer on the shield where the date commitment itself is stopping the team from changing what they're doing. And again, that's often very, very useful, but we're talking a second about how that can go too far and why that can be a bad thing. The last layer of the shield is delivery pressure. So what will often happen, particularly as you go through a project or you get closer to delivering something is people will really start to zone in on is this scope, the scope that we said it was going to be, is that date going to be hit? People get very nervous if the scope doesn't look like it's all there and you're getting close to that date. And what tends to happens then is stakeholders and leaders and people in the organization will start to put pressure on the team. And once you put teams under pressure, they become even more determined to just get their heads down and get the work done. So that last layer is basically a psychological one that puts the team from a kind of exploration mindset where they're thinking, oh, let's get creative about this and build something. And it puts them much more into I'm under a lot of pressure. I just need to get focused and build something. So those are the four layers of the roadmap shield. There's the committed scope and then there's the timeline. Then there's the communication of the scope in the timeline. And then there's the pressure that comes in as you go through the delivery to make sure you hit it and putting all that together. It really does protect the team from change and it works relatively effectively at delivering the things that you said you were going to deliver. The problems start to appear when new information needs to feed its way into the team. So let's say the scope that you'd originally decided to turns out not to be correct before you finish delivering. So we decided we're going to build one feature, but actually it should have worked slightly differently. Well, what happens then is each stage in the roadmap shield will kick in and it will stop that new information from changing what the team are actually building. One scope has been agreed and written down and it becomes much, much harder to change. You get the sunk cost fallacy where you start to think, well, we've already written this scope up. We've already created some acceptance criteria. We don't want to change our minds now. Let's just deliver what we said we were going to deliver and then we can change our minds later on. So the amount of scope you've committed can stop new pieces of information coming in. And sometimes that's desirable, but not always. The same thing happens with estimates and communicated timelines. If you miss a communicated timeline, that can affect the reputation of the team. It can affect the perception with customers and stakeholders. It affects a lot of things negatively. It can make the engineering organization look like they're not predictable and they're a little bit chaotic. And so again, all of those things add pressure that prevents scope changes and ideas coming into the team. But the compounding effects that all of these layers have on your ability to innovate quickly is that they turn questions like, is this the right feature to be building into questions such as, are we delivering this feature completely successfully? And ultimately, as we spoke about in previous episodes in this podcast, you don't want to be holding your teams always accountable to how effectively they're building this thing they said they were built. You need to also hold them accountable to how much impact are they having and what outcomes are they driving in your product. But if your roadmap is causing your team to not be able to change direction or bring in new information, then they are going to end up forcing themselves to be accountable by how well we're executing the roadmap. And you're going to find it very, very difficult to hold them accountable to any kind of outcome metric. So I'll give you an example. Let's say you're working on a product and you want to bring in some AI functionality from a third party service. Now, at the minute, you might think what we're going to do is we're going to find an MCP server and build in an MCP server integration into our applications. So that's a fairly common thing to do. If you've got a third party AI application and you've got an AI application, then using an MCP server and putting it in your application seems sensible. So to go through the roadmap steps, what you would do is you would decide firstly how much which tools are we going to use on this MCP server, how much of this functionality do we want to bring in? And that becomes your scope. You might also have some performance requirements on the scope. You might have some testing requirements, all that sort of stuff. And we decide we write down, we're going to bring in this MCP server. We're going to use these five tools. This is how we're going to test them. This is how we're going to make sure that they're performing. That becomes the scope. The engineering team then turn around and say, yeah, that's about five weeks worth of work. And that five weeks becomes your timeline. So you said, these are the things we're building. This is our timeline. Then you go and communicate it out. So we've got five weeks worth of work, an agreed amount of scope, and we're communicating that out to stakeholders and saying in six weeks, let's add a week in six weeks, you can have these five tools from this MCP server brought into our AI application and you'll be able to use that. And then as they go through and deliver it, it starts to get a little bit of pressure through the team where they start to think, oh, how close are we? How many of these tools have we done so far? That sort of thing. So a delivery pressure builds up and that creates the four layers of the roadmap shield. Now, let's say you're three weeks into this and it turns out that maybe that MCP server wasn't the right way of solving that problem. And that's perfectly possible in the world of changing AI, a little bit of a tangent, but there is a little bit of growing but very passionate backlash against MCP as being the right catch or solution to a lot of integrations at the minute. A lot of people that are building AI products are starting to think, what if instead of using an MCP server, we could just have the LLM write some JavaScript that calls their API directly. That is an alternative approach. And the team might have assessed that approach and thought, no, no, no, we still want to use an MCP server. But let's say halfway through that delivery, that approach of allowing LLMs to write JavaScript, maybe a new model gets released that's really good at that. Or maybe the company you're integrating with exposes some skills that help models interact with their API, whatever it is, some new information comes in and halfway through delivery, it turns out that this MCP server integration probably wasn't the best solution. Or at the very least, we should assess something else. We should spend a bit of time trying out something else. Now, the four layers of the roadmap, she'll kick in there and stop that happening on the team, because by this point, the team are not in experimentation or discovery mode. They're in execution mode. They're being held accountable to how effectively they can execute to those deliverables. So they're halfway through delivering their agreed MCP server scope. They've communicated out when it's going to be available and they're halfway through delivering their roadmap. You cannot at that point, just change what that team's doing and have them spend two or three weeks investigating alternative approach. The first thing that will happen if you did that is the delivery pressure from stakeholders would be like, whoa, whoa, whoa, what are you doing? You can't just change your mind. You've got to hit this date we agreed on. And then the date as well, if you were to miss that, that would affect the team's reputation. It would affect the ability to trust future dates coming out of the engineering team as well. And also the original estimate, which was five weeks, the engineering team that had given that estimate, they'd done it based on a set amount of scope. So if you say to them, you're now going to spend a week experimenting with a new way of solving this problem, they're going to say, we can't do that because that breaks our original estimate. And again, the amount of scope that was written down has been written onto a roadmap and has been written onto a feature. And this new approach just was not on there. So those four layers of the roadmap shield will ultimately prevent the team even exploring this new approach as they're building the first thing. What tends to happen is they will get to the end of that feature and they'll deliver it. And then maybe they'll have a little bit of time back when they can explore different things. And if they did explore like an API first write some code approach, then what they would do is I put another feature on a roadmap and then they will commit to that. And then in three weeks time, there might be another approach. So this is a good example of where committing too much time into one roadmap item and then getting your heads down and delivering it can actually stop new approaches and new ways to experiment. Or at the very least, it can defer them to too far in the future. So how do you actually solve this? Like what do you do if a roadmap is preventing your team from pivoting or exploring your ideas during execution? Well, there's a bunch of ways that you can solve it. And ultimately, that's the heart of why I'm doing this podcast. It's because creating teams that can adapt some new information and they can pivot and they can explore. They're constantly exploring as well as delivering. That is the real skill of product engineering. It requires a huge amount of trust and collaboration and some process changes as well. So there's a few ways you can get out of the roadmap shield. One of them is to just create smaller roadmap items. So you're still delivering that roadmap item. But instead of spending five weeks, you're just going to really cut the scope down so you can deliver something in two weeks. If you do that, then you can deliver it and you can check it off and then you can spend a week exploring alternatives. But there are other ways of doing it. One interesting thing that I've seen being quite successful is to explicitly say you have an exit ramp at every part of your roadmap shield. So taking the four steps, you've got your delivery pressure. You need to have documented and explicitly the trust with leadership to say we are going to deliver the things we said unless something that meets this threshold of new information comes along, in which case we are not going to do the thing we said we're going to do. And you need to be comfortable saying that to people that are your stakeholders. It's the same with delivery estimates and timelines as well. You need to be able to have an off ramp in your timeline. So you say to somebody we're going to deliver this in five weeks, but this might change if there is a major development in this area and you need to have that communicated properly. And that's not always possible. It's not always possible to say to somebody you can have this in five weeks, but with a caveat, you might not do, particularly if you've got marketing motions around that or you've got customers that really need it and they're relying on having something in five weeks. So it's not always possible. But I would encourage you to look for places and look for features that you're delivering where those deadlines actually can be moved a little bit. And you can agree up front what kinds of things will get you to change those deadlines. So a lot of engineering teams, particularly if they don't have the customer context of why something's got to be done by a certain date, then they will just treat every deadline as immovable. Engineer managers are told to always hit these deadlines, but actually in most realistic scenarios, those deadlines do have a little bit of room. You can work with customer facing teams. You can work with marketing teams. You can start to think what would happen if we change direction halfway through this project and we had to push it out by five weeks. What can move and what can't move, work with them and decide realistically which of these deadlines can move and which ones can't. So every layer of the road map shield can be broken down. You just need to think about this consciously and you need more trust and communication with the people that are communicating the road map to you also need that trust internally on your team. You need the team to feel a lot more comfortable with breaking commitments. If they've been given the permission to break commitments under certain situations, then they should feel comfortable putting their hands up and saying, we are actually going to change direction now. We are not going to deliver the thing we say we're going to deliver. And these are the reasons why this is the new thing we've learned. This is why we think taking two or three extra weeks will be worth it or deliver something that's even better. If they can get comfortable doing that and they can build up the trust of stakeholders, that that's the right thing to do, then what you'll do is you will end up with an engineering team that is much more flexible and much more able to solve problems and then switch to a different solution halfway through a solution that they're already working on. And that is ultimately how you achieve outcomes. Because outcomes are very, very rarely just going to automatically happen when a roadmap item gets to the end and gets delivered. Outcomes nearly always need some kind of course correction or some kind of iteration to be able to reach them. And so by being able to give yourself permission to do that iteration during the delivery process or a roadmap, then you're basically going to be able to react a lot more quickly. You're going to be able to respond to market changes, to technological shifts a lot more quickly, and you're going to be able to be a much more flexible and iterative team. If you can get comfortable with saying these are our deadlines that we need to hit and these are the ones that we do have a little bit of flexibility with, providing we've got a good benchmark of when we can break those commitments. So think about this on your own teams. Think about which of your deadlines and which of your scope commitments and estimates are actually set in stone and which of them do does have a little bit of flexibility. And if they have flexibility, communicate it to the teams and say to them, always keep your eyes open. You have a little bit of flexibility here. You have a little bit more leeway than you think. If some new information comes in and you found a better way of solving it, it's not a failure. It's a failure to wait before trying that out. So ultimately, product roadmaps are not a bad thing. They do still protect your team from outside noise and they do still give you that heads down time that you need to solve a problem. But it is really, really important to have off ramps from the commitments you're making on a product roadmap because you never know when your information is going to come in and you never know when pivoting or slightly course correcting could be the right thing to do. It's nearly always worth exploring when something comes in that could change whether you've got the right solution or not. So try not to stick too much to your roadmaps wherever possible. All these things, it's always a balance. It's always a balance between being predictable and reliable and being innovative and disruptive. So find that balance. Try not to use your roadmap as the complete gospel of what you should be building. Try to make the exit points explicit on your roadmap and always ask yourself, would we be able to change this plan if new information came into the team? And will we be able to respond quickly if we need to make a change?