OKR Workshop Method

Hi All, have recently found myself discussing OKRs with peers, colleagues and even friends.
It has become evident that the concept is becoming more topical.
Have taken some time to gather my thoughts I have pulled together a template for workshopping and defining product OKRs with Product Teams.

Would love your experiences and insights

2 Likes

This is a really good guide. No jokes, I am going to suggest using this on our next Product Workshop next quarter.

@Raggie, my questions about the article and OKR in general:

  1. How do you track the progress. The team who is responsible for their KR also responsible for tracking?
  2. How often do you track the progress? Monthly?
  3. What if we all agree that one feature is essential to the product, but because of the constraints we can’t measure it. Is there any better option than just put “deliver feature X”.

Hi AniaSamira,
Thanks for the feedback - I am glad this is a method that makes sense to you and something that you can trial out. I would genuinely love your feedback on how it goes.
Sure can help you out and give my 2 cents:

1. How do you track the progress. The team who is responsible for their KR also responsible for tracking?
This really depends on what you and your team decide on, as well as how often your stakeholders would like to know about the progress. You need to work with them to call reach a balance without creating too much overhead.
In my last OKR session we as a team came up with the following Cadence:

  • Fortnightly team catch up to report on current inflight features as well as performance of delivered features. We also talk about what is currently in flight. A fortnightly catch up gives us enough time to Pivot if we see things going astray
  • Weekly email to stakeholders with a link to the team dashboards and some key learnings and insights.
  • Fortnightly Showcase to discuss the progress against our key results with the wider group.
  • Majorly the Product manager is responsible, however i ask my team for help if they have access to deeper stats (databases, repositories etc) but it is my role to collate and present these in a relatable and understandable manner.

2. How often do you track the progress? Monthly?

  • We have some live dashboards set up that I monitor
  • When we are looking at features we pull up anything that may help us make a call
  • Other progress is done ad-hoc and for showcase - so we can show the status of feature build e.g this feature is x% complete and will bring foward these results.
  1. What if we all agree that one feature is essential to the product, but because of the constraints we can’t measure it. Is there any better option than just put “deliver feature X”.
  • This is a tricky one - i have been in this situation and put down “Build and Release x feature by end of x month” however this should be the last resort.
    I would look at metrics such as “Deploy x feature with less than x P1 bugs” or “Build and deploy x feature with x% downtime” - It would still be preference to relate the feature delivery to an impact that you are intending to make.

Hope that helps - once again my 2 cents, its always horses for courses in our space :slight_smile: please let me know if there is anything else i could help with and let me know RE any feedback

RT