A roadmap is just a tool. It can be useful for two things:

• Expressing priorities: the presence or absence of projects on a roadmap should represent what you, your team, and your stakeholders agree is important.
• Communicating when things will happen: roadmaps predict the future, estimating when features will ship and when your team will be ready to start work on exciting new projects.

The act of creating a roadmap often has positive side-effects. It can prompt you to break big projects down into smaller milestones. It can also help reveal dependencies between projects. However, the primary purpose is communication – maintaining focus within your team, and projecting your plans and progress across the wider business.

Let’s address a common misconception up front: roadmaps don’t need to be all about deadlines. My teams set fixed dates sparingly. Sure, we have the occational major product launch, regulatory commitment, or technical migration; fixed points in time are simple constraints to plan around. But our default operating model is more iterative, and roadmaps act as a prioritisation aid in a continuous planning process.

Scale

Small companies don’t need roadmaps. A startup can just put their business priorities on a stack rank, or maybe the priorities are implicit in the team structure. That approach doesn’t scale very far, though. Once you have a dozen teams, nobody can keep the complete picture of what everybody is working on in their head.

You need some level of process to document who is trying to build what by when. Otherwise, teams will inevitably step on each others’ toes, set clashing ship dates, pull in opposite directions, or work on things that aren’t really important for the business. A roadmap is usually part of the solution – it’s an efficient window into a team’s priorities, status, and milestones.

Decay

Roadmaps decay in unpredictable ways unless you reconcile them with reality continuously. A static roadmap will do more harm than good. As soon as any one piece of the puzzle changes, the whole timeline is misinformation.

If you’re going to use a roadmap, the team responsible for delivering the projects needs to own it, integrate it into their planning process, and keep it updated every single week.

I work with cross-functional product engineering teams, meaning the team is staffed to deliver on their goals with as few dependencies on external functions as possible. Product managers, designers, engineers, data scientists, researchers, and marketers collaborate directly every day. This is how I think about roadmaps in that context:

• We need to know what we’re doing for the next 2 weeks with near certainty, so engineers can mostly focus on shipping the next chunk of value to customers.
• We need 80% confidence in our plan for the next 6 weeks, so we can line up research, design exploration, and technical discovery for the next set of things we’re planning to build.
• We should have a set of candidate projects for the next 3-6 months, so we can evaluate the impact of new opportunities against the current default path we’ve defined in our roadmap.

Anything more than 3 months away is just a blurry shape of an opportunity. We probably haven’t done the discovery work to understand the effort and potential impact yet. We might even have better ideas before we get there – every time we ship, we learn something we didn’t know when we drafted the roadmap. The trick is to maintain this rolling window, so new projects are coming into focus and being reprioritised continuously.

Edge cases

Roadmaps want to make every plan linear. Sometimes reality is more complex. It’s important to communicate uncertainty. In the planning process at Monzo, every roadmap is accompanied by a table of risks. We present our default path and simultaniously highlight all of the reasons we might need to deviate from it.

At one point, my team had a plan that was so dependent on a series of long-running experiments that we really struggled to estimate when the feature would ship. We started with a wide launch window on a roadmap, but we soon realised it would be neater to represent our process as a decision tree with a fork for each experiment iteration. That shifted the focus from an arbitrary launch date to the next decision point that would narrow the range of possibilities.

Wrong turns

You can do a lot of damage by using a tool in the wrong way. There are endless planning anti-patterns. The humble roadmap often gets unfairly implicated in a bad situation. Here are a couple of examples. No identification with actual persons (living or deceased), places, buildings, and products is intended or should be inferred.

1. You created a roadmap as part of a regular planning cycle, but the team isn’t actually using it to plan their work. It’s seen as belonging to leadership. It’s not a living document. Executives are mad because the team communicated timelines and didn’t deliver. The team is mad because they’re working hard and the reasoning behind every change of plans has been flawless. The team starts to pad estimates. The executives start to fixate on deadlines. Poorly managed communication is now a lack of trust.

2. You have a roadmap that gets updated continuously, but nobody on the team agrees with it. They don’t understand how the roadmap was created or why these particular projects were prioritised. They push for some time to tackle technical debt. In a distant meeting room, executives puzzle about these new projects that don’t align with business goals.

If you have a delivery problem or an immature company planning process, then a detailed roadmap is not going to save you. Focus on developing an empowered team that’s connected to customers, understands the business, and delivers incremental value with short feedback loops. Pick one thing and ship it while you get the foundations in place. A roadmap is no substitute for a mission-driven, autonomous team.

A quickstart guide

If you’ve made it this far, maybe a roadmap is for you. Here’s a quickstart guide for roadmapping:

1. Keep your roadmap up-to-date. Every week! Exercise ownership and re-plan, but remember to communicate major changes to your stakeholders.
2. Use your roadmap to create focus. Understand your team’s work-in-progress limits. Finishing things is better than starting things.
3. Don’t try to maximally allocate time. Leave ~20% capacity for unplanned work.
4. Create space for things that are too small for the roadmap, like polish, delight, and keeping the lights on.
5. Every roadmap should come with a set of risks and dependencies that explain why you might deviate from the plan (and start conversations on what to do about it). Embrace the uncertainty.
6. Don’t force a non-linear plan into a roadmap just to fit the mould. Other tools are available.
7. Ability to deliver a roadmap is a fairly poor indicator of team performance. Instead, measure the outcomes your customers and business care about.
8. There’s a difference between launching a feature and landing it. Plan space to iterate and get the product right.
9. “It’s on the roadmap” is a lazy, circular argument for doing something. Use the roadmap to challenge whether you’re spending time on the most impactful projects.
10. Short feedback loops are better than long-term plans. Get product changes into the hands of the your team, staff, and customers as soon as possible. If you discover you’re building the wrong thing, tear up your roadmap!