2. The Trouble with Traditional Roadmaps

At the beginning of this guide, we learned about the definition of a product roadmap. Traditionally, companies tend to show their roadmaps in a form that’s similar to a Gantt chart. A Gantt chart is a classic project management tool that maps out the tasks to be done along a timeline. Each item to be done, in the case of a timeline roadmap, is a work item to complete, and has a start and end date. It’s meant to give the company a sense of how much is going on at any one time, so they can plan resources, and to give a sense of how long it will take to finish a set of tasks. 

As a roadmap format, it’s so prominent today that if you do a Google image search for ‘product roadmap’, you see tons of examples of colorful Gantt charts, and very little else. It’s been like this for years. 

Product management, not project management

This form of roadmap grew as an extension of release planning, which is a project management function. Now, product and project management sound and often look similar, but they are different disciplines. Project management is about taking a known set of tasks, or the scope, and figuring out how to best plan it out to ensure it’s done within reasonable time, cost, and to an acceptable level of quality. 

Product management encompasses elements of project management, but looks at the bigger picture of what could be done or built, in order to solve the most interesting problems for the business and customer. At its core, in product management, you do not know the full scope of the project. You’re constantly learning and iterating as the market changes and you discover more about how you can serve it. As such, it’s not about optimizing the fastest and cheapest route to build a known thing, like it is in project management, but more about selecting which projects should be kicked off now that will likely lead the product and the business to success in the future. 

The practice of roadmapping as we see it today grew out of the habit that teams have of outlining their short term development work and release planning. It makes sense to outline the order of work to be done and resource planning for known, short term work that’s agreed upon, like you would for a sprint that’s two weeks long. 

Where it starts getting tricky is when the team is asked to forecast what’s included in the next sprint, and the next one, and the one after that. The same estimation practices that are being used for short term and known work to be done, starts to be expanded to try to cover months, or sometimes even years of work ahead. Estimates are always wrong, but in the short term, the effects are minimized. Over longer and longer stretches, the estimates of what’s going to be delivered in what timeframe are so made up they no longer bear any relevance to reality.

The timeline roadmap is a comfort blanket

Now, the thing is, product people everywhere know this. They know that the dates they are putting on their roadmap are made up, and that it’s highly unlikely they’ll deliver anything as outlined. And yet year after year, product teams produce these roadmaps because they see that it solves a different sort of problem. It makes certain stakeholders happy and feel secure. It gives the impression that there’s lots of work planned, that the team is busy and presumably working on the right things. It implies that important projects are going to be finished by a particular time. Your bosses love when you can give them this level of certainty. 

But it usually sets your team up for failure, as you’re the ones who look bad when you’re not able to deliver on what was an unreasonable expectation in the first place. 

Breaking down the broken timeline roadmap

If you deconstruct this format of the roadmap, you’ll see that it’s basically like a chart, with time going across on the x-axis, which creates your timeline, and your features or things to do going down on the y-axis.

A timeline roadmap, due to having that timeline on the x-axis, means that you are assigning a due date and a duration for every feature that you put on the roadmap

This roadmap format becomes harder and harder to manage the further out it goes, both in terms of time on the x-axis as well as visibility to stakeholders. No matter how big of a caveat you add, people around you will try to hold you to the dates implied in your original roadmap, which is a dangerous strategy that sets everyone up for disappointment.

In particular, there are three ways in which timeline roadmaps cause problems.

It creates too many assumptions about what needs to be done

The first one is that you end up building off in a direction of what was assumed to be the right thing, some months ago. Imagine standing at the beginning of last year and saying you knew exactly what needed to be built for the market for the rest of the year. Roadmapping out a year’s worth of feature releases means making brash assumptions about what the market needs and how you’ll best fill those needs, and leaving no room for spotting new opportunities or changing course if the playing field shifts. 

You’re also assuming that you know how long each of these is going to take.  

This might be easy for the stuff you’ve already broken down into more detail and had the developers give some estimates, but the further down the list you go, the less clarity you’ve actually got.

You’re also assuming that each of these features will work as soon as they launch.

So if you put 3 weeks to build that new checkout page, then at the end of 3 weeks, it should be converting exactly as well as expected, and you should be free to move on to the next thing. Except it’s actually very rare for any project like this to not need further iteration and development, so locking out your time by committing it to the next project is a dangerous game.

And by explicitly adding these features to the timeline, you’re assuming that each of these features should definitely exist! 

That they form part of the strategy and should therefore be codified. But the reality is that your business needs change over time, and what was a good plan at the beginning of the year turns out to be short-sighted as new information unfolds over time. The timeline roadmap format doesn’t afford the flexibility to show how these plans might change.

The timeline roadmap forces you to make a lot of assumptions up front, and assumptions are always risky. At the end of the day, you’re making one big, dangerous assumption:

That nothing is going to change

The format of the timeline roadmap leads to the product team having to work towards made up release dates, which in turn force the developers on stressful marches to launch everything on time, while giving sales teams and your customers expectations that you can’t meet, while missing opportunities in the market, and often, downright building the wrong things. 

And this leads to sad product managers and stressed out teams. 

It slows down your team

The next major roadmapping problem is more sly. It actually causes your team to slow down. It’s a crazy phenomenon, but here’s how it works. 

Picture this: If you, as the product person, go around to all your engineers and ask them for estimates on how long things will take, they might tell you it’ll take them a week for something. To be on the safe side, you assume a week and a half, as you know coding is more of an art than a science, and perhaps for your timeline roadmap, which is seen and signed off by your execs, you show it as 2 weeks. That way, if you finish early, you can move on to the next thing, or spend the excess time getting it perfect, right? Except that never happens. 

You experience Parkinson’s Law, which states that work expands to fill the time given for that work. Every product team runs into this. It’s why you’re always up against a deadline crunch, and no roadmap or project plan of any type ever seems to be finished ahead of schedule, no matter how much buffer time you put on there. 

Scope always tends to creep, as in you’ll find little excuses everywhere to say ‘while we’re in there, let’s add this – we’ve got a little extra time, after all!’, and procrastination always happens. 

The team spots that they’ve got something due further down the line, and so doesn’t rush on it until later. You might come in on time for some of your projects, but on average, you’ll find that your estimations suck, and most of the time, you’re up against a deadline crunch. 

I’ve seen a lot of teams tackling a lot of roadmaps, and I’ve never in my career seen a timeline roadmap be delivered as expected and on time. It just doesn’t happen. 

Janna Bastow, CEO/Founder of ProdPad

What happens instead is that the product manager spots the constant deadline crunches, and adds more buffer to their projects, buying more time to complete things. It might help reduce the number of things that come under a deadline crunch in the immediate term, but scope always creeps, procrastination always happens, and there are still crunches. 

And yet the team is able to achieve way less, because everything is mapped out to take up SO MUCH time. This is why you end up with teams who are huge and heavily resourced, but are unable to deliver fast. They’re being asked to spend a chunk of their time estimating how long it’ll take to do their work, and then try to stick to that plan. They often don’t even realize that it’s now taking them months to pull off what a small team of 3-5 people in a startup can pull off in a single sprint. 

It creates technical debt

Finally, these bad roadmapping practices also lead to tech debt. Because the developers are always in a deadline crunch, they’ve got to make trade-offs. 

Oftentimes, the product manager doesn’t even realize this, let alone the rest of the business. Essentially, if the engineer is forced to choose between making something look like it matches the scope and fits the acceptance criteria versus getting it out on time so they can have their weekend back, they often do so by skimping on the quality, in subtle ways. 

Perhaps the code wasn’t as elegant or reusable as it could have been if they spent a few more hours on it. Or perhaps they skipped on code commenting or documentation. Often it’s little things like this that don’t necessarily affect the ability to launch that feature, but over time they stack up and result in a shaky, tech-debt-riddled product. It wouldn’t be so bad if the developers had time to go back and fix up their code, but the timeline roadmap dictates that they’re meant to be on some new project already, so there’s never any time for rework. 

Furthermore, that wave after wave of deadline crunch is stressful! If the engineers are asked to build subpar code that they aren’t proud of, week after week, you can bet that they are on the lookout for other jobs. 

A couple years down the line, the company finds that its codebase is junk and needs to be refactored, but none of the original developers who wrote it are around to maintain and fix it. That’s an expensive problem to solve.

Timeline roadmaps create a vicious cycle

Having a timeline roadmap and a deadline-driven way of working gets teams locked into a vicious cycle that can be hard to get out of.

No one wants to be caught holding the hot potato, missing a deadline, so bigger and bigger buffers are given. 

Time expands to fill the work given. This is where Parkinson’s law comes into play and is the reason you always seem to be running up against deadlines, no matter how far out they started.

Those longer estimations create longer, riskier looking timelines, and the execs are even less comfortable giving freedom to build in lean ways, so they try to tie down even tighter deadlines so they feel they have control on costs. There’s never room for discovery in there, no time for rework or quality, and so the wrong things are built, problems aren’t solved, and quality suffers.

It leads to blame culture, where no one feels safe being the one to make a misstep at work, meaning people resort to just giving bigger buffers and estimates for their work, in hopes they don’t get it wrong ever again. 

This cycle can be easy to slip into, but hard to break.

We’re here to tell you there’s a better way.