Growth: what are roadmap and OKR?

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.

How frequently should I update the 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 suggestions, 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 operating 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.

12-month rolling roadmaps

During my time at Conta Azul 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.

THE MOTIVATION

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.

ELEMENTS AND HOW TO USE THE 12-MONTH ROLLING ROADMAP

The basic elements that should be in a 12-month rolling roadmap are:

• Objectives and metrics: it is placed at the top of the slide because this is the most important thing of the roadmap, what you are planning to achieve by doing the things you plan to do and how do you measure that you achieved. From these, you create your OKRs.
• Deliveries: here we have what is planned to be delivered by each team to achieve the objectives. It’s important to note down when a new team will be hired and onboarded. Normally it takes some time to hire people and have them onboarded with enough knowledge in order to deliver something. The deliveries are boxes of one or more months. That does not mean that delivery will happen only once per month. Teams should be deploying in production every week, every day, every hour if possible. This means that these deliveries are high-level deliveries, composed of many smaller deliveries that are one level down of details from what is shown in the 12-month rolling roadmaps. For those familiar with agile methodologies, think in terms of themes, epics, and stories. In the 12-month rolling roadmap we are at the level of themes and epics, we don’t go to the level of detail of stories. Note that deliveries for the upcoming quarter are in darker green while the others are in lighter green. This is by design, to show that we are more certain of the things that are closer. It is the job of the product manager to present this roadmap to maintain the upcoming quarter focus of the discussion. If your stakeholders want to discuss deliveries later in the roadmap, the only discussion that is important is if that delivery should happen in the upcoming quarter and, if so, what should be postponed.
• Discoveries: the same way you present your deliveries in a timeline, you can present the required discoveries you need to do prior to the deliveries. Again, the result of discovery should not be presented only after one or more months. The discovery team (product manager, product designer, and someone from engineering) will be making discoveries and sharing them with stakeholders on a weekly or even daily basis, but a better full picture of the discovery may need more time to be put together. This element is optional.
• Constraints: if you have any relevant constraints, it is important to be placed here. In this example, the government was rolling out a new invoice layout that should be used since April 2018. For this reason, our invoicing system should be prepared to issue invoices in this new format by then. This element is also optional.

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

Should I keep a secret about my roadmap?

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.

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

How to build a roadmap?

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.

WHAT ARE THE COMPANY’S GOALS?

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

WHAT DO USERS WANT?

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:

• 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 numerous tools and methods to get to know your client. Some examples are surveys, interviews, access data analysis, A/B test, prototypes, usability test, 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 or from a smartphone 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 orders of service for small service providers. One of the main competitors is e-mail because these small providers can use it instead of using your tool. Or, yet, they can use the phone, paper, and pen!

CAN WE DO IT?

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.

Putting everything into one image

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.

Roadmap = motivation + metrics

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.

WHAT’S THE MOTIVATION?

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

• Company’s 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 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.

HOW TO MEASURE THE RESULT?

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 them? 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 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:

• 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: the amount of deliveries (inbox delivery, opened message ratio, spam complaint ratio) and decrease of canceling.

OKRs, the future of product roadmaps

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.

HOW DOES OKRS WORK?

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.

IMPLEMENTING OKRS AT LOCAWEB

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?

FROM TODOERS TO POINTER MANAGERS

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.

OKRs or Roadmaps?

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:

• Innovation: from all 4 lifecycle stages of a software product, Innovation is the one that holds the biggest amount of doubt. It is also the stage that holds the biggest number of books. Any book on innovation and startups is helpful when your product is in this stage. The main objective is to create a product that addresses the problems and needs of a group of customers. For this reason, during this phase there’s only one Objective, to find product-market fit, and to measure this Objective we can use various Key Results that demonstrate customer engagement and satisfaction. In the Innovation stage, we should use neither OKR nor roadmaps. We should use the MVP (Minimum Viable Product) framework of build-measure-learn to reach the Objective of finding product-market fit.
• Growth: In the growth stage, when the product has been developed and launched, we should worry about how to manage the product during its growth. Since during the innovation phase we built an MVP to reach our Objective of finding product-market fit, our product is quite incomplete, so we should have a roadmap describing which features we will build plus the motivation to build each feature and the metrics that will show us that we are fulfilling the motivation to build each feature, as I described in my article about the roadmap. Motivation is another word for Objective and Metrics are the same as Key Results. In the Growth stage, we should use Roadmaps together with OKR, since in the Innovation phase we launched an MVP lacking many features that would make the product more complete, and now we need to implement those features.
• Maturity: After growth, comes maturity. In this phase, our product reached its potential market and consequently doesn’t grow as fast as it grew in the Growth phase. When a product reaches this stage, it has all the needed features and there’s no need for a roadmap anymore. In the Maturity stage, we should use only OKRs to manage the product development since in this phase we will be optimizing the product to fulfill its Objectives.
• End of life: After maturity, or when the product is developed but does not find product-market fit, comes the stage is known as the end of life, or sunset, of a software product. In this phase, like in the Maturity phase, a roadmap is not needed since it doesn’t make sense to build any additional features. If your product reached the End of life phase after the Maturity phase, it already has all the features it needs to have. If your product reached the End of life phase right after the Innovation phase because it didn’t find the product-market fit, you should not invest any effort in building any additional features. At the End of life stage, we should use only OKRs to manage the product development since in this phase our only Objective is to stop serving the product.

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.

Detailing versus audience

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.

• General target: 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.
• Close clients: 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 getting 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 an 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 the 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’s demand, and for marketing, the need for more details comes from the publicity work they will do.
• Product marketing: this group is practically the fourth element of that core team I mentioned in the chapter What is software product management? They must participate very closely in the product’s development and must know the whole motivation and the metrics of the features in the roadmap.
• Customer 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, for it communicates with their clients on a daily basis.
• Engineering and UX: they are part of the product’s core team. They need all the details, motivations, and metrics in order to do their job.

Roadmap or backlog?

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.

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

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

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.