I love OKRs

OKRs (Objectives and Key Results) are simple, elegant, and effective.

And if done right, they can empower teams and unlock tremendous value.

I use them all the time at Google.

But they are not perfect.

For example, when product teams are given lofty goals like “improve user adoption by 15%”.

Here is usually what ends up happening.

• Leaders assume that by keeping OKRs at a high level, their teams will figure it out.

• Teams, on the other hand, struggle. Without the proper context and guidance, they are left guessing on the best way to execute.

• Some of these directionless teams take a short-term focus. Trying to create band-aid solutions that meet the metric as fast as possible.

• Others try to do the right thing and invest in product discovery. But then face pressure, run out of time, and scramble to deliver something.

• Worse yet, when multiple teams try to solve for the same OKR. You end up with siloed solutions, duplication, internal competition, and missed opportunities for collaboration.

The net result. You get half-baked solutions, broken user experiences, non-strategic bets, technical debt, and/or not getting anything done at all.

The problem with OKRs is that, by themselves, it is not enough.

OKRs are great at telling you what you need to achieve – the objective and key results.

But they are silent on the why, the who, and the what.

For example, in our OKR above. There was no mention of,

1. Why is adoption important? Is it because of new competition? Are new features being released? Trying to capture market share? Without proper context, teams are left in the dark.
2. Who is on point? Is it product, marketing, sales, or all of the above? Without a single owner, teams end up tripping over each other.
3. How to best achieve the goal. Do we already have a validated idea and now we need to build it? Or do we need to discover and test it? Do we take a short-term approach or a long-term approach? Without high-level guidance, teams are left to guess.

Augment your OKRs with why, who, and how.

If you want your team to achieve the OKR and be successful, you need to provide your team, with

1. Right context (why are we doing this?)
2. Proper team structure (who is going to do it)
3. Key milestones (how we are going to do it)

The Right Context (Why)

The context is just one or two lines that provide the team with the bigger picture.

When done right, it aligns the OKR back to the product and organization strategy. Describes the outcome. And why it is important.

It also serves as a guide, when they are generating ideas, making decisions, aligning with the larger organization strategy, and communicating.

Here are two examples:

“Today, our customers use our call center when they have issues with their mobile plan or billing. If we can divert more of the call volume to our new chat services, not only will it provide our members with a better experience but also save us $$ in call center costs. As a first step, we would like to increase awareness and usage of our new chat functionality.”

“It takes over 3 days for our customers to move money in and out of their account. And over 60% require them to call their financial advisor. If we can help our customers move money in minutes, without burdening their advisor, it will deliver a better experience for both parties and save time for both parties. As a first step, we would like to improve withdrawal time to just 24 hours and reduce call volume by 20%.”

The Right Team Structure (Who)

I am personally partial to the core + support team model.

Here is an example of the core + support team structure we used for discovery at a regional bank.

Notice how each of the stakeholders is included early into product development, including at product discovery. This ensures that everyone has a seat at the table, is hearing directly from the customer, is aligned, and is marching in the same direction.

Guidance On Execution (How)

The goal here is not to micro-manage.

But to provide teams with high-level guidelines on the how. Otherwise, the teams will (like the example above) either underperform or overshoot.

I usually like to break the work down into the following 5 milestones.

1. Define KPIs (Key Performance Indicators) makes sure that we can define and measure incremental success
2. Innovate helps the team understand the problems from the user perspective and ideate on multiple potential solutions
3. Experiment forces the team to try, improve, and perfect potential solutions before we spend time building them
4. Launch forces teams to define and launch an MVP (Minimum Viable Product) as quickly as possible (within 6 – 9 months)
5. Measure makes sure that we had an impact, and helps teams determine what to do next

A high-level approach like this sets expectations, provides teams with better directions, and the freedom to achieve the milestones as they see fit.

It also makes governing and oversight much more manageable. Since you can track and adjust as needed. And at the end of the month or a quarter, the team has something tangible to show.

Putting it all together.

The next time you develop an OKR, leverage the above framework.

Don’t just leave your team with the OKR and have them figure out the rest. Take the extra step and help them with the why, the who, and the how.

It will help them and you in the long run.

Happy building!!