From six weeks roadmaps to OKRs
This article was originally posted in the Ontruck Product blog. On May 2019, I gave a talk at La Product Conf about this topic. You can see the talk here.
Last summer, we started working with OKRs to define the company priorities. We have just begun our third cycle; so it’s time to share our learnings.
In order to give context, at Ontruck we are currently 140 people in the company, 45 from Product & Tech. We have three offices (Madrid, London, Paris). We have a strong operation and sales teams which deal with real operations as we work with thousands of trucks every day.
Where we come from — Six weeks roadmaps
For over a year, we prioritized problems for six weeks organizing them in roadmaps.
Why six weeks?
It’s small enough to maintain stable priorities during the roadmap, even if the business changes priorities. And it’s big enough that the product and tech teams can tackle a complex problem. To give flexibility to business, we spent 20% of the time on new priorities which weren’t in the roadmap.
Why problems?
There are many ways of solving a problem. If you prioritize a project without understanding the problem well nor opening your mind to more ideas than the given solution; you are playing the lottery. We wrote an article about changing the mindset of business people from solutions to problems.
Who chose the priorities?
PMs did, aligned with business stakeholders. This was hard for some business people to accept, as some were used to prioritize solutions.
Which challenges did we face with this way of working?
Some business managers thought that the prioritization was arbitrary.
Each business manager sees the reality from his/her own view, but the Product Manager needs to see the whole. A middle manager may think one problem is the biggest one, but when you compare it with the problems of other departments it isn’t that big.
Another challenge was that these roadmaps were priorities for Product & Tech, but Business had its own priorities and KPIs. As both weren’t necessarily aligned, and as we had more stakeholders, it was clear that we needed to change how we prioritized as a company.
This way of prioritizing worked us reasonably well for over a year, on which we grew from 30 to 120 employees, from one PM to four PMs, and from four stakeholders to fourteen.
New way — OKRs
If you don’t know well what’s an OKR (Objective Key Result), read the following article. It explains really well this framework to prioritize.
niket
In order to start working with OKRs, we did the following changes in the organization last summer:
- We organized the company into four cross-department areas. In our case, they are Shipper Experience, Carrier Experience, Operations, and Marketplace Dynamics (pricing, routing, GIS…). Each area includes several departments, not only Product & Tech. Apart, we had two half-product teams like Internal Tools (CRM, billing, accounting) and Platform.
- We appointed a Business Lead, a PM, and an Engineering Lead for each of them. The first Business Leads were all C-level. The role of the Business Lead is to set and follow up on the business priorities, aligned with the PM and the rest of middle-managers of that area.
We decided to start with quarterly OKRs just for those cross-department areas. Six months later, we haven’t yet done OKRs at a team or individual level. We will probably do soon, but we are still learning the framework.
How do we set OKRs?
- We start with a discussion on management on which are our biggest priorities as a company. These priorities are clearly defined when they are accompanied with the Business Plan.
- The Business Lead and PM lead the discussion with the rest of leaders of that area (local Heads, Marketing, Finance, Engineering Lead, BI Lead) on which should be the OKRs given the company priorities, and their own problems.
- OKRs are goals for the whole cross-department area. Some Key Results are more Sales oriented (with help from BI or Product) and others are more Tech-driven (with help from Product or Ops).
- In order to set the numbers of current status and target, we work very closely with BI; which is an integral part of the conversations, not just someone who does the numbers.
- Business Leads, PMs and Engineering Leads meet horizontally to align OKRs between areas. We make sure they are all aligned, the sum of all matches the company priorities, and we won’t have any blocker because of resources or dependencies.
- We kick-off the OKR cycle with different sessions to explain them to all departments. Everyone needs to know they are the priorities as a company, OKRs aren’t just the priorities of the product squad. On this OKR kick-off, it’s interesting to do a deep down on sub-KPIs, and the problems we know that need to be solved.
How do we work with OKRs on our day-to-day?
Every Monday, BI analyst shares a summary of how the numbers progress and s/he raises concerns to be reviewed by Business Lead or PM.
Fortnightly, Business Lead, PM and BI lead meet to review the progress. They go deeper into the data, raise blockers, and align priorities.
Fortnightly on the other week, all leaders of the area meet to discuss initiatives, blockers, and priorities. The meeting document is previously filled with an updated status of all current initiatives.
Each department cascades the OKRs and initiatives depending on their way of working. It’s not the same how Sales and Ops work (short-term vision, deal with the current day) than how Product and Tech work (short-to-long-term vision, prepare for the next) for example.
From OKRs to Solutions
On the Product side, we need to transform a Key Result — business challenge– like “Increase the monthly average number of orders from X to Y” into the problems which are blocking us to reach that target, and from them into solutions.
While setting up the OKRs, and on the first weeks of the cycle, we do a lot of problem discovery looking at data, processes and talking to our colleagues in other departments and clients. This is one of the main tasks of the Product Manager. Find out what problems we need to solve to reach those OKRs.
Then, the Design and Tech team will work on solving them.
- By understanding why those problems are happening and which are the expectations and real needs of the users
- By designing and implementing different solutions
We don’t how long is going to take to reach a certain KR target. It depends on how well we understand the problems at the beginning of the cycle, how complex those are and if they are going to be tackled by product, business or a combined effort. We may solve a KR in two weeks or we may need 2 months.
Our mindset is to prioritize KRs, tackle them and once we have reached 70% of the target, move to the next KR. If we see an opportunity to improve one, even more, we may do if the impact is clear and we don’t block an improvement in another KRs. This means that we can design different solutions, but if the first one achieves its objective, we don’t do the other. This has also happened to us when we change a process in Ops or Business; as we achieved the KR target, no new product solutions are needed.
Challenges
We are still learning about these challenges:
- Knowledge transfer so the Product Designer is clear on which problem(s) s/he has to work on. We have seen that it works much better when the PM does properly the discovery phase and translates the KR into different problems. S/he prioritizes one or several of them to the Product Designer and Tech team. They focus on those specific problems.
- Maintain Tech team engaged about KRs. Tools like Jira promote the focus on user stories, which are several levels separate from KRs (KR → Problem → Solution=Epic → User Stories). There needs to be a great communication so the tech team knows and feels their work contributes to the company goals. One way of doing this is by reviewing the KRs on the sprint planning and reminding which one attacks each project/user story.
- Business people have their own KPIs which influence their bonus, and those are different from OKRs (it’s good that OKRs aren’t included in the bonus). It’s challenging to talk about KPIs and OKRs at the same time, while at the same time their day to day is focused on operating the business.
- We don’t do roadmaps, we focus on the quarterly OKRs. However, PMs needs to plan when and how to tackle them. This requires a combined effort with business as there can be dependencies.
Recommendations to start OKRs
- Start just with team OKRs. It’s a tool people need to learn, so you want to start slowly. It’s better to start with the most high-level teams possible (that’s why we started with those four cross-department areas), as people need to be convinced about their usefulness.
- The first draft of OKR should be proposed by a few people. Send it, and do a session with the rest of middle managers to gather feedback. When the team has learned over several iterations, move into a more bottom-up approach.
- It takes time, especially the first times. It’s still taking us a month of discussions to set each cycle of OKRs. Not only we need to align business-product-tech, but also between squads.
- Don’t start them in summer. Our first month of OKRs was last August. As you can imagine, with most of the business side of the company on holidays, we didn’t advance much.
KRs need to follow the SMART guidelines
SMART is a mnemonic acronym, giving criteria to guide in the setting of objectives. KRs need to be Specific, Measurable, Attainable, Realistic and Timely. Some tips:
- Don’t have a KR like “Deploy X feature”. Think which is the metric you want to move instead. “Increase the user conversion on the 1st month from x% to y%”. This mindset will make you open your mind to thinking on the problem, and other potential solutions.
- You need to measure it every week. Make sure you choose a KPI you can track clearly every week.
- Choose your targets based on the Business Plan. Be ambitious, but realistic.
- It always takes longer than expected to find the current metric and set the target. It’s better if you do that some weeks in advance.
Tips to set great OKRs
- Make sure all OKRs are cross-department priorities. Even if one is more related to a certain department (ex: “Reduce loading time from X to Y seconds”), you want other departments to buy it. This is the moment to prioritize together. You don’t want other departments to challenge the prioritization one month later.
- When you prioritize problems, it happens that some of them are in different squads. Who should tackle them? One or several squads? This has happened to us in our last cycle. We analyzed the pros and cons, and we decided to give full ownership of certain problems for each squad. We have favored ownership vs need of coordination and constant alignment. This has required to move some people temporarily between squads (we call this ‘doing an Erasmus’). These discussions take time.
- Be careful which OKRs you set on a cycle which has a peak in sales (and business is focused on it). Our experience is that they are fully focused on their KPIs and their day to day job.
As I said at the beginning, we still have to learn a lot about setting and working towards OKRs; but we feel they are a powerful tool to align everyone in the same direction, maintain the focus on business, and structure the teams to think on problems before implementing initiatives.
We would love to know your experience working with OKRs and get new tips to apply this year.
Questions & Answers
If you have any, let me know in the comments!
When do you communicate the roadmap to the rest of the team?
We don’t do roadmaps. At the beginning of the OKR cycle, we communicate them to the whole company (through an email and specific sessions). Every two weeks, PM+BL may decide to change priorities depending on the progress. It’s the responsibility of the PM to maintain the stakeholders updated on product initiatives.
How to track non-numeric KPIs?
Key Results need to follow the SMART approach, so they need to be measurable. If you have a big project like building a new product or rebuilding something, probably you don’t need OKRs for that cycle. But if you are doing something in order to reach a business target, you should have that in mind, not just the project.
How do we close the gap between OKRs and tasks?
I’ve explained above how we are doing it. We move from OKRs → Problems → Solutions → User Stories
How do we manage the OKRs kick-off?
We do a session with the departments with those OKRs. We explained to them why those OKRs are key, how they are aligned with the company goals and the business plan. We also go a bit deep down on the problems we are facing, and how we are thinking of attacking them (ex: if a KR will be more sales or tech-focused)
How was the experience setting KRs for dev teams where the results are more difficult to express numerically?
We are currently doing OKRs for the squads, so we haven’t yet done pure OKRs for Tech or other departments. But I can share an example which may help. On our last cycle, we wanted to clean and improve our internal Ops tool because we had been iterating it quickly, and users were suffering from small things. What we did was a shadowing of our users, list all pain points, rate their impact and cost, and prioritize them. The KR was “Reduce pain points in Ops tool from X to Y”. There was friction with the team when we were defining it, but it has worked out great as the KR is business and user-oriented.
What tool do we use to track OKRs?
Dashboards are in Tableau. We tested having the OKRs summary in Coda. As we have finally moved to Notion, each team has them there. We share them every week on Slack.