Roadmaps, delivery plans, timelines and the Civilization 6 technology tree – how I like to use these artefacts when working with product teams

Roadmaps, delivery plans, timelines and dependency maps are all artefacts that people use in different and overlapping ways. In this post, I describe my interpretation of what each of these artefacts are, how I like to use them when working with product teams and explain how the Civilization 6 Tech Tree can be a source of inspiration when planning ahead.


Vision describes the future we are trying to create. The strategy describes our approach to achieving the vision. The roadmap visualises the plan to achieve the product strategy. At a high level, it should show the problems we plan to solve, in what order and over what timeframe.

The target audience for a roadmap is all stakeholders, customers and users of the product. For public-facing products, I like to have a public-facing roadmap. One of the main things I learnt from working a the Government Digital Service was that making things open makes them better. A public-facing roadmap gives everyone a chance to understand your priorities and provide feedback. Even if no users ever look at it, the process of creating and maintaining it forces me to articulate what we are doing to a wider audience, which is something that all product managers have to be good at.

My preferred format is the now, next, later roadmap. Here’s why:

1.. Just enough information for most. Most people don’t need to see a highly detailed plan. They just want a rough idea of what changes are coming in the short, medium and long term. This artefact meets the information needs of the majority concisely and simply.

2.. Handles uncertainty well. Software is inherently complex and uncertain. It is hard to accurately predict how long work will take until work is scoped and estimated. Planning too far ahead is usually a very inefficient way to work, and often offers false certainty. Now, next and later gives the reader a sense of priority, timeframe and ambition, without the team wasting too much effort on providing false certainty in long term plans.

3.. Easy to maintain. This roadmap is done to a level of accuracy that most software teams can easily provide. More granular detail can be provided for items in Now as these are things that engineers are working in now. Items in Later can and should be kept at a much higher level. Not having specific dates on things avoids awkward conversations when those dates inevitably need to change.

A snapshot of our public product roadmap at Climate Policy Radar

How to define now, next and later? In the Climate Policy Radar roadmap, I am using these definitions which are inspired by Prodpad.

I am not using a not doing column in my roadmap at present, but they can be helpful, especially when looking over a defined time period (eg. 6 months of 1 year). A good product strategy answers the question “What are the few things we will focus on and the many things we won’t”. Being explicit about what you are not doing helps create clarity and focus.

Delivery plan

Like roadmaps, delivery plans show us the problems that the team is solving, in what order and over what timeframe. In addition, they:

  • focus on specific tasks or outputs (as well as problems to solve or outcomes)
  • get more specific on who will be doing the work, by when and in what order (much more specific than now, next and later)

Delivery plans are primarily targeted at an internal audience: the people who are building the product, and the leaders who are overseeing that work. Their main purpose is to help the organisation plan and deliver work. Recently I have been working with delivery plans at two different levels:

Tools like Linear and Jira can automatically generate delivery plans and timelines

Shorter-term iteration plans from teams

Teams working in sprints will usually have at least the next few weeks of work mapped out in detail in tools like Linear or Jira. For work that’s in flight or starting soon, requirements for new features or functionality will be broken down into specific estimated tasks. Other work like bugs, support, technical rework or chores that would rarely make it into a roadmap are tracked here. In an ideal world, non-product work such as recruitment or learning & development would be tracked here too.

With all the work tracked in one place and estimated, tools like Linear and Jira will help teams estimate when the work will get done based on their prior delivery velocity and automatically generate project plans or GANTT charts. Tools like these give us much higher levels of accuracy in predicting what work will get done in the next 1-4 weeks, and when new work will be ready to start. A short-term view like this helps us get into the details of things like release planning, go-to-market planning, stakeholder management and planning ahead for activities like kicking off new work and scheduling user research.

In Linear, you can create specific views of work related to different sets of features that cross team boundaries, such as our work to bring in new datasets. This automatically creates a delivery plan that can be used by the cross-team working group that meets to align all data in work every fortnight.

Humans are bad at estimating software projects, so more often than not, work ends up taking longer than forecast (here is a technical explanation of why). To help counteract this, I like to encourage teams to add placeholder tasks to represent unknowns that could blow up and slow things down. As work progresses, these can be marked as done.

Higher-level internal timeline

Planning software work months and years in advance is very, very hard to do accurately. But not planning at all hides useful information about what we hope to achieve by when, what order things come and what we think is achievable.

For this reason, I like to maintain a high-level internal product timeline. It communicates at a high level where we think we will get to in the months and years to come. It includes information such as contracts coming to an end, legal deadlines, dependencies and strategic milestones that we don’t want to communicate externally but still want to aim for internally. This information helps teams to take a longer-term view where beneficial to do so. However, because it tries to look further into the future it is inherently a lot less accurate. It is important that this is understood by everyone.

Dependency map

Best game ever! Also a better than real World example of how a dependency map can be useful

Anyone who has played one of Sid Meir’s Civilization games will be familiar with the technology tree. New technologies unlock new capabilities (eg. units, buildings), and enable more advanced technologies to be researched in the future. The tech tree visualises all of these technologies, capabilities and dependencies on a visual map. Users can use the map to work backwards from specific capabilities they want to unlock and figure out which technologies they need to research to make that happen.

Dependencies are often mapped in delivery plans or timelines. Even so, I often maintain a standalone dependency map which focuses exclusively on dependencies. There are a few reasons why:

1.. Supporting strategic decision-making. Just like in a Civilization game, decision-makers can work backwards from longer-term ambitions and get a sense of the problems they need to solve to achieve them. In Civilization, you might face a choice between racing to discover gunpowder or developing ships which can navigate the great blue seas. There is usually a choice between doing everything slowly versus a smaller number of things faster, which is essentially a choice between having a clear and focused strategy or not. A dependency map visualises what we know about the likely costs of achieving a goal, and helps people to understand the trade-offs. It is particularly helpful when combined with some idea of how big or complex each item on the dependency map is.

2.. Supporting cross-team planning. In all big organisations where I have worked, there has been a regular (usually fortnightly) conversation about dependencies with a representative of each team. In that meeting, we review the dependency map and ask ourselves two questions. Question 1: are there any new dependencies we need to manage? Unlike in a video game, the future in real life is far from certain. New dependencies are discovered as we go along. Question 2: are any of these dependencies likely to block or impede us? If so, how do we stop that from happening? This allows us to keep up our delivery momentum and flag any delays or risks early.

3.. Low effort to maintain. There should not be too many dependencies to map and manage in product development. If there are, then that’s a sign of a much bigger problem. 15-30 minutes every couple of weeks is usually enough to maintain an accurate dependency map.

Why so many artefacts?

All of these artefacts are solving a similar set of problems: communicating work to do, timelines and priorities. It might seem unnecessary to have 3-4 different artefacts doing the same thing. After all, maintaining multiple artefacts can be time-consuming.

However, tools that do lots of things have a tendency to do all of them badly. Trying to combine all of these things into just 1-2 artefacts means each of those artefacts becomes more complex. More complex artefacts are harder for people to understand, which can lead to misalignment and misunderstanding, which can lead to costly mistakes. Personally, I find the benefit of improved team/stakeholder alignment generally outweighs the cost of maintaining multiple smaller artefacts. That said, I am always looking for ways to feed two birds with one scone where possible, and all of the above aren’t always necessary on every team.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *