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.
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.
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.
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.
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:
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.
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.
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:
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.
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:
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.
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!
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.