Running OKR workshops for dummies (part 1)

Running OKR workshops for dummies (part 1)

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:

  1. 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
  2. There are many sessions. Can’t get it done in one day – our brain doesn’t work that way
  3. Oh god, OKRs are boring though
  4. I need everyone aligned on the same problems
  5. I really want all of my team involved
  6. I need them to actively participate, not just listen in
  7. OKRs are so boring
  8. I have to be very careful not to control the conversation with my own opinion
  9. I have to get my stakeholders to also see the same stuff that the team came up with, and get in the right mindset
  10. OKRs are really boring and reading them makes my brain turn off
  11. I hate fussing over wording of metrics, but it really is important to get it right
  12. 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:

My process for running OKR workshops

Yeah, OKRs are your job as a product manager, not necessarily your engineers’. Be prepared to drive most of the sessions.

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.

An example warmup Miro board, where you list your favourite 80s movie and one guilty pleasure

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.

A set of problems to solve. We like using Notion for this stage, but any collaborative editing tool can work here, including Miro, Google Docs, and Figma.

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:

  1. Try to cluster the outputs and outcomes together logically. Place several items under one theme or problem statement.
  2. How do the outputs and outcomes relate to the problems you want to solve?
  3. Do some outputs lead to obvious outcomes you’ve missed? Add them!
  4. Are there outcomes that can’t happen because they have no outputs to rely on? Come up with something, or scrap them.

Make sure everyone is on the same page by writing an update on the recent session. Always include the up-to-date list of problems, outputs, and outcomes.

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.

Ask your team to place the problems on the board

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.

Create logical connections between inputs, outputs, and outcomes.
Tip: Create order on the board by colour-coding arrows and blocks, and rearranging the blocks as connections are formed.

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.

Think of OKRs as a network of problems and outcomes. They are and should be kinda intertwined.

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!


Posted

in

by

Comments

2 responses to “Running OKR workshops for dummies (part 1)”

  1. Mark Avatar
    Mark

    Should each outcome that was established in this step “Offline: Narrow down the list of problems and refine the outcomes” create one OKR for each outcome? So if I have 4 outcomes, should i have 4 objectives?

    1. Arnon Shimoni Avatar
      Arnon Shimoni

      If you can lump some outcomes into the same objective, and create a way to measure it, so you don’t need 4 objectives for 4 outcomes

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.