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, 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. 

How frequently should I update the roadmap?

If you are part of a team that uses good software engineering practices, you’ll be doing frequent deliveries and, by frequently delivering, you’ll 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 a hardware based product, such as a server, a notebook, a smartphone, a tablet or even an operational system for these devices, your roadmap will be much less flexible. Many decisions will be taken months before your product is ready for users. 

Fortunately, continuous delivery in web products allows much more flexibility. It is a good idea to have a roadmap for a web 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.  

Should I keep my roadmap as a secret?

Many companies publish their roadmaps to users and to the market, while others prefer to 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 changes and if it’s disclosed publicly these changes will end up frustrating your users. 

Cone of uncertainty

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 researches 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. 

How to build a roadmap?

After understanding what a roadmap is, the question remaining is: how to build a roadmap? How to define which items are going to be in it and in what order? The answer has three elements: the company, the users and the possibilities. 

1) What are the company goals?

The first element a product manager should know in order to build the roadmap is the company 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 goal is and, from time to time, check if it is still the same.  

2) What do users want?

Knowing what are the company goals, the product manager should think of new products or evolve the existent ones in order to reach these goals. To do that, the product manager needs to know:

• The users: it is necessary to know the users or possible users of your product, and which problems or needs they have that can be solved by your product. There are innumerous tools and methods to get to know your client. Some examples are surveys, interviews, access data analysis, A/B test, prototypes, usability tests, etc. 
• Context: the context in which your users are in and, specifically, when they use the product. Context is the set of physical conditions and events that surround your user. For instance, your user accessing your product from a desktop at her home or from a smartphone in a supermarket is part of the context. 
• Market and competitors: either direct or indirect competitors. The direct ones are those that deliver the same or a similar product. The indirect competitors are the ones that somehow replace your product. For instance, suppose that you built a tool for managing service orders for small service providers. One of the main competitors is e-mail, because these small service providers can use it instead of using your tool. Or, yet, they can use the phone, paper and pen!

3) Can we do it?

So, you already know your company goals, understood your user and now you defined how is going to be your product or that new feature that will, at the same time, meet the company goals and be useful to your user. Now you need to know if it’s feasible and what would be the cost build it and offer it to your customers. It may seem possible to build 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 for alternatives. 

Putting everything into one image

After reading what to take in consideration while doing a roadmap, it is possible to translate product management into one image, that we saw in the article What is software product management?

In order to build your roadmap, you need to know the company goals, users, their needs and problems, and what can be done. With that in hands, you can build your roadmap. However, do not forget that the company 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. 

Roadmap = motivation + metrics

It is common to see roadmaps as a list of features, as depicted on 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 market. 

However, having the roadmap as a simple feature list is incomplete. There are two very important elements to explain why these features are in the roadmap in this priority order. 

1) What is the motivation?

As previously stated, we should take into account three aspects while building a roadmap:

• Company strategic goals;
• Problems and needs of the client;
• Available technology.

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 itself, it is important to state the motivation that lead the product manager to put it there. More clients? More revenue? Less users asking for support? Increase 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. 

2) How to measure the result?

Aside 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 less 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. 

An example

To illustrate the use of motivation plus metric 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 that the sender has the agreement from the recipients to send them e-mails. After that, it is key 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 any email addresses that trigger error messages or spam complaints. 

Those who don’t follow these simple rules will end up having a low e-mail delivery, will get disappointed with the product, and eventually will no longer use e-mail marketing considering it as an ineffective product. 

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:

• Motivation: to educate clients on good practices of using e-mail marketing so they would reach a higher success rate in their campaigns and, consequently, would not cancel the service;
• Metrics: the result of this feature is being measured in two ways: amount of deliveries (inbox delivery, opened message ratio, spam complaint ratio) and decrease of cancelling.

Detailing versus audience

As mentioned in the beginning of this article, 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 motivation, results and metrics than on the feature itself. 

The second aspect to consider is the level of detailing you have to display.

• Close customers: for the closest clients, it is possible to show more details, giving a medium-term vision. It is very important to create a good relationship with your close clients. You can guide the vision of your product based on the problems they have, and that your product is willing to solve. 
• Partners: to them it is worth to get into details, especially those who help the product to reach your clients. For instance, the final clients of the Locaweb hosting platform are the companies that host their websites there. However, you have to consider the partners, that is, the developers and agencies that develop these sites. In this case, you should continue to depict the roadmap as a list of features. 
• CEOs, vice-presidents and directors: at this point, we move to internal audience. This target group might be interested in the feature list, but they really want to know the motivation for these functionalities on the roadmap. 
• Sales and marketing: for sales and marketing teams, it is necessary to get into a little more detail. For sales, details are important because they may have already identified the market demand, and for marketing the need of more details comes from the promotion work they will do. 
• Product marketing: this group is practically the fourth element of that core team I mentioned in the article What is software product management? They must participate very closely of the product development, and must know the whole motivation and the metrics of the features in roadmap.
• Costumer service: this group does not have to know a lot about the motivation of the features as many of the internal groups, but it is the one that needs to know more details of these future features, since they communicate with your clients on a daily basis. 
• Engineering and UX: they are part of the product core team. They need all the details, motivations and metrics in order to do their job.
• Everyone else: in this case, detailing does not have to be high. The ideal is to talk in terms of features and you should disclose the features closer to being delivered. 

Roadmap or backlog?

A question that I frequently hear is: what is the difference between roadmap and backlog? 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”. In other words, these terms are equivalent. 

In my next article, I’ll discuss roadmap prioritizing techniques. Stay tuned!

Digital Product Management Books

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.