成果导向目标的 OKR 产品管理指南

内容：

• 什么是 OKR？
• 谁创建了 OKR 框架，为什么？
• OKR 的局限性是什么？
• OKR 对领导者的好处
• OKR 对产品管理职能的价值
• 建立稳健的产品 OKR
• 审查产品 OKR 进度
• OKR 与产品策略之间的相互作用
• OKR 在产品发现中的作用
• OKR 和 Scrum 如何相互协同
• 使用 OKR 进行产品决策
• 要避免的 OKR 陷阱

成功的执行领导者的一个标志是能够推动朝着既定的业务愿景取得重大进展。 虽然领导者必须带来无数的技能和才能，但称为目标和关键结果 (OKR) 的特定心智模型可以帮助您以更少的时间和精力实现这一进步。

我们为寻求设定和实现雄心勃勃的业务目标的最高管理层和产品负责人编写了 OKR 指南。 通过为您自己和您管理的职能部门实施 OKR，您将能够确定对您的业务来说重要的事情，为您的团队应该实现的目标设定目标，跟踪目标的进展情况，并诊断问题的根本原因意想不到的结果。

什么是 OKR？

目标和关键结果框架（ OKR框架）是一个灵活的、面向行动的结构，用于确定业务优先级、设定可衡量的、以结果为导向的目标，并在组织的各个层面激发行动，为客户创造价值。

许多组织围绕 OKR 启动了自己的特定流程。 我们编写本指南是为了帮助您塑造和塑造最适合您的需求和环境的流程，而不是从特定公司“导入”可能对您的特定组织弊大于利的特定风格。

首先，每个 OKR 实施都包含两个组成部分：目标和关键结果。

• 目标是定性的愿望，代表了企业寻求前进的方向，而不是有形的最终状态
• 关键结果是代表团队在实现目标方面取得的进展的量化目标

每个团队在本季度都应该有一个单一的目标。 然后，团队应决定支持该目标的多个关键结果。

举个例子，想象一下一家销售炊具的公司。 他们其中一个团队的目标可能是“成为家庭厨师值得信赖的烹饪锅供应商”。

该团队可能会选择以下三个关键结果来支持这一目标：

• 将退款率从 0.5% 降低到 0.2%
• 将重复购买率从 5% 提高到 15%
• 将首选品牌知名度从 10% 提高到 25%

定性目标和定量关键结果的特定组合是强大的，因为它推动了团队每个成员的定向和协同行动。

想象一个只有目标但没有关键结果的团队。 该团队不会充分了解他们在实现这些目标方面取得的进展，也不知道要改变哪些行为或采取哪些行动才能取得有意义的进展。

此外，队友可能会单独选择以对他们有意义的方式追求目标，但最终无法很好地协调一致。

例如，一个人可能会针对销售炊具的企业帐户，而另一个人可能会针对 SMB。 或者，一个人可能会寻求提高价格以展示品牌实力和声望，而另一个人可能会寻求降低价格以提高可负担性和可及性。

使用这些例子，我们可以很容易地看到在团队层面共享关键结果如何帮助团队成员保持一致。

另一方面，想象一个只有关键结果但没有目标的不同团队。 该团队将缺乏做出正确权衡的业务背景，并且可能会以牺牲长期业务成功为代价，在短期内狭隘地优化他们的指标。

而且，他们可能会在尝试同时处理多个指标时遭受信息过载，而没有一个总体目标告诉他们在哪些情况下优先考虑哪些指标。

因此，通过将定性愿望和定量目标结合在一起，我们调整并激励团队采取行动，推动我们的业务向前发展。

在我们深入探讨实施 OKR 的最佳实践之前，让我们先讨论一下发明 OKR 的原因，以及该框架对知名公司的影响。

谁创建了 OKR 框架，为什么？

英特尔首席执行官安迪·格罗夫 (Andy Grove) 在 1970 年代建立了 OKR 框架，以授权所有职能部门的各级员工识别和获取商业价值。

他为公司创建新“操作手册”的动机是因为他在仙童半导体工作时亲眼目睹了自上而下的管理控制和一线权力下放的问题。

Grove 将 OKR 视为学习引擎，而不是绩效管理系统。 OKR 的目标不是奖励完成目标的人，也不是惩罚未达到目标的人。 相反，经理和直接下属都需要根据他们在 OKR 方面取得的进展来反思他们所学到的东西，无论他们是否超过、达到或未达到他们的目标。

Grove 在“目标管理”(MBO) 系统之上构建了 OKR 框架，Peter Drucker 在他 1954 年的著作 The Practice of Management 中分享了这一点，德鲁克在书中建议管理者为他们的直接下属设定明确的目标以实现。

但是，格罗夫试图避免这种僵化的结构带来的主要缺点，这种结构将过多的决策权集中在经理和主管手中。 格罗夫在 1983 年出版的《高产出管理》一书中提出了这样的批评：“如果主管机械地依赖 MBO 系统来评估下属的绩效，或者如果下属因为没有明确的目标而放弃利用新出现的机会，那么两者都正在以一种小气的方式行事。”

这就是为什么目标通常由领导者和经理设定，以及为什么关键结果通常由团队和个人设定。 通过这种方式，主管和下属通过在前线的成功合作，共同推动高水平的业务进步。

1999 年，John Doerr 将 OKR 框架带到了谷歌，进一步推广了 OKR 框架。 当时，谷歌员工不到 50 人，其创始人拉里佩奇和谢尔盖布林一年前还是博士生。

正如 Doerr 分享的那样，“Kleiner Perkins 刚刚投资了 Google，作为 OKR 的坚定拥护者，我主动提出向 Larry、Sergey 和领导团队介绍 OKR 系统。 拉里和谢尔盖立即看到了价值。 他们喜欢为公司制定一套季度优先事项。”

通过将精力集中在这些优先事项上，Google 迅速成为互联网用户的宠儿，这些用户以前依赖 Yahoo 或 Lycos 等门户网站来浏览网页。 Google 于 2004 年首次公开募股，距 OKR 在 Google 实施仅 5 年。

OKR 的局限性是什么？

我们现在看到 OKR 如何帮助英特尔在 Grove 的领导下从 19 亿美元增长到 260 亿美元的年收入，以及 OKR 如何帮助谷歌成为互联网上占主导地位的搜索引擎。

但是，OKR 不是灵丹妙药——我们需要确保我们不会不小心误用 OKR。 具体来说，OKR 不应取代业务愿景或业务战略。

愿景定义了多年来和几十年业务的总体方向。 OKR 按季度设置，因此植根于日常执行。 如果没有指导性愿景，领导者就无法制定能够取得有意义的长期进展的 OKR，因为“有意义的进步”的定义正是由愿景设定的。

而且，OKR 不能取代业务战略； 相反，OKR 有助于为战略注入活力。 真正的战略需要诊断和一组护栏来推动权衡，而 OKR 专注于执行以实现符合这些预定义护栏的结果。

我们不会深入探讨“如何设定引人注目的愿景”或“如何制定制胜战略”，因为这些主题超出了本指南的范围。 如果您想具体了解有关愿景或战略的更多信息，我们会在 Product Teacher 举办关于愿景和战略的企业研讨会。

到目前为止，我们已经了解了 OKR 的来源，并且我们对什么是 ORK 有了一个很好的工作定义。 但是，作为领导者，我们为什么要使用 OKR 而不是其他方法？

OKR 对领导者的好处

使用 OKR 框架可为领导者带来五个主要好处：

1. 衡量进展的能力

首先，OKR 鼓励我们将业务目标明确化为易于衡量的目标。

换句话说，OKRs 是一种强制功能，它让我们用语言表达我们对业务到底关心什么，我们为什么关心它，以及哪些结果很重要。 我们建立问责制和透明度，避免以后“择优”取得好结果。

假设贵组织的一个关键结果是“本季度新客户获取率提高 10%”。 如果一个团队最终“增加了现有客户的合同价值”，但没有“增加新客户的获取率”，作为领导者，您会立即知道这不是您想要实现的结果。

也许，作为领导者，您已经确定“获得新客户”对于推动病毒式增长至关重要，每个新获得的客户都会增加您获得下一个新客户的可能性。

但是，如果你只让你的团队负责“增加收入”，那么他们会认为“增加合同价值”是增加收入的好方法，而不会理解你想要的战略是以赢得新客户为中心。

避免樱桃采摘对于运行 A/B 测试尤为重要。 任何实验都可以很容易地在几十个可能的指标上产生变化，并且当他们的结果实际上未能为客户创造真正价值时，有人可以轻松地选择“只有积极的结果”来使他们的测试看起来不错。

因此，通过预先设置成功指标，OKR 可以推动问责制和透明度。

2. 努力实现业务目标

其次，当团队清楚他们寻求移动的指标时，他们会根据这些指标调整他们的工作。 当团队指标进入业务目标时，我们可以授权我们的团队高速做出分散的决策，以帮助业务取得成功。

一旦给定的团队知道他们将使用哪些指标来衡量他们的进度，我们就可以让他们决定要运行哪些计划，哪些人应该在这些计划上运行，以及他们想要实施什么样的流程。 一旦我们的团队说服我们，他们选择的指标证明在实现业务目标方面取得了进展，作为领导者，我们就可以担任顾问角色，而不是执行角色。

作为执行领导者，我们的目标应该是让所有团队“紧密结合但松散结合”。 换句话说，团队应该瞄准同一个业务方向，但他们不应该受到行政干预或行政批准的瓶颈。

当领导者感到不得不对每个细节进行微观管理时，他们的效率和战略性就会大大降低。 另一方面，当团队获得授权并紧密合作时，领导者可以专注于更可扩展地使用自己的时间和精力。

3. 根据学习灵活改变

第三，OKR 可以而且应该根据我们从客户和我们经营的市场中学到的东西而改变。

在某些方面，团队可能会决定只有三个关键结果对给定目标真正重要； 在其他方面，团队可能决定他们需要跟踪五个独立的关键结果。

而且，随着每个业务线按照自己的节奏经历不同的成熟阶段（例如启动、增长或衰退），我们需要定期重新评估业务目标。

通过 OKR 框架，我们有办法改变我们的目标和我们团队的目标，以专注于为我们的客户和投资者提供最相关、价值最高的工作。

4. 跨越不同层次的能力

第四，OKR 可以跨不同层级进行伸缩； 也就是说，前线的 OKR 可以升级为中层管理人员的 OKR，而中层管理人员又可以升级为高层领导的 OKR。

正如 Doerr 自己在谈到他在英特尔工作的经历时所说的那样：“看到 Andy Grove 的 [CEO 级别的 OKR]、我的经理的 OKR 以及我的同事的 OKR 对我来说非常强大。 我很快就能够将我的工作直接与公司的目标联系起来。”

OKR 的价值在于它可以在任何层级实施，无论是对 CEO 还是对一线员工。 执行层面的“关键成果”流入下一级的“目标”； 并且，一线团队的成就会回流到执行团队的成果中。

当 CEO 使用 OKR 集中精力时，他们会清楚地定义公司下一季度的发展方向，并在公司层面制定清晰易懂的目标。

从那里，各个部门的负责人可以将每个目标转化为各自职能的目标。 然后，每个职能部门都可以采用这些目标并为他们的团队创造关键成果，然后他们为个人创造他们自己的目标和关键成果。

通过在所有级别推动这种伸缩对齐，执行领导可以提供跨职能和资历的清晰度和激发动力。

5.一致性和标准化

最后，OKR 为我们提供了一种通用语言来指导我们的团队。 当我们拥有一致性和标准化时，我们最终可以作为一个组织走得更快、更远。

跨团队协调是公司成功和失败的最大放大器之一。 通过授权团队使用同一种语言，我们可以推动更好的协作、谈判和解决问题。

当两个团队在 OKR 框架中的目标发生冲突时，他们可以共同修改各自的目标和指标，使他们的进度不再相互冲突，而是相互协同。

例如，假设客户成功团队的目标是减少当前客户的流失，而销售团队的目标可能是接触各种新徽标。

如果没有适当的 OKR，这两个团队可能会发生冲突。 如果销售团队引入许多最初购买但随后流失的新徽标，那么客户成功团队将受到影响。 而且，如果客户成功团队强迫销售团队在让他们购买之前对徽标进行资格认证，那么销售团队就会受到影响。

但是，有了 OKR，这个假设的客户成功团队可以与他们假设的销售团队合作，完善各自的关键结果。 客户成功可以根据“合格客户的流失”来衡量他们的进展，而销售可以根据“与新的合格客户的对话”来衡量他们的进展。

这样，两个团队都不会花时间在无法发现价值的劣质客户上，从而使整个公司能够专注于将从他们的产品中获益最多的客户。

OKR 对产品管理职能的价值

每个产品都力求为客户创造巨大价值，以便企业可以为自己获取价值。 但具有挑战性的是，产品可以在多个方向实现商业价值，其中一些方向与其他方向相互排斥。

例如，产品是否应该专注于获得新用户？ 还是应该专注于推动现有用户的更多参与？ 也许它应该专注于通过其当前用户群获利？ 或者它应该改为从当前收入流中提高盈利能力？

我们需要提前选择本季度应该解决的目标。 毕竟，专注于这些目标之一通常是以不同的可能目标为代价的：

• 获得更多用户可能需要牺牲利润来为客户获取提供资金
• 推动即时利润可能需要付费墙，这会导致用户参与度下降

因此，用OKR来指导产品的方向，可以显着加速产品对业务的影响。

我们如何决定 PM 团队的 OKR？ 我们可以使用 Miro 的这个 OKR 模板作为起点。 Miro 提供的模板已经预先填充了内容功能和合作伙伴与活动功能的示例。

那么，让我们用产品管理示例填充此模板。 假设产品负责人设定了“成为客户值得信赖的技术合作伙伴”的目标，并取得了以下三个主要成果：

• 增加每个用户每月完成的平均工作流程数
• 增加每月活跃用户数
• 增加产品的集成数量

然后，每个关键结果都由产品总监领导，产品总监将他们的特定关键结果转化为目标，以指导各自的产品经理。

考虑负责“完成的工作流程”的产品总监。 他们的团队可能会取得以下主要成果：

• 完成大量 A/B 测试
• 完成一些可用性测试
• 将工作流完成时间加快一定百分比

然后，每个产品经理都会有自己的目标，然后他们会在设计、工程和其他职能部门的对应部门中为他们的产品群创造关键结果。

下面是这个特定产品团队的示意图：

OKR 学习引擎对 PM 团队特别有帮助，原因有以下三个：

1. 鼓励实验和学习而不是功能交付
2. 通过丰富的客户背景为自下而上的发现创造空间
3. 为成功提供护栏

首先，产品经理要有实验能力。 请记住，产品管理就是要最大化优势并谨慎承担风险，而项目管理则专注于最小化劣势； 这两个学科既相关又不同。

如果我们强迫产品经理进入项目管理模式，他们的唯一目标是在某个已知的截止日期前交付一些已知的功能，那么产品开发就会转变为项目交付。 当我们未能为产品经理提供向客户学习和开展范围广泛的实验的空间时，我们就会导致我们的产品停滞不前，并导致我们的公司落后于那些花时间了解客户痛点的竞争对手。

附带说明一下，从传统项目管理过渡到现代产品管理超出了本 OKR 指南的范围。 如果您希望开始这种转型，我们可以通过产品教师提供企业研讨会和 1:1 指导。

其次，通过使用 OKR，我们使分散的自下而上的发现成为我们组织内的主要创新形式，而不是在执行领导层阻碍创新。

产品经理往往比行政领导更接近客户背景，无论是通过客户访谈、客户跟踪、客户反馈分析还是数据分析。 因此，产品经理应该有权为他们的客户做出产品决策，而不是迫使高管们不得不放弃宝贵的时间来做出战术性的产品选择。

最后，OKR 为成功建立了护栏，并将客户的成功与业务的成功联系起来。

毕竟，客户是“神一般的不满”，有无数的痛点我们可以为他们解决； 他们的期望随着时间的推移而增长。 其中一些痛点在解决后，根本不会为企业带来价值。 因此，确定哪些业务杠杆很重要是一个强大的过滤器，可以帮助产品经理确定正确类型的客户痛点的优先级。

例如，考虑一个房地产网站，用户可以在其中输入地址以获得估计的房屋估价。 此房屋估价工作流程的假设产品经理可能会确定他们可以通过仅删除工作流程中的一个步骤来改进“完成工作流程的时间”、“工作流程完成率”或“用户满意度”。 此步骤恰好询问用户是否愿意与房地产经纪人讨论他们的需求，并且少数用户已向客户支持团队投诉此步骤对他们来说很烦人。

至关重要的是，此步骤是获取商业价值的货币化步骤。 如果此产品经理删除此号召性用语，则该产品将不再为业务获取价值。

有了 OKR，这个假设的产品经理将意识到他们的产品的重点是为业务获取价值，因此不会尝试删除这个工作流程步骤，即使它会为客户创造价值。 换句话说，即使此 PM 的关键结果之一是“客户工作流程完成时间”，他们也不会为了产品指标的短期收益而牺牲业务的长期生存能力。

我们现在了解 OKR 对产品管理团队的价值。 而且，随着公司发现以产品为主导的增长的力量——即使用产品来实现非产品职能（如销售和营销）的目标——任何职能的执行领导者都必须了解如何设置稳健的产品 OKR。

建立稳健的产品 OKR

为了帮助您构建适用于您的组织的产品 OKR，让我们来看看针对目标和关键结果的最佳实践和反模式：

为每个团队设定一个目标

在实施 OKR 时，我们需要记住，每个团队一次只能追求一个目标。 虽然不同的目标可以在多个季度中排序，但任何给定的季度都应该只有一个活跃的目标。

例如，我曾经领导过一个面向房地产经纪人的 CRM 移动应用程序，其目标如下：“让房地产经纪人能够以更少的努力推动更多的房屋销售。”

我本可以将此目标分解为三个较小的目标，如下所示：

• 使房地产经纪人能够通过我们的产品相互协作
• 加强房地产经纪人的在线知名度
• 使尽可能多的低价值流程自动化

但是，如果我最终使用这三个单独的目标，我就会遇到一个问题：我应该关注哪个目标？ 当团队在理论上有多个优先级时，他们最终在实践中的优先级为零。

当然，在领导层面，我们认识到企业必须兼顾多个相互冲突的优先事项。 即便如此，这些优先事项之一对于给定的团队来说是最紧迫的； 所有其他目标可以安排在未来，也可以分配给不同的专门团队。

您在本季度寻求实现的目标越多，您必须拥有越多敬业的团队； 活动目标的数量与团队数量呈线性关系。 而且，由于每家企业的营运资金都有限，因此每家企业一次只能有这么多目标。

澄清一下，我们不能忽视现实世界的需求； 相反，我们必须就现在优先考虑什么与以后优先考虑什么做出艰难的选择。

非生产性目标的例子

虽然没有适用于每个企业和每个环境的普遍良好的目标，但我们应该避免选择普遍糟糕的目标。

首先，我们应该避免在一个季度内无法取得有意义进展的目标。 例如，如果我们的组织尚未在西班牙开展业务，那么“成为西班牙的市场领导者”就没有意义。

相反，我们可以将此目标定义为“了解我们是否可以切实可行地进入西班牙市场。” 通过将目标范围限定在一个季度内是合理的，我们可以针对目标设定具体的关键结果。

其次，我们应该避免设定强制特定产品结果的目标，尤其是在我们不清楚客户痛点的情况下。

例如，一个非生产性目标可能是“淘汰最少使用的功能以提高利润率”。 虽然这在表面层面上可能有意义，但我们可能没有意识到特定的“密码恢复”功能是一种低使用率的功能，但对客户来说却具有极高的价值。

当客户无法更改自己的密码并且必须联系支持团队寻求帮助时，他们会感到沮丧并且更有可能转向竞争解决方案。 即使我们可以节省几千美元的维护成本，我们也可能会因客户流失而损失数万美元或更多。

另一个无用的目标可能是“缩小我们的功能集与竞争对手的功能集之间的距离”。 当我们要求我们的团队追赶竞争对手而不是了解我们自己的客户时，我们的产品就会偏离解决真正的客户痛点，并失去为我们的业务获取价值的能力。

毕竟，我们的竞争对手服务于他们自己的特定客户群，而我们服务于我们自己的特定客户群； 每个客户群都有不同的需求。 因此，我们的业务目标必须植根于我们客户群的特定环境，而不是竞争对手的客户群。

如果我们因为不知道客户有什么痛点而试图模仿竞争对手，那么围绕发现客户痛点设定目标比围绕竞争特性平价设定目标要更有成效。

现在我们了解了好目标和坏目标是什么样子的，让我们讨论选择关键结果的最佳实践。

设置良好的关键结果

关键结果应该确定团队是否在选定的业务目标方面取得了进展。 因此，关键结果包含三个组成部分：

• 我们正在衡量的指标
• 指标的当前状态
• 该指标的目标最终状态

谨防设置便于衡量但与所选目标不一致的关键结果。 例如，考虑“为用户创建更强大的工作流程”的业务目标。 许多团队可能决定衡量“每月活跃用户”，因为它很容易检测和衡量。 然而，“每月活跃用户”并不是一个可以证明在“为用户创建更强大的工作流程”方面取得进展的指标。

毕竟，一个团队可以创建更深入的工作流程，但最终仍会拥有相同数量的月活跃用户。 或者，一个团队可以通过提供提高工作流程意识的功能来吸引更多的每月活跃用户，但该团队可能无法有意义地深化当前的工作流程。

此外，每个目标应该有 3-5 个关键结果。 理想情况下，每个关键结果都应该彼此不同，并涵盖目标的不同组成部分。 超过 5 个关键结果可能会导致注意力不集中，而少于 3 个关键结果可能会导致失去全面覆盖。

例如，假设我的目标是“让房地产经纪人能够以更少的努力推动更多的房屋销售”。 这三个关键结果可以放在一起说得通：

• 将销售线索转化率从 30% 提高到 34%
• 将每个代理商的平均每月房屋销售额从 1.5 增加到 1.8
• 将房屋价值估算的准确性从 85% 提高到 90%

建立可行的目标

此外，关键结果需要有目标——我们不能简单地衡量一个指标然后就收工了。 为了使我们的团队能够执行的目标，它们需要是 SMART 目标：

在设定这些目标时，我们应该鼓励我们的团队选择具有激励性但并非不可能的延伸目标。

如果团队有一个他们将在 100% 的时间内实现的目标，他们就没有理由保持好奇和创新。 但是，如果团队有一个他们可能只有 20% 的时间可以实现的目标，他们就会感到失望和气馁，因为他们的目标感觉很遥远且无法实现。

一个好的经验法则是 OKR 目标应该可以实现 60-80%。 也就是说，一个团队自然应该能够在没有额外努力的情况下达到 60-80% 的目标，但需要付出一些努力才能达到 100% 的目标。

非生产性关键结果的示例

作为领导者，我们需要指导我们的团队为他们的目标选择有意义的关键结果。

首先，关键结果不应该是“虚荣”的结果，即随着时间的推移自然会出现的结果。 例如，无论团队在本季度的努力如何，“总观看次数”或“用户帐户总数”只能向上增长。

一般来说，百分比和比率往往是比总数更好的面向结果的目标。 例如，“活跃用户帐户的百分比”比“总用户帐户”更有意义，因为随着时间的推移，活跃帐户的百分比告诉我们产品是否正在为客户创造持久的重复价值。

其次，我们关注的关键结果应该对业务真正重要； 也就是说，关键结果应该与客户价值或用户价值相关联。

Logins and views are rarely good choices for key results. When a customer logs in, they haven't received value from the product yet. Similarly, when a customer views a particular page, their pain has likely not been solved yet.

Completed workflows tend to be better measures of customer value than logins or views. And, somewhat counterintuitively, customer interviews tend to be strong choices for key results. By interviewing customers, teams can identify unmet customer pain, which can then guide them towards making valuable product decisions.

Now our teams have a system of objectives and key results in place. But, we still need to set up regular reviews to drive learnings and iterative improvement across the organization.

Reviewing product OKR progress

As leaders and managers, we need to regularly review the progress that our teams have made against their set OKRs, so that we can encourage them to reflect, learn, and improve.

Keep in mind that OKRs are not meant for performance management – you should not encourage promotions or demotions based on OKRs, as that tends to incentivize “gaming the system.” That is, teams will be incentivized to pick a target that will make them look good, rather than selecting a target that truly drives customer learning and business value.

Focus on rewarding teams that demonstrate thoughtful learning rather than thoughtless execution. After all, the teams that learn are the ones that will create long-term value.

We should formally review OKRs with our teams at least once per quarter. Some product-led organizations review OKRs every 6 weeks, and others might review them every 4 weeks. On the other hand, a 2 week cadence for formal reviews is usually not a good use of time.

Furthermore, we should encourage teams to spin up dashboards so that we can check in at any time on their progress without having to schedule a meeting. By encouraging information flow, we spur the organization to move faster and farther.

Using key result goals to drive learning and business growth

The key result goals that teams have set will lead to one of three possible outcomes:

• The team meets 60-80% of the target
• The team exceeds 80% of the target
• The team doesn't achieve at least 60% of the target

If the team meets the target, then they should spend time reflecting on their learnings. Which initiatives and processes were effective? How could the team have achieved better results? Were there surprises that we didn't expect?

If the team overshoots the target, that's 结语

Executive leaders should consider implementing an OKR learning engine to empower their teams to create business value at all levels.

By combining qualitative business objectives with measurable outcomes, you motivate your teams and your direct reports to improve over time.

OKRs should not be rigidly implemented—instead, different organizations will have different best practices around OKRs. Consider which kinds of processes make the most sense for you, whether those are formal executive readouts or lightweight syncs.