The Importance of OKR Definition Inputs for Product Teams

Answering the question “How does success for our product look at the end of this cycle?” can be difficult if a product team lacks tangible guidance. After all, granting the autonomy to define OKRs from the bottom up doesn’t automatically clarify what should come next.

That’s why it’s the responsibility of the product team to either demand access to or create the inputs required for the definition of their OKR Sets.

I like to differentiate these various inputs along the lines of their flight level (strategic company direction versus tactical priorities) and the team ownership (receiving versus creating).

This helps product teams focus their efforts on the inputs they can shape instead of getting lost in influencing upper-level artifacts without much success.

Inputs can include (but are not limited to) the following elements:

• Company OKR Sets
• Product Vision
• Product Strategy
• Product Discovery Insights
• Previous Team OKR Sets
• Existing Roadmap Items

Company OKR Sets

The most important attribute company-level OKR Sets need to have is that they focus on the right metrics. And though that’s important for the thematic aspect, I would like to argue that it’s even more important that company-level OKR Sets focus on Impact metrics.

Otherwise, the “room to breathe” for product teams gets narrowed to only being able to list Output OKRs. Company-level impacts need to balance guidance (as in making a strategic priority measurable) as well as autonomy (requiring the product team to determine the contributing Outcome metrics and Outputs to build).

A product team’s ability to focus on Outcomes depends on whether it gets enough room to create by the Company OKRs.

Another attribute of treating the Company Key Results as an input for the product team is the strict cascade of them. Though it might end the discussion more quickly, it also narrows the corridor in which the product team will OR can act.

Strict OKR Cascades lead to Output focus; Weak Links encourage Outcomes

Product Vision

There’s an overwhelming number of “templates” and “best practices” that get widely distributed that mash up Product Vision and Strategy.

The Product Vision is about articulating how the future state for the market you have chosen should look—based on your values, responsibilities, and drivers. It can sometimes be difficult for the product team to articulate their Product Vision and not just stick to the company vision. 

You can compare those two levels from a product team at Airbnb that was responsible for the booking experience:

Product Strategy

On the other hand, your Product Strategy Choices are about outlining the most promising play to win in the market you have chosen to compete in. Again, it’s worth differentiating Company and Product Strategy here. Following the previous example from Airbnb, the (IMO imperfect) matching strategy statement was “Transition the Airbnb marketplace from ‘request to book’ to ‘instant book’ model.”

Such a simplified statement cannot be pulled from thin air but rests on a set of quantitative and qualitative data that informs this Strategy (whether in B2B or B2C). Again, filling in a gap text with “brainstorming” inputs won’t form a valid strategy. And this lack of quality will be evident when you try to use your Product Strategy as an input for your OKR definition.

Filling in a gap text with “brainstorming” inputs won’t form a valid strategy.

Richard Rumelt once famously wrote: “A goal is not a Strategy!” But to me, that doesn’t mean that goals can’t be PART of your Strategy—and they certainly should RESULT from your Strategy.

If you’re having difficulty articulating OKRs that go beyond “increase revenue,” it’s probably due to a lack of strategic context. But the product team shouldn’t blame it on their manager or the C-level if the Product Strategy isn’t clear. Instead, I encourage the product team to create clarity about their strategic direction themselves.

The gaps in your plan to win (aka Product Strategy) are almost like a secret sauce ingredient for your OKRs.

Product Discovery Insights

I’m still surprised by the number of product teams that get “tasked” with defining or even going beyond Outcome OKRs, but that were never enabled to interact with users or customers firsthand. This alone contradicts a company’s intent to enable product teams through OKRs. If product teams don’t have the skills and environment to understand the problems worth solving and solutions worth pursuing through Product Discovery, they lack the essential data points to articulate Outcome OKRs in the first place.

Without Product Discovery insights, product teams are, by definition, not enabled to define Outcome OKRs.

Product teams need to understand how the concept of understanding customer problems translates to the definition of Outcomes, which, in turn, is crucial for articulating a corresponding Key Result.

Simply asking users “what they want” will lead to only surface-level feature requests, which don’t help with describing how the behavior of user segments needs to change.

Actor-Job-Outcome-Key Result-Mapping to connect User Insights to KRs

This way of mapping research insights to Outcomes and then Key Results also ties in with Impact Mapping as a way to connect down-the-road feature ideas and experiments to overarching company goals. Being able to use actionable Discovery insights to define and shape OKRs is also one of the key traits that separate Outcome-oriented Product Teams from those that get lost in OKR Theater.

Previous Team OKR Sets

Whether some of the Key Results will spill over into the next quarter or you just revisit the learnings from your OKR Review and Retrospective, your previous team OKR Sets can be helpful inputs for drafting the Objectives and Key Results of your next cycle.

How the Delivery Progress of Backlog Items determines the success of set Product Management Key Results across timelines

After all, just because your OKR cycle ends, not all of your Key Results will automatically jump to 100 percent progress. The reasons for not fully achieving a Key Result can vary. Maybe there’s a gap in your team’s composition and skills that prevents you from executing the activities needed to drive an OKR Set.

Maybe there’s a gap in your team’s composition and skills that prevents you from executing the activities needed to drive an OKR Set.

Another reason might be that your chosen Key Results relied too much on lagging indicators. The art of balancing leading and lagging indicators to measure the progress of OKRs requires thoughtful discussions and experience by product teams. 

Whatever the reason, previous team OKR Sets can act as a helpful input for the following cycle.

Existing Roadmap Items

Product Roadmaps are not the enemy of using OKRs as a product team. It’s all about recognizing the priorities defined through a Product Roadmap and leveraging OKRs to help you execute these or to shift priorities.

Even if most of these Roadmap items are indeed fixed and not negotiable, OKRs can be beneficial.

One option could be to use OKRs for internal team improvements and to change your process deliberately. An often neglected benefit of using OKRs combined with a regular check-in cadence is their potential to promote learning. 

In addition, OKRs don’t need to cover ALL of your work. You can use them for deliberate tracking and adjusting your way of working. Once you agree to that as a product team, OKRs can serve as a lightweight structure to keep track of behavior changes YOU want to achieve—like your research cadence, team members’ happiness, the response time to incidents, or other similar indicators.

OKRs don’t need to cover ALL of your work. You can also use them for deliberate tracking and adjusting your way of working.

Takeaway: High-Quality Definition Inputs set the stage for High-Quality OKRs

Of course, Inputs don’t lead to useful OKRs by themselves. They do, however, set the stage for brainstorming, discussion, and commitment to OKRs that fit into the environment you’re operating in.

The opposite would be to try to articulate OKRs JUST based on a lofty vision statement or JUST on an arbitrary strategy statement like “doubling the revenue.” Though this might feel like it grants more autonomy to the product team at first, the resulting OKRs will lack the tangibility required to make OKRs a useful tool for the product team’s day-to-day decision-making.