I’ll admit it. I’m a bit of a dummy when it comes to OKRs. Like, I understand OKRs and I understand what makes good OKRs.
Heck, I even agree that they’re an important tool.
Running an OKR setting workshop for product teams is a different game in 2021, especially when you have remote teams! It becomes so much harder.
Of course, not everyone would agree – some people are just naturals. I’m not, so I had to think about how I’d run it for quite a while.
I’ve also made some mistakes in previous situations, which I’ll try to outline.
Read on!
Note: I’ll be writing this from the Product Manager perspective, but I think most of the stuff is quite universal.
Why do I even need to run an OKR workshop with my team?
Let’s face it – OKRs aren’t going to be good if you don’t involve your team. At best, they won’t feel like it relates to them. At worst, you risk alienating and confusing your team and your stakeholders.
Just run the workshop, OK? If you really don’t like the results, you can always come up with your own later.
Why is running this remote workshop so hard?
You need to do quite a bit to run an OKR workshop. Here is what I think is hard about running these sessions:
- Lots of preparation needed to schedule these sessions. With a remote or partially remote team, finding good times is hard – but it also takes away from valuable engineering time
- There are many sessions. Can’t get it done in one day – our brain doesn’t work that way
- Oh god, OKRs are boring though
- I need everyone aligned on the same problems
- I really want all of my team involved
- I need them to actively participate, not just listen in
- OKRs are so boring
- I have to be very careful not to control the conversation with my own opinion
- I have to get my stakeholders to also see the same stuff that the team came up with, and get in the right mindset
- OKRs are really boring and reading them makes my brain turn off
- I hate fussing over wording of metrics, but it really is important to get it right
- When the sessions are virtual or via Zoom, collaborating is harder than when you’re sitting in the same room.
So, with that in mind, how do you run a virtual OKR workshop, and what should you look out for?
Planning the OKR workshop
This is my process for setting the OKRs via a series of workshops and off-line activities:
As you can see, some activities can and should be done offline, so as not to waste the entire team’s time. Particularly, filtering out things that don’t work or can’t be measured should be done separately.
Plan for who will attend and for how long
So first, note that OKR workshops take quite a bit of time – around 4-8 hours, but YMMV. This can be very taxing, especially for engineers.
Start by setting the schedule at least a few days before the first session, and figuring out who wants to attend.
My experience is that engineers and designers want to be involved, but may not want to sit in every session, so make the sessions optional.
Tips for engaging your team members
Tip 1: I recommend no more than two 1 to 1½-hour sessions a week, as the sessions can be quite heavy. This should result in the entire process taking about 4 weeks from start to finish (you can of course do it faster, but you may burn out your team in the process).
Tip 2: Start each session with a warm-up exercise, to get everyone talking. This can be as simple as getting them to add a statement at the top of the shared virtual page, getting up and writing something on the board, or it can follow your daily stand-up.
On my team, we liked playing “Two truths and a lie”, sharing a mildly embarrassing story, writing down what our guilty pleasure music/movies are and then guessing who wrote what, and describing a movie only with Emojis.
Tip 3: Give homework at the end of each session. I do this because not everyone is comfortable speaking up. Giving homework with a soft deadline is another way of engaging team members, and having them review the content.
Tip 4: Set reminders for the meetings. We use Slack’s reminders to remind team members to weigh in on this week’s sessions/topics.
With these tips out of the way, let’s take a look at the sessions themselves.
Session 1a: Set the context, and brainstorm on the problems at hand
In this session, set the context by reminding your team of the vision and mission. You can also relate to company vision or strategic goals your department may have.
After a quick warm-up or check-in, give your team 5-10 minutes to fill in the problems they see and want to solve in the near future.
Problems are just that – problems that you see, hear, or know about from your stakeholders and customers. No problem is too small or too big at this stage.
The team leaders can and should share some interesting problems to prime the discussion.
After several problems have been noted, go over the list together and make sure you all understand the problems.
You can also try to narrow down the list, as some problems may coalesce – they could be combined into a bigger scope.
Once the list is full, let the team vote for the problems they also agree are worth solving.
After voting has finished, you should select the items that make sense for further processing together in the next session.
Session 1b: Brainstorm on the outputs and outcomes that you want
If the previous session took less than an hour, you could squeeze this part into the same meeting. Be sure to take a small break though!
After you’ve listed all problems, figure out what outputs and outcomes you want to accomplish as a team.
Outputs are things you are working on and will produce or build. They’re generally easier to come up with for everyone in the team.
Outcomes are the effect that your outputs will have. These are somewhat harder to work out, as they usually have further dependencies on customers or other stakeholders. It’s the way your outputs will be perceived.
Give your team 10 minutes to come up with outputs or outcomes. Be sure to prime the list with some of your own ideas, again.
Offline: Cluster and refine the outcomes and outputs
After the previous sessions, it’s your time to shine as a product manager.
I can’t really tell you how to do this part, as this is pretty core to your job, but:
- Try to cluster the outputs and outcomes together logically. Place several items under one theme or problem statement.
- How do the outputs and outcomes relate to the problems you want to solve?
- Do some outputs lead to obvious outcomes you’ve missed? Add them!
- Are there outcomes that can’t happen because they have no outputs to rely on? Come up with something, or scrap them.
Session 2a: Lay out the priorities
Again, start with a warmup!
Next, remind the team about the grand lists of problems from the last sessions. Then, take turns and transfer the problems, outputs, and outcomes to the board. However, start with the problems.
This is a great time to tell your team about the priorities for your team for the upcoming period, and how they relate to the work you hope to do.
Session 2b: Align the problems, outcomes, and priorities
On the same board, now the relation between problems, outputs, and outcomes should be clearer.
Together with your team, create logical connections between items. Form a network of problems, solutions, outcomes.
Depending on where your team is in the company, these outcomes a may be very quite low-level. They can and should relate to company-wide OKRs, but don’t have to be a direct one-to-one connection.
This may be the last time to archive or de-prioritise problems you don’t think you can solve, or won’t have a clear outcome. Shove them to the side or colour them in a different colour!
Some outcomes may have multiple outputs feeding into them, some items may not even have outcomes. This doesn’t mean it isn’t important or worth doing – this is all down to your own priorities for the upcoming period!
Offline: Narrow down the list of problems and refine the outcomes
After the previous session, you should now be ready to start narrowing down the problems and refining the outcomes even further.
Don’t forget to send your team an update when you’re done!
Offline: Word your first OKR
With the problems, outputs, and outcomes narrowed down to a smaller list, start wording your OKRs, starting with the objectives.
Objectives should address:
- Who is our customer?
- What value does the team create?
- Is there a clear goal or milestone?
- Is it precise enough?
- Is it ambitious enough, but also realistic and achievable?
- Can we realistically accomplish this in one cycle, or should it be split up?
- Can it be understood by anyone in the company without explanation?
For each objective, come up with as many key results as you can. You’ll narrow them down and select them later.
Key Results should address:
- Is it measurable?
- Can we establish a baseline for the metric?
- Is it a task (complete / incomplete)?
- Can we show progress on this?
- Is it a leading indicator or a lagging indicator?
- If we are successful with the objective, what external signs would the user or stakeholder see?
- Does achieving this key result result in us reaching the objective?
- Can it insure the outcome we want?
Focusing on outcomes can really help in the next step, so be sure to word these correctly. If, for example, you want to ensure your users are engaged, an outcome oriented metric may look like:
- ✅ Good: “Increase answer rate on survey by 10%” (engaged user finishes filling in the survey)
- 🙅🏻♂️ Not so good: “Increase e-mail open rate by 10%” (this is a vanity outcome)
That’s it for part 1.
In Part 2, we’ll discuss how to measure success for the candidate OKRs, narrowing down the success metrics, establishing baselines, and sharing the OKRs with the world!
Leave a Reply