Locaweb is Brazil’s leader in web hosting and SaaS applications like email marketing and online store. Locaweb hosts approximately 23% of all Brazilian domains. I work there since 2005 and I’m responsible for managing product strategy, roadmaps, product life cycle and product development.
Since 2012 we review 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 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 are doing each 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 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 is 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 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 point to recommend our services to your friends
Key Result 1: 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 existing customers recommendations.
The goal does not necessarily need to have numbers. However, key results must always have numbers, i.e., must be some metric and must say where you are and where you want to be with regards to the metric, 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 what is called “perverse effect”. For example, suppose the goal is to raise the productivity of 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 the attendant 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” it is recommended another key result that ensures customer satisfaction to be 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 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 their 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 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 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 this monitoring sessions we had an epiphany: what if we abandon the traditional roadmap, the list of tasks to do, and we focus only on defining and tracking OKRs?
From ToDoers to needle 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 needles that wanted to manage. We cease to be mere ToDoers, mere executors of tasks, to become needle managers. Given a goal and a metric that indicates that this objective is being achieved, we decide what to do. In the OKRs review meeting for the 1st quarter of 2016 and planning of 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 needles, 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 autonomy to decide “what to do” as they please.
We have learned some valuable lessons during this almost one year in which we are working with OKRs. We frequently review these lessons learned so that we can continuously improve our OKRs:
As I said above, in our OKRs review and planning sessions at Locaweb, no one missed the list of tasks to do done that we used to discuss in our old roadmap quarterly review and planning sessions. During the review each team says a little bit about what they did to try to move the metric needle, but the “what to do” are only a means to achieve a goal, and not the goal itself. And of course in each OKR planning session the teams already have a good sense of “what they will do” to achieve their goals, but they have autonomy to decide and change the “what to do” as they wish, provided they achieve their goals.
For this reason, it is increasingly clear to me that the OKRs are the future of the roadmaps. It is a tool that puts the goals and metrics in the center of the discussion, leaving the decision on “what to do” more fluid and flexible, giving teams more autonomy in deciding what to do.
Product Management: Delight your customers with your software
In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.
The book is organized in 5 sections:
This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.
We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!