What is it? Who creates it? How often does it get updated? How far into the future does it go?
It turns out that when you ask engineering leaders (be it CTO's or VPs of Eng. or Directors of Eng.) in companies and startups they will generally give fairly similar answers to these questions. Certainly the processes used are different for companies at different sizes but it's always a bit of a struggle, so allow me to give you a basic rundown of the different moving parts and some strategies I employ and have heard others employ for creating their engineering roadmaps.
What is it?
The engineering roadmap is a list of features which the engineering team aims to build. It exists so that other stkeholders in the company (CEO, CFO, Head of Product, etc.) can see what engineerings direction is. This helps them feel confident that the correct features are being worked on. For engineering it is an important because it allows visibility into the value they are producing and it helps prevent new features being requested in a reactive haphazard way.
Regardless of its formal format its some sort of list that is easy to understand. I, and many others, recommend leaving implementation details and background information and business reasoning off of it altogether. Remember who is reading it (see below). As a general guideline I try to make sure it is understandable in less than 5 minutes of reading (aka bullet points!).
There is a surprising amount of agreement among engineering leaders about the general format for it. Clearly defined and prioritized for whats coming up next and less well-defined the farther into the future you get.
- Vision: I like keeping the vision or "mission" or "general direction" of the engineering team as a part of the roadmap. It's just a sentence or two that describes what you are working towards. It may change but usually it settles in as the company hits its stride and finds product market fit. The vision is also important because it can be referenced when stakeholders want something that doesn't fit it. Either the vision needs to change or they are recommending something that may divert away from the core product that engineering should be focusing on.
- Future: Features that the company currently thinks it definitely wants in the future. If its too out there keep it on a separate "ice-box"-type of list away from the roadmap. The features on here should be highly likely to actually be implemented. It is up to you to recommend things to go into the future bucket, and you should listen to input from the other stakeholders for this. These features do not need to be prioritized. These features are usually things where you hope to begin work within the next 3 months to a year. Further out than that and priorities may change enough that it gets discarded.
- Next: This bucket is usually somewhere between 2 weeks to 3 months out. The stakeholders grab features from the future bucket and put them IN PRIORITY ORDER in this bucket.
- Current: The things you are currently working on. This bucket should not change. At the end of a sprint features which are done are removed and whatever has highest priority in the next bucket is added.
There are certainly more involved systems to use, but you add complexity to the engineering roadmap and it‘s creation at your own peril. Be careful not to end up in endless "prioritization and feature meetings"-hell.
Who creates it?
Whoever is in charge of engineering is responsible for keeping it updated, but the stakeholders who have input on it are the different people who understand the different parts of the company. Usually it is some constellation of the CTO, CEO, Head of Product, Head of Marketing, but this does vary some. I would highly recommend you keep it to as few heads as possible to prevent bloating the amount of stakeholders. These heads can distill what their departments and the company needs.
How often does it get updated?
Some recommend having a constant conversation between the stakeholders about features and company direction to keep everyone in sync, others recommend having a meeting after every sprint to update the priorities and others say every quarter is enough. Find a system that works for you. If you are in charge of creating the roadmap then you will probably be looking and polishing it continually, it will be a living document.
Very simple example Roadmap
This is for a company that is trying to be your one-stop-shop for hiking maps.
- Allow hikers to rate hikes.
- integrate Colorado public hike dataset with our data.
- Allow hikers to friend each other.
- Allow hikers to recommend hikes to each other.
- Allow hikers to see notifications of when one of their friends completes a hike.
- Allow hikers to recommend hikes to the system. (crowdsource)
- Add way for shoe manufacturers to recommend shoes through our platform to hikers depending on which hikes they are going on.
- Parse hike data from Europe.
- Allow hikers to find and see maps of hikes that suit their physique and tastes in any country.
As you can see it gets less specific as you progress into the future. Next is in priority order. The vision doesn't actually take into account the shoe recommendations but it seems like a legit business vertical to monetize on and it is still very much within the realm of hiking, so I think its fine.
Anyway, I find this way to be the most intuitive way to approach an engineering roadmap, and in speaking to other engineering leaders I know i'm not the only one that roughly follows this format. But at the end of the day go with a system that works for your company/situation.
Remember, an engineering roadmap is not something which is written once and then set in stone. It needs to be an editable thing which reflects the current priorities of engineerings most important client, the company.