Yeh OKR OKR kya hai (What’s this OKR)?

There has been a lot of buzz around OKR in the past couple of years. If you haven't heard the term, please crawl out from under your rock. But, is it another piece of flotsam in sea of startup jargon that product managers and coaches throw around and brag about, or are we really onto something here.

Well, it turns out (you have to take my word for it), it is a very useful Product methodology and should be paid close attention to. A lot of successful Product companies are following the methodology and there are several benefits to it. At the same time, it is certainly not the cure for all, that some Product Practitioners hype it up to be.

For the uninitiated, OKR’s are a set of guidelines on how to manage the product journey more collaboratively and focused on the business problem. It lays out some practical steps to follow in order to prioritize the company's problems and rallying around the entire company towards solving those problems. The O in OKR stands for Objective. This is the most critical business problem in qualitative terms, that the business needs to solve in order to move forward in the next quarter or so. The KR stands for Key Results, and lays out the metrices that need to be tracked and attained in order to fulfil the chosen objective. Simple enough!

Well, I have implemented OKR’s in some of my product lines, and, I have to admit, the results have been mixed, some have shown exceptionally good outcomes, whereas for some cases, there has been no visible change, or even, marked decline. The main reason for that is, setting the objectives and related key results is not an easy task. Getting a set of senior people to agree on one or more objectives at the organization level, and then imposing them on the rest of the organization looks good on paper, however, the age old problem of motivating the rest of the organization still remain. Many teams find themselves lost, as the objectives seem too distant and abstract for them. This is especially true for large, complex organizations, with multiple disciplines and product lines. Additionally, again for larger organizations, there will be many objectives that are equally important to achieve. Choosing one or two of these is often sub-optimal, as the team has to juggle between many of these to stay abreast of customer demands, or they lose customers otherwise.

Finally, the prevalent design on OKR’s suggest that the objectives and key results should be set up on a quarterly basis, and the team needs to review their progress or attainment of these key results at the end of the quarter. However, for many cases, I have seen that a quarter is too short a timeframe to see any perceivable effect on the objectives that are set out. For example, lets assume that the objective is to improve customer satisfaction, and a key result for this is stated to be improve customer reorders by 60%. Now based on these objectives, the product team may have set their own Objectives as performance improvement, and set this as 40% faster load time of pages. The team may have brainstormed and delivered against this key result in the stipulated quarter. However, it is impossible to determine at that point of time, whether the customer reorders target of 60% would be achievable or not based on this key result attainment, as that result would still be a quarter away at the least. So essentially, at the time of attaining their own key result, they team does not have solid proof that they are going to move the needle on the organizational objective or not and by how much.

In spite of the shortcomings mentioned above, I still think OKR’s are a fantastic motivational tool and methodology. It brings teams together and starts meaningful conversations. It also helps in bringing alignment on things like backlog prioritization. It is especially useful for startups and mid-sized product companies, those that have not yet breached the $25 million revenue barrier. Having quarterly targets makes the team focus on a specific objective for an optimum period of time, while, at the same time, they do not losing the ability to pivot or change direction, in an agile manner. For larger organizations, there are some specific tweaks to the process that need to be incorporated. But that is another topic for another day.