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.

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.