The roadmap is a very useful tool for product managers. It enables us to plan and communicate the view of the future that you have for your product.
Check out some roadmap examples:
The first two examples are short-term roadmaps, that is, they display a few months and the features that are going to be in each version of the software. On the other hand, in the Windows Server roadmap, we see a broader view, without major details but a long-term roadmap, holding almost a decade.
By setting up a roadmap for your product, you must adequate it to your audience. In other words, you must add more or less details, depending on to whom you will present this roadmap.
If you are part of a team that uses good practices in software engineering, you are going to be doing frequent deliveries and, by frequently delivering, you will have plenty of feedback from your users about the software and the features you are delivering. This will probably change your roadmap, because when users start to use a new feature, they will make suggestions for your software. However, even if you don’t get any suggestion, just seeing them using it will give you new ideas for your product.
If you are a product manager for hardware — such as a server, a notebook, a smartphone, a tablet, a smartwatch or even the operational system for these devices — your roadmap will be much less flexible. Many decisions will be taken months before your product is ready for the users.
Fortunately, continuous delivery in digital products allows much more flexibility. It is important to have a roadmap for a digital product of at least 12 months. However, this roadmap will frequently change, according to what you and your team will learn with your product’s users and with the way the market reacts to your novelties. Therefore, at each change of course you should update your roadmap and communicate it to everyone involved.
During my time at ContaAzul and now at Gympass my teams and I have been using a roadmap structure that has been very helpful for us to achieve the two main goals of product roadmaps, planning what are the next steps of the product and aligning the view of the product future with the entire organization.
We call this roadmap structure the 12-month rolling roadmap. I know that some people will comment that having a 12-month roadmap will prevent us from being agile, that we should have no more than 3 months planned ahead, ideally we should have no roadmap and we should only use OKRs. I tend to agree with all these comments. However, my experience has showed me that the need for roadmaps depends a lot on the product development culture maturity of the company. Probably companies like Google and Facebook have such maturity of product development culture that roadmaps are not needed and the product is developed only based on OKRs. This is also the case when we are managing mature products.
However, if you are working on a product in its innovation or growth phase, and your company does not have yet a mature product development culture, roadmaps in general and the 12-month rolling roadmap that I will present here can be very helpful.
When a product manager presents to stakeholders a 3-month roadmap, it is not unusual that the product manager gets asked questions like “what about feature X?” or “when will we put more energy on objective Y?”. The answer is normally something in the lines of “it’s planned for future quarters but I believe that what we have planned for the coming quarter are the most important things to work on, do you agree?”. This answer will probably generate some frustration.
If a product manager decides not to use roadmaps and only use OKRs to present her plans for her product to stakeholders, the questions she will get will be in the lines of “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”
For this reason, we created the 12-month rolling roadmap. It helps product managers communicate the view of the future of their product and, consequently, this will elevate the discussion to a more strategic level. Here’s an example of a 12-month rolling roadmap for a team that takes care of invoice issuance in an ERP product for SMBs.
The basic elements that should be in a 12-month rolling roadmap are:
You can add other elements if it makes sense to you, your team, and your stakeholders. At Gympass we are building an integration layer that is enabling us to easily integrate our systems with gym booking and ERP systems as well as with payroll systems. As we build the building blocks of these integration layers, we are getting ready to offer specific types of professional services. For this reason, we created in our 12-month rolling roadmap an element called Professional Services readiness, to show stakeholders when we will be able to do certain types of integrations with our professional services team.
Note that with the 12-month rolling roadmap, when you get questions like “what about feature X?” or “when will we put more energy on objective Y?” or “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”, it is easier to answer because you have a big picture of what’s coming next.
We named it “rolling roadmap” for a reason. It has to be reviewed regularly. If nothing changes, it should be reviewed at least quarterly, to guarantee it is aligned with the product vision and strategy. If there are changes in the external environment (new regulation, new competitors, etc) or in the internal environment (people leaving the team, change in company strategy, etc.) and these changes need to be dealt immediately, the 12-month rolling roadmap is the perfect tool to help everyone understand the impact of the changes in the objectives and deliveries of the team.
Many companies publish their roadmaps to users and to the market, while others rather keep them locked away fearing that competitors will copy their steps. I believe that the short-term roadmap (1 to 3 months) must be known by its users, so they can even present some feedback on it.
Regarding the market, you can respond reactively, that is, when asked, you can answer if it is or it is not on your short-term roadmap. The medium and long-term ones (three or more months) are not to be unveiled, not only for keeping them away from competitors, but because there are big chances of changing and, if it’s disclosed publicly, these changes will end up frustrating its users.
The cone of uncertainty is a concept used in project management that describes the amount of uncertainty through a given project’s lifecycle.
In the beginning, very little is known and the uncertainty is high. As we move forward in the project, we learn more and the uncertainty diminishes.
Software researchers concluded that before starting a software development project, the uncertainty might vary from 0 to 4 times of the initially estimated regarding the time and the cost of developing the software.
After understanding what a roadmap is, the question remaining is: how to build a roadmap? That is, how to define which items are going to be in it and their order? The answer has three elements: the company, the users, and the possibilities.
The first element a product manager should know in order to build the roadmap is the company’s goals. The main goal of a company is not revenue or profit margin. Revenue and profit are its financial health indexes that can even show if its goals are being reached.
However, sometimes revenue and profit are not necessarily linked to goals. Moreover, these goals can change over time. For instance, in the beginning of any social network, the goal is not revenue but the number of users and the certainty that they will come back. Only after having a considerable base of active users that is reasonable to think of how to profit, whether with users or companies interested in communicating with them. That is why it is important that the product manager knows what the company’s goal is and, from time to time, check if it is still the same.
Knowing what are the company’s goals, the product manager should think of new products or evolve the existing ones in order to reach these goals. To do that, the product manager needs to know:
So, you already know your company’s goals, understood your user and now you defined how your product is going to be, or that new feature that will, at the same time, meet the company’s goals and be useful to your user. Now you need to know if it’s feasible and what would be the cost. It may seem possible of building it, but if it takes too many months and too much money, it may not be worth it. Then you have the conversation with the team that will build the new product or feature; the people from UX and development. They will tell the cost, time-wise or money-wise, and if it’s not acceptable you’ll have to discuss in order to seek alternatives.
After reading what to take into consideration while doing a roadmap, it is possible to translate product management into one image, that we saw in the chapter What is software product management?
In order to build your roadmap, you need to know the company’s goals, users, their needs and problems, and what can be done. With that in hand, you can build your roadmap. However, do not forget that the company’s goals may change, as well as the users’ problems and needs, and what can be done. Therefore, it is essential to make periodic reviews in your roadmap in order to keep it lined up with these three elements.
It is common to see roadmaps as a list of features, as depicted in the previous examples. This type of roadmap works well when you have to present it to an audience outside your company, that is, to users and the market.
Having the roadmap as a simple feature list is incomplete. Following are two very important elements to explain why these features are in the roadmap in this priority order.
As previously stated, we should take into account three aspects while building a roadmap:
These are the inputs that the product manager has to take into consideration while building a roadmap, that is, to define which features to add up to it and in what order. For that reason, for the roadmap that is going to be used internally, in addition to the features themselves, it is important to state the motivation that lead the product manager to put it there. More clients? More revenue? Fewer client requirements asking for support? Increasing engagement? Etc.
Having the feature motivation in the roadmap will help the product manager to set the context for the team that will work on creating these features.
Aside from the motivation, the roadmap must also have an indication of how to measure if what motivates the features is being reached. If the motivation is to increase the number of clients, how to measure it? If it is to get more revenue, how to measure it? If it is fewer support requirements, how to measure it? If it is increasing engagement, how to measure it?
It is important to define how to measure if a given feature has accomplished its motivation and effectively measure it. It is very likely that the way of measuring it must be considered while developing the feature. Most likely, it requires adding specific programming code to allow this measurement.
To illustrate the use of motivation plus metrics while building a roadmap, I’ll use an example from Locaweb: an e-mail marketing product for sending e-mails.
If you use e-mail marketing, you know that is necessary to follow some good practices in order to reach a good delivery ratio. First, it is necessary the agreement of the recipients to send them e-mails. After that, it is fundamental to hold a frequency of e-mails. If you send a message once and never again, you are not going to create a relationship with the recipient. Besides, it is important to keep your recipient address list clean, that is, remove an e-mail address that triggers error messages or spam complaints.
Those who don’t follow these simple rules will end up having a low e-mail delivery ratio, will get disappointed with the product, and eventually will no longer use e-mail marketing for thinking that it is ineffective.
Thinking about this, we decided at Locaweb to create the concept of reputation, translated into a percentage that aims to inform the clients how well they are doing while following these good practices. With that, we can educate them regarding the good practices of using e-mail marketing.
Therefore, the feature reputation from Locaweb’s e-mail marketing had:
Since 2012, we review Locaweb’s product roadmaps every quarter. At the beginning of each quarter, we look back on what was done in the previous quarter, which items were delivered, which weren’t, and what were the reasons for success or failure. Then we plan what to do in the following quarter.
In the middle of 2014, I wrote an article on writing roadmaps including the motivation behind each item in the roadmap and metrics that showed that the motivation was being fulfilled. It was the result of several conversations we had at Locaweb about having the roadmap as a list of items to make every quarter, but not always having clear why we were doing each of those planned items. Since that time we started to make our roadmaps with each item composed of three sub-items: what to do, why it had to be done, and what metric we expected to move when we do that item. However, while we try to make clear the motivation and the metric of each roadmap item, the discussions ended up mainly around the “what to do”.
In the first half of 2015, we heard about a framework called OKR, which means Objectives and Key Results. This framework has been used by Google since its early days and was brought there by John Doerr, an Intel employee, where this framework was created. John Doerr, after leaving Intel, became an investor in technology businesses such as Google, Amazon, Intuit, and Zynga and brought this framework to these companies. Several technology companies today use OKRs. A few more examples are LinkedIn, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix, and Spotify.
OKR is a framework derived from a management technique called Management by Objectives, a term coined by Peter Drucker in his book The Practice of Management, 1954. Management by Objectives is a process that requires the identification and accurate description of goals to achieve and deadlines for completion and monitoring. This process requires that those involved agree with what you want to achieve and that all of them play their roles for the achievement of the objectives.
There are several articles and videos that explain in detail how OKRs work, so I will make my explanation very brief. OKRs are composed of two parts, a goal (objective) and 2 to 5 key outcomes (key results) indicating that the goal was achieved. For example:
Objective: To have satisfied customers to the point of recommending our services to their friends.
Key Result 1: To maintain 80% of satisfaction survey notes above 8 on a scale from 0 to 10.
Key Result 2: At least 50% of new sales should come from recommendations of existing customers.
The goal does not necessarily need to have numbers. However, key results must always have numbers, i.e., there must be some metric and must say where we are and where we want to be with regards to the metric, that is, the goal we want to achieve with that metric.
It is recommended to have at least two key results. When there is only one key result, we can suffer from what is called the “perverse effect”. For example, suppose the goal is to raise the productivity of the telephone service team. Let’s say we define only one key result, the AHT (average handle time) which is now in 8 minutes and we want it to drop to 2 minutes. One way to achieve this key result is for the attendant to hang up the phone when close to 2 minutes. Of course, this would be bad for the quality of service, but the key result and the goal would be achieved. In this case, to balance the “perverse effect”, another key result is recommended to ensure that customer satisfaction is maintained.
After studying OKR for some time, we realized that it was very similar to what we always wanted to do, focusing more on the motivations and metrics than on the “what to do” itself. The big difference is that in OKRs the “what to do” simply does not exist. It can be discussed when defining each goal and its key results, but “what to do” is not documented and, therefore, it is not committed and can be changed. What matters is the goal and key results that indicate that the goal has been reached.
To help us in this change, we brought Felipe Castro from Lean Performance, a company that specialized in OKR implementation. We brought him in June 2015 and started implementation in the 3rd quarter of 2015 with a series of internal training on OKR, goal setting, metrics, and objectives. In August we made our first training planning session to set OKRs for the month of September. It was a test for us to understand a little better the mechanics of the OKR setting process. In late September we made our first planning session of a full quarter, where we defined the product development and marketing OKRs for the 4th quarter of 2015. In parallel, we continued with the quarterly product planning roadmap based on a list of items to do.
Each team updated their OKRs weekly. Furthermore, we followed the evolution of the roadmap monthly. We have seen throughout these follow-ups that the roadmap items were the tasks that enabled the achievement of the objectives and key results, i.e., there were monitoring tools — OKRs and Roadmaps — for the same job. Throughout these monitoring sessions, we had an epiphany: what if we abandon the traditional roadmap, the list of tasks to do, and focus only on defining and tracking OKRs?
That’s what we did in the 1st quarter of 2016. The planning was done completely based on goals and metrics that we wanted to move, i.e., the pointers we wanted to manage. We ceased being mere ToDoers, mere executors of tasks, to become pointer managers. Given a goal and a metric that indicates that this objective is being achieved, we decided what to do. In the OKRs review meeting for the 1st quarter of 2016 and planning for the 2nd quarter, no one missed the old roadmap list of tasks to do. Obviously, during the retrospective, each team commented a bit about what they did to move the pointers, but the “what to do” was just a means to achieve a goal, and not the goal itself. And of course, in each OKR planning session, the teams already have a sense of “what they will do” to achieve their goals, but they have the autonomy to decide “what to do” as they please.
In August 2016, after 11 years leading product development and management at Locaweb, I decided to move to ContaAzul, a SaaS ERP startup at Joinville, a city in the south of Brazil, to help them scale their product development team. When I arrived at ContaAzul, I noticed that they also used OKRs for the entire company, including the product development team. However, besides using OKR, they also used roadmaps and it didn’t seem it would be possible to stop using roadmaps and manage all product development efforts only using OKRs. That made me ponder if OKR can really substitute roadmaps or if there are circumstances where both tools can be used together. And if the latter is true, what are those circumstances.
When discussing this topic with people from the software industry, it became clear to me that the use of a roadmap or OKR depends on the stage of the product in its lifecycle. I discussed the 4 stages of a product lifecycle in the Lifecycle of a software product chapter.
As described in that article, the software product lifecycle has 4 stages:
For this reason, it is clear that OKRs substitute Roadmaps in all stages of the product lifecycle except for the Growth stage, where Roadmaps are very helpful to understand where your product is heading, i.e., to understand the future of your product. In the Growth stage, we should use Roadmaps and OKRs in conjunction to manage the product development.
As mentioned at the beginning of this chapter, the roadmap of your software product is your tool to communicate the vision of the future for your product. We know there are different types of targets that will demand different levels of detailing in your roadmap. In which level of detailing should we stand for each type of target?
The picture points out a suggestion of detailing level according to each audience. The first aspect you have to consider is whether the target is internal or external. As previously said, to external targets you will usually talk about features. To internal audiences, your focus will be more on results and metrics than on the feature itself.
The second aspect to consider is the level of detailing you to have to display.
A question that I frequently hear is: what is the difference between roadmap and backlog? The roadmap is your map or guide, that is, the things you have to do; backlog is the term used in agile methodologies for your “record of things to do”. So, these terms are equivalent and can be used interchangeably.
In the next chapter, we’ll approach roadmap prioritizing techniques.
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:
You can also acquire the books individually, by clicking on their titles above.
I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.