A roadmap is a layout of all the goals and milestones a product should hit during its lifetime. Every company runs a roadmap, but each company runs it in a different way.
In the product world, there are three main types of roadmaps. First is the traditional roadmap, which lays out what will be built quarterly, semi-annually, and annually. As a product manager, you need to understand that a traditional roadmap is almost always inaccurate and it is mainly used to speak with executives and investors about the progress of a product through its development. It is useful to display clear goals for the company and product.
Below is an example of a traditional roadmap that I was taught in college. The dreaded gantt chart. With hard dates and a regimented schedule, how could it ever predict the future? As a mechanical engineer, you’d figure a well-respected engineering school would elaborate further on the different types of roadmaps. I now realize a gantt chart and traditional roadmaps are mainly for construction and project management, be careful to not mix them into product development, especially software development.
The second type of roadmap emerges in software development. It is extremely difficult to put hard dates on software features and milestones. This agile style roadmap allows for the flexibility needed in agile development frameworks. The roadmap is structured into a chart of three groups; Near-Term, Mid-term, and Long-term.
When running 1-2 week scrums in an agile development framework the product team is saying “during this time we are going to attempt to solve this user need through this method”. It may work or it may not. Having hard dates contradicts the concept of this framework.
|1. Feature 1|
2. Feature 2
|1. Update 1.4|
2. Feature 3
|1. Feature 4|
2. Update 2.0
Breaking features into the three categories shown above allows for the flexibility and prioritization required in agile software development. Here is what we are doing now (Near-Term), here is what comes next (Mid-Term), and then here is what we want to get to eventually but is not a priority right now. This is used widely in B2C companies that don’t have financial issues and can take their time to develop their product.
Lastly, a roadmap called Objectives and Key Results or OKRs is a way to track work that needs to happen without committing to a solution. In general, for a roadmap to be useful, you need to have clear goals. The way an OKR is laid out allows for flexibility but gives clarity on what result is trying to be achieved.
According to the creator, John Doerr, the proper way to write an OKR is like this:
“I will X as measured by Y”
Where X is the objective and Y is the set of key results you are looking to achieve. An OKR roadmap removed a defined method to achieve this key result. This is crucial as it provides the product team the freedom to brainstorm out-of-the-box solutions to achieve key results. This out-of-the-box thinking would then be called an initiative.
Using Uber let’s do an example.
X = Increase geographic coverage of drivers
Y= Increase coverage for all active cities to 75%
Y= Decrease pickup time to <10 mins in any coverage area during peak hours of usage
Now put it all together…
- I will increase the geographic coverage of drivers as measured by an increase in coverage for all active cities to 75%
- I will increase the geographic coverage of drivers as measured by a decrease in pickup time to <10 mins in any coverage area during peak hours.
Then the product team would get together and brainstorm initiatives to achieve these key metrics.
In the end, all roadmaps have the same goal. They are documents that tell a company and product team what features, solutions, or products will be created at various times. Traditional roadmaps have been phased out of tech companies to make way for the agile or OKRs roadmap. Depending on your product and company will decide what roadmap you will work with.
This post was inspired by an interesting Twitter thread I found recently that dives into the history and usefulness of OKRs in real-world scenarios.