#45 - Keeping OKRs Relevant with Virtual DOM
Applying Virtual DOM Concepts to Keep OKRs Relevant and Efficient
OKRs Are Dynamic
OKRs are a common framework used to manage and organize a company's tasks and projects to meet its specific goals and objectives. When defining OKRs, you can think of it as a top-to-bottom process where the company decides its objectives and key results. Then, each department feels about how they can contribute to them, and eventually, each team needs to decide on the top priority and most impactful tasks to meet those objectives.
However, in reality, OKRs are a bit more dynamic. Let's take an example where the original goal was to improve the user's time-to-value —let's say, improve onboarding to first action time by 30%. In reality, once the teams and departments start working towards this goal, they realize that they have achieved it in a way, but then retention goes down. This means they improved the onboarding dramatically, but retention took a hit. Previously, it took longer to onboard users, but those already onboarded were able to find meaningful experiences and remained engaged with the product. With the new enhancements, it's not like that anymore.
They went back to management to discuss and decide to change the KR. Now, instead of looking at onboarding time, they look at two-week retention. The interesting question is how this KR change should impact the company.
Option #1: Wait for the next planning cycle and hope the people involved in these discussions will do what they can with the new KR.
Option #2: Regroup and plan everything again, validating the plans and ensuring the current tasks and internal objectives meet the new KRs.
There might be a third option: take a step back and explore the world of front-end applications.
Lessons from the Virtual DOM
Imagine a webpage where you have certain elements: you have the header and the footer, and then maybe you have a catalog area, a "Purchase Now" button, and so on. The elements are structured in some hierarchy, as shown below.
Web browsers treat the webpage as a tree structure (Document Object Model, DOM). Let’s assume the active sale has a timer of two minutes, and once the sale ends, the webpage will:
Remove the active sale.
Show the next sale.
Refresh the product carousel.
The webpage has several alternatives:
Option #1: Wait for the next page to refresh to load updated data.
Option #2: Refresh the page and load the entire page from scratch.
See where I’m going with this analogy? It's a similar problem to the one we introduced earlier with our OKRs example.
Luckily, we have a third option. Let’s discuss how it decides on changes to apply to the current page.
Instead of directly manipulating the DOM (e.g., refresh the page and components), the Virtual DOM compares the current state against the desired state. Once done, it changes only the elements needed instead of the entire page. Let’s see it in action:
In the example above, the virtual DOM updates only the necessary components instead of triggering a full page refresh. This improves performance and enhances the user experience.
The page’s tree structure plays a crucial role here. When the sale ends, multiple elements need updating, and we can identify them by examining the components (nodes) under the Sale Banner, such as the title, label, and price.
Keeping OKRs Up to Date
Let’s return to our OKRs example. After the company published its OKRs, each department created its plan. Now, let’s think of the DOM. The DOM represents the OKRs, structured so that each task ties directly to its relevant key result and each key result to its objective. This creates a tree-like structure, starting from the company’s top objective down to the last task connected to it.
When changing the onboarding KR to a retention KR, we can consider this process the Virtual DOM.
Looking at the tree structure, it’s clear that we need to revisit tasks 1 & 2. However, this doesn’t necessarily mean we will change them. For example, “Implement in-app guides” may remain relevant to the new retention KR.
We don’t need to involve the entire organization. By identifying the potentially affected areas, we can focus on discussing changes with the relevant teams. Once the updates are finalized, we publish and share the new version with everyone—just like updating a webpage after a sale ends.
Here are some tips that you can take right now to implement this:
Ensure every relation is in place, meaning each department's KR relates to the company's original KR. It's much easier to build it in a more structured way with tools like Notion or spreadsheets.
Link the day-to-day tasks—whether our personal tasks, marketing projects, or R&D features—to tie back up. It's hard; sometimes, it might be related to more than one KR, and still, we need to have a structured way to revisit it in the future.
Once changes occur, see them in a structured way—because you have already identified all the affected tasks and maybe KRs—and bring all the relevant people to the table to build an updated plan version.
Once you have an update, update the OKRs, change the tasks, revisit efficiently, and share it with the company.
Summary
Overall, we drew inspiration from how web pages manage state changes and applied that to the OKRs process. While goals and objectives are typically set once a quarter or year, finding a way to revisit them weekly and efficiently implement changes across the company as needed can be a key to success.