Combining OKR and Product Execution
Working in product development, it’s easy these days to get lost in frameworks. Whether it’s about building products or entire organizations.
And while I definitely have become more cautious about introducing new frameworks to my work the work of teams I’m leading, some combinations stuck with me.
For example the Auftragsklärung format (or: mission briefing after its inventor Stephen Bungay). But when I took over iridion at the end of last year, I was looking for something more detached from the product development and instead focussed on company alignment.
After reading the excellent book ‘Radical Focus’ by Christina Wodtke, I decided to implement Objectives and Key Results (OKR).
I have heard opinions that OKR and formats like other alignment tools (whether its Auftragsklärung or Intermission) would contradict each other. But at this point, I have also received requests from fellow product people wondering how multiple formats across various strategic levels could play together.
So, here’s how we organize our work at iridion (below the levels of our overall mission, vision and strategy):
We start with the OKRs, settling on a maximum of 3 company level Objectives (equalling ‘themes’). They are documented in a Google Sheet, and the progress is re-visited every week.
The various paths to achieve the desired results get discussed among the responsible persons of a domain (e.g., product, product marketing, sales, etc.).
The potential solutions are outlined as epics and follow a lightweight mission briefing structure for developing a shared understanding. We look at the context, the intent, the key implied tasks, potential boundaries and measures of success.
Epics can transition through five states, which are reflected in our Epic Priority Board:
- Backlog — Subject for further discussions
- Committed for Quarter — Matching our OKR focus theme
- In progress — Discovery & Delivery
- Done — Core scope has been shipped
- Outcome achieved/failed — Measuring if we actually achieved our goals and not just pushed something out the door.
While there indeed is an overlap between these two formats, we found that the space of elaborating on, e.g., market dynamics and user feedback, as well as defining specific boundaries helped to prioritize and plan the work.
Beyond that, we follow a two-week SCRUM cycle and as many direct user interactions as possible to validate new assumptions or check-in on feature usability.
While we certainly didn’t re-invent the wheel and are by no means at the end of our process improvement, this currently works quite well for us. Let’s see where we end up in 3 to 6 months.
