Capturing a holistic view of your Product’s success through Key Results 🔗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.These inputs can include (but are not limited to) elements like:Quarterly or yearly company/department OKR setsCompany Purpose and VisionProduct Vision and Product StrategyPrevious OKR sets and existing Theme-based Product Roadmap elementsProduct Discovery Insights in the form of proven user problems or validated solutions Strategic vs. Product Team-owned Inputs for the OKR Definition The quality or lack of these inputs can often reveal significant flaws in a team or company. How can you expect articulated Key Results containing what should be achieved, instead of what should be done, if a team doesn’t have the possibility or skills to interact with users through Product Discovery directly? How should a team name their contribution to business goals if there’s no clarity about where the company is headed? And how can you expect defined OKRs to match cross-team priorities if there’s no alignment and communication about agreed high-level initiatives?Though each of these inputs brings benefits to the table, I have seen the absence of a Product Strategy as the most harmful. I would even say that if you don’t have a clear and tangible Product Strategy, it does not make sense to use OKRs.If you don’t have a clear and tangible Product Strategy, it does not make sense to use OKRs.The inputs listed above are not an exhaustive list every team has to complete before they are “allowed” to draft their OKRs. Furthermore, these should serve as orientation for the required clarity that informs the quality of the defined OKR sets. If one or more of these are missing, simply prioritize completing the puzzle until the next cycle to improve your way of working.As mentioned earlier, defining the success of a product through Key Results shouldn’t just be a list of all the same performance-driven KPIs you measure already. Instead, use the idea of Key Results to define how success would look from as many angles as possible.There’s nothing wrong with starting your OKR definition process by focusing on already established performance indicators like revenue or growth. But don’t stop there; challenge yourself to think about other measurable expressions of your product’s success.Exemplary metrics suited to represent holistic success could be:A product’s or service’s conversion rateCustomer satisfaction in the form of NPS or a similar methodologyProduct reviews from platforms like G2 or the App StoreThe number of new users completing an onboarding sequenceChanges in behavior from the sales team like the number of necessary follow-up calls or steps to perform a product demonstrationResults generated through User Testing Sessions or other ExperimentsChurn or retention metrics indicating customer preferences through behaviorHow to set up the definition of meaningful OKRs with your Product Team 🔗 Defining OKRs in Product Management should be a collaborative practice. One that includes all (ideally) cross-functional team members to make sure the OKR definition is based on the capabilities and commitments of the people “doing the work.”A practical setup comes in the form of a workshop. Ideally, a dedicated facilitator guides the team through the process, so domain experts like the product manager(s), designers, or engineers can focus on the content.Before jumping straight into writing and sharing ideas for individual Objectives or Key Results, everyone should be on the same page regarding the context of the next cycle. That means the facilitator sets the stage by revisiting all existing and relevant inputs. Ideally, the owners of any of these inputs are present during this phase as well. That way, the intent of, let’s say, company OKRs isn’t lost through proxies and misinterpretation.Before jumping straight into writing and sharing ideas for individual Objectives or Key Results, everyone should be on the same page regarding the context of the next cycle.Don’t fool yourself into thinking that there’s just one “right way” to arrive at OKR sets that work for your team. Though there are benefits to starting with the qualitative statement in the form of the Objective, you can also “work your way up” from Key Results or tasks. Versatile OKR Definition Directions and Approaches The main thing to pay attention to is whether you’re coming up with ideas that match your OKR WHY and the current level of discussion. Deep Dive: Drafting Outcome OKRsMy “Outcome OKRs for Product Teams” course provides all the practical strategies and templates you need for an effective OKR drafting with your Product Team. Learn More The Danger of “trickling down” Key Results throughout CascadesThough there’s nothing inherently wrong with different OKR cascades within a company, these pieces of advice make things a lot easier:Less is more: Reduce the number of cascades as much as possible. Though company-level OKR sets can provide crucial guidance, department OKRs rarely do and instead only limit the Product Team to focus on Outputs, not Outcomes.Weak links, not strong ties: While company or department-level OKRs are a relevant input for the OKR definition, there’s a common myth that any Key Results of a higher-level OKR set need to be synonymous with the Objectives of the team’s OKR sets. Strict OKR Cascades lead to Output focus; Weak Links encourage Outcomes Avoid narrowing the corridor for the team-level OKR definitions, which would contradict the idea of bottom-up Outcome OKRs defined by the Product Team.Differentiating Outcome and Output OKR sets 🔗There’s a common misbelief that OKRs come with “built-in” Outcomes. Setting goals this way will automatically limit your discussion to fewer solutions, i.e., Outputs.Before we go further, let’s go over what I mean when I talk about Outcomes and Outputs.To me, an Outcome describes a measurable change in behavior that contributes to an Impact. (This definition is inspired by Josh Seiden’s excellent book Outcomes Over Outputs.)An Outcome is a change in human behavior that creates an Impact. An Output, on the other hand, is an artifact that has been delivered through activities. It’s one way of creating this behavior change, whether for customers, users, or internal stakeholders.OKRs can work with either Outcomes or Outputs. As with every framework, the benefits of OKRs highly depend on how you use them. It’s certainly possible to set some or all of your Key Results as Outputs. In some instances, this might even be a better way to get started. Some teams get stuck in the Key Results definition process because they try to turn everything into an Outcome—just for the sake of it.For Product Teams, being aware of the difference between Output and Outcome OKRs is an essential first step to drastically improving the definition of their OKRs. Realizing whether they are already talking about solutions or are still focused on articulating the changes in behavior, Product Teams aim to create a big difference for their continued use of OKRs. Tip for Practice: HMW StatementsTry to rephrase your Key Results as a “How might we...?” statement. This way, you can sanity-check your focus on Outcomes and uncover premature discussions about feature ideas. Tweet this Here’s a practical example of how Outcome OKR and Output OKR sets might differ: