How Product Teams can
move on from OKR Theater

A close relative of John Cutler’s concept of Success Theater, as in blindingly celebrating reaching milestones without taking into account the bigger picture, OKR Theater can obfuscate the actual impact of your work.

Here’s how it plays out: By focusing on vanity metrics instead of measuring the solving of proven user problems, you jeopardize creating success for the business and your users. Let’s take a look at how to recognize OKR Theater — and how to ensure your team is focusing on the right things.

How to Recognize OKR Theater

The first step in circumventing OKR Theater is knowing how to spot it within your organization. There’s a fine line between using OKRs to change the way you work and keep efforts aligned and on track and using them to win kudos in your quarterly product all-hands meeting.

The number of OKR sets that makes sense depends on the skills and resources of a product team, their way of working, and the lifecycle stage of their product or feature.

Furthermore, there has to be a shared understanding of what you intend to cover through OKRs. Only strategic priorities? Only daily business? Both? This will lead to a more clear understanding of what share of a team’s capacity can be structured through OKRs and, in turn, what number of OKRs matches that ambition.

Your teams are not set up in a way that creates value cross-functionally and need to operate in silos with shared OKRs.

This results from a team lacking the capabilities to change more than one aspect of the product. Your shared UX resource is busy elsewhere? Tough luck. The infrastructure team isn’t available this cycle? The growth team can’t prioritize your A/B test until Q3. The case for embedding domains of expertise within a Product Team becomes stronger the more your organization grows.

When your ambition is to use OKRs to shift the way product teams work from Outputs to Outcomes, you might want to rethink team responsibilities as well. For example, consider structuring teams along the lines of broader user problem statements, ensuring all required skills and roles are part of a team.

You’re targeting Impacts instead of Outcomes.

An impact metric helps you to describe how the success of a specific strategic priority looks from a company or department perspective. An impact can be derived from Company or Department OKRs, and specific Product Strategy Choices, and should be manifested through a collaborative alignment artifact like the Mission Briefing. 

Though impact metrics are often clear-cut and easy to spot on large dashboards, they typically feature one key downside: They are lagging indicators — more on these later — whose change depends on many efforts coming together. That’s why product teams need something more tangible to measure the progress of their day-to-day work. 

A possible solution? Use Impact Mapping to connect User Outcomes that are rooted in proven problems with overarching business priorities and feature-oriented experimentation and delivery. 

Using Impact Mapping, you can utilize Outcomes as a tangible proxy for your work to measure real progress without losing sight of the company-level priorities. This is also why Product Discovery insights are such a key input for the OKR definition of product teams.

How to Overcome OKR Theater

Now that we’ve established how to identify where OKR Theater might be occurring within your organization, let’s move on to what you can do about it.

Connect your way of using OKRs to a clear why and adjust accordingly.

One root cause for OKR Theater is the unconscious adoption of “best practices.” Though you might feel inspired to adopt the goal-setting framework coined at Google, that’s typically not a sustainable reason why. And certainly, it isn’t one that employees can get behind and that you can measure your success in adopting them against.

Instead, use your Product Vision, Product Strategy patterns, and existing insights from team retrospectives for setting your unique reason why to use OKRs. And define what would change as a result of you using it — aka, how success would look.

Use your Product Vision, Product Strategy, and existing insights from team retrospectives for setting your unique reason why to use OKRs.

This way, you’ll establish a somewhat objective starting point for measuring the impact of how you use OKRs. You can design the way you use OKRs accordingly and check back in to see how product teams are doing.

Approach each of your OKR cycles with the courage to adjust your approach, since there’s simply no fixed “right” way of using OKRs.

Stop translating all your responsibilities into OKRs.

Trying to define OKRs for 100 percent of a product team’s tasks tries to cover inevitable uncertainty with more rigorous planning — which rarely works. Instead, this practice translates your feature-focused product backlog into a “busy looking” yet ineffective spreadsheet or OKR tool.

Instead, product organizations need to support individual teams in developing an explicit understanding of what OKRs might be most useful for in their context. That can mean differentiating strategic initiatives from ad hoc maintenance and support tasks or using OKRs to bring structure to the day-to-day responsibilities. Developing a clear understanding of the aspired capacity “coverage” also helps teams to adjust their sprint backlogs in a way that balances availability for ad hoc tasks with enough focus on strategic progress.

Product teams should focus on what matters most and pick measurements of success for the aspects of their work that they want to proactively drive. This is essentially the main difference between Key Results (proactively driven, time-based strategic priorities) and KPIs (reactive measurements of evergreen metrics).

Measure a team’s progress using leading, not lagging, indicators.

I often see companies focusing on aesthetically pleasing and yet completely ineffective lagging indicators for their Key Results (aka Impacts), when they’d be much better off focusing on the opposite: leading indicators.

Using leading indicators to set product team-level OKRs allows you to essentially predict the future. They’re challenging to create, but worth the extra effort and time: Ultimately, you’ll end up with metrics that allow a team to measure their progress and adjust their Discovery and Delivery priorities accordingly.

Figuring out whether you’re using lagging or leading indicators to measure the progress of your OKRs — and making the necessary changes — is step one on the path to overcoming OKR Theater. It’s also vital to ensure you’re choosing meaningful Key Results that represent real progress.

For example: Focus on designing processes to capture the critical attributes of a user or buyer that demonstrate product usage (or customer success). Make sure to document them after your most important lagging event has happened — this event could be a purchase or an upgrade, for example. Next, compare the last X purchases and find the common denominator among the product usage metrics. Choosing the right metrics to focus on (and sidelining the rest) will help you and your team steer clear of the OKR Theater trap.

Leading indicators should be derived from lagging indicators by reverse-engineering the proven customer journey. You don’t want to choose a random metric just because it’s technically a leading indicator. But if it’s proven that this metric contributes to more lagging indicators, I think it’s a fair trade-off that enables more product teams to make evidence-informed Product Discovery decisions.

Leading indicators should be derived from lagging indicators by reverse-engineering the proven customer journey. You don’t want to choose a random metric just because it’s technically a leading indicator.

Takeaway: Don’t Let OKR Theater Get in Your Way

Adopting OKRs in a product organization is an ongoing process that requires patience and constant tweaking. But you don’t have to get it right the first time. It’s much better to start imperfectly than not to start at all. Having awareness of how OKR Theater manifests will help your team avoid this common pitfall — and keep your focus where it needs to be.

See if you can identify where you’ve been focusing on the wrong metrics, or honing in on lagging rather than leading indicators. With a little tweaking, you can create your own journey to using OKRs as an enabler for product teams to shift toward Outcomes.