Product leaders are charged with leading cross-functional teams through high value, iterative product releases. The product leader needs to understand market dynamics, their customers’ problems and needs, and storytell internally to generate excitement and support. To do this effectively, the product leader must partner with cross-functional leaders (design, engineering, product marketing, sales) to determine what success actually looks like.
The Objectives and Key Result (OKR) framework is a popular way to bring small teams together and define priority outcomes over a fixed period. As with any framework, there is room to customize what works best within an organization’s culture. I’ve worked with OKRs in several different organizations; there are universal truths that apply to any team, including:
- OKRs translate a mission and strategy into actions for a specific period of time;
- OKRs center on a few critical objectives, while allowing for roadmaps to remain flexible;
- OKRs create discipline and accountability across the cross-functional product team, challenging teams to ground objectives in measurable outcomes;
- The product lead drives the OKR process, but requires input from cross-functional partners;
- Objectives should be ambitious–accomplishing ~70% of the target is success;
- The product leader needs to make sure that dependent products share or are aligned to KRs;
- Use baselines and metrics that are available, avoiding aspirational metrics which aren’t trackable yet;
- KRs should have flexibility to change mid-year based on new insights, but objectives should be durable.
You may have noticed that OKR alignment or cascading is not on this list…that’s on purpose. The idea of creating OKRs at the CEO level is very powerful and critical to centering a company’s executional strategy. On paper, it’s logical to cascade this downwards across the full product organization: CPO aligns to CEO OKRs; a product group aligns to CPO OKRs; a product team aligns to product group OKRs – nice and tidy. John Doerr and Google pioneered the concept of cascading OKRs during Google’s early phase of growth and it was a huge success (Doerr’s book Measure What Matters is a must-read!). Although cascading OKRs can be successful, in my experience, the effort created more problems than benefits. My advice: focus on getting your product’s OKRs pointed accurately to your company goals and be done. The time it takes to do just that while ensuring OKRs are updated and communicated is a big enough lift in itself. Here’s what I found to be the most challenging things about cascading OKRs:
1. The process takes too long.
Ideally you want to brainstorm around next year’s strategy, north star and OKRs between Thanksgiving and mid-December before vacations, so that coming into the office on January 2nd, the team is fully aligned and off to work. If OKRs cascade, you need to wait for each layer above to be set before your team can set its own. Good luck getting going before Valentine’s Day.
2. Update meetings are cumbersome.
With cascading OKRs, you’ve now introduced another set of alignment meetings where you need to make sure that things around you stay connected. As a product leader, you need to report progress to another entity which will be an unnecessary distraction.
3. Needs heavy overhead and software.
Cascading OKRs requires a central team software solution. A shared Excel doc will be overwritten and broken in minutes. A part-time owner will leave a lot of fields blank due to other priorities. Puting in the right oversight for this effort can cost the company several hundred thousand dollars.
4. Not all teams will define OKRs the same way.
Within a product organization, your product operations team can lay out best practices and standards for writing good OKRs. What happens when other teams, with different styles, take a different approach? One team’s OKRs may only focus on outputs (send out 30 emails) vs outcomes (improve conversion rate by 0.5%). This compounds challenges number 2 and 3 above.
5. No one wants the job of running this process.
Yes, I said it. This is painful for someone to run. They need to constantly badger people for updates, push back on bad KRs, and then deliver a rolled-up version of overall progress to the executive team which is always incomplete.
A good product leader will always look for ways to minimize their team’s overhead and create as much space as possible for testing, exploring and delivery. OKRs are an excellent framework to allow a team to go fast and keep centered. As with any process or framework, there can be a tendency to over-engineer – leave OKRs with the team, make sure they have the right buy-in, and it will be the measuring stick for how well the product and team can perform.