• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_three
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
产品目标—在敏捷团队中使用目标和关键结果(OKRs)
介绍
你的团队是否会问:“我们怎么知道我们一切正常?”除了知道“最终”的成功可能是什么样子之外,更重要的是了解在你前进的过程中你的活动和进展如何与你的抱负相匹配。
这不仅取决于你定义的产品目标的类型、质量和选择,还取决于你如何使用它们。如果你设定了带有特定发货日期的目标,那可能无助于你组织日常活动。
产品团队肯定会花费大量时间低着头,专注于产品发现或交付。但是,当他们抬起头来寻求下一步行动的指示时,他们不应该只看到功能列表和发布日期。
这就是有效的产品目标与设定任意里程碑的区别。
内容
产品目标入门
在本章中,我想通过回答一些基本问题来介绍产品目标的基本概念。
什么是产品目标?
显然,很难将目标这样的通用术语压缩到一个通用的定义中。因此,与其试图定义产品目标究竟是什么,我将专注于它们的作用——至少在正确使用的情况下。
产品目标应该为产品团队和你的组织做的主要事情是使你的战略方向更加具体。虽然未来三到十二个月的战略方向提供了高级别的方向,但产品目标有助于确保更多的战术决策也与该方向保持一致。虽然产品战略也可以包括高层次的数字来表达特定的战略优先级,但产品目标在专注于可衡量的进展时会变得更加有效。产品目标可以包含构建产品的更多方面,而不仅仅是纯粹的绩效。稍后我们将讨论定性和定量目标设定的结合。
不过要小心。因为产品目标旨在连接产品战略和产品执行,所以很容易混淆这三个术语。
考虑到这些事情,让我们确定一个工作定义,以完成本文的其余部分。
产品目标定义
产品目标是一组有形且可衡量的产品成功表现形式。产品目标通过为团队提供一组具体而全面的指标,将产品战略和产品执行联系起来,让他们知道自己是否在朝着正确的方向前进,并在需要时调整他们的行动。
产品目标与产品战略有何不同?
无需详细介绍产品战略,以下是每个(好的)产品战略应该能够回答的主要问题:
1.你的产品正在为你的用户解决哪些基本问题,你希望在未来解决哪些问题?
2.你的用户可以使用哪些替代方案来解决该问题(例如直接和间接竞争者)?
3.定义你的产品的核心价值主张是什么?
4.与那些直接和间接竞争者相比,你的产品有何独特之处?
我喜欢使用 Product Field 框架将这些问题的答案可视化,以使指导产品发现工作的(不断发展的)支柱始终可见。
产品战略是产品发现的起点。但是如果产品战略不明确,产品团队不应该把它归咎于他们的经理或C级领导。相反,我鼓励他们自己明确自己的战略方向。通过利用像 Product Field 这样的协作框架,你可以勾勒出产品的战略方向并很容易地识别现有的盲点。
重点不是制定麦肯锡级别的公司战略。但是,当你在探索任务的问题空间中导航时,必须做出权衡决定时,可以参考一些东西。
总的来说,我喜欢将产品管理的主要学科划分为三个飞行级别。
1.产品目的/愿景/使命和产品战略
2.产品目标和产品路线图
3.产品发现和产品交付
因此,我没有将这六个学科视为孤立的活动,而是相信一个更相关的观点:
不仅一个飞行级别内的学科相互关联,而且来自一个学科的见解和经验向上或向下流动以通知其他飞行级别。因此,这六个学科中每一个学科的质量都会从根本上影响其他学科之一的实施情况。当产品战略不明确时,许多团队在被要求“定义本季度的目标”时会遇到困难。
到达“正确”的产品目标集是一个需要迭代的旅程——通常在目标周期内和目标周期之间。但是,如果团队一开始就拥有正确的策略,事情就会变得容易得多。
如何确定产品目标?
产品发现需要围绕要解决的问题空间建立一致性,并深入研究你的用户、客户或利益相关者面临的挑战。
毕竟,你要确保你已经了解实际(并且通常是潜在的)问题是什么以及它是否值得解决。但是,一旦你以值得改变的用户行为形式识别并组织了你的发现,团队往往会迷失方向。
现在,用户问题很少适合立即用作目标。相反,我们必须考虑如何衡量你的成功。要设定切实的产品目标,你必须从用户研究中收集定性和定量的见解,以确定如何改变用户细分的行为。
我们先来看一个 b2b 的例子。假设你正在构建分析软件,并且你的战略重点是增加来自代理客户的收入。通过研究,你可以识别目标受众面临的具体问题。
例如,客户经理可能正在为向客户报告结果需要多长时间而苦恼,而 IT 管理员需要不断更新数据合规性。因此,如果你专注于为客户经理识别的结果,基于他们核心问题的“我们如何......?” 的挑战可能是这样的:
“我们如何为客户经理加快客户报告结果的过程?”
尽管这为构思和原型创建提供了大量上下文,但你需要更加具体。
如果你要为该问题提供解决方案,你想知道成功是什么样的。你很少能将一个产品发布与公司收入等高级指标联系起来。这意味着团队应该考虑具体的指标来表达对客户经理来说“加速”是什么样的。
从定性的角度来看,你可以利用修改后的客户投入评分现场调查来查看感知速度如何变化:你可以设置产品目标,例如“报告生成过程的客户投入评分为 4.5”。
从定量的角度来看,你可以查看该产品领域中的“花费时间”或创建的报告数量等指标。这两个指标都可以告诉你行为发生了怎样的变化。
定义适用于你已确定的解决方案的产品目标应该是一项跨职能的工作。分析经理可能会帮助你知道什么是可能的。用户体验设计师可能会带来一个新的用户视角来定义“成功的样子”。
你将已识别的用户问题转换为可衡量的产品目标的方式应与你在公司中利用目标的方式保持一致。如果你使用目标和关键结果(OKR)、北极星框架或平衡计分卡等内容,请务必调整此流程。
将目标和关键结果 (OKR) 用于产品目标
OKR 是设置、跟踪和审查产品目标的非常有效的方法。在本章中,我将概述 OKR 的结构,以及使用输出和结果 OKR 的区别。
什么是目标和关键结果 (OKR)?
OKR 代表目标和关键结果。简而言之,OKR 将目标设定的最佳方面结合到一个框架中:一个高度鼓舞人心的定性愿景,具有简洁和可衡量的指标来确定成功或失败。
一个目标就像一个使命说明,只适用于更短的时期。一个伟大的目标会激励团队,在设定的时间范围内很难(但并非不可能)完成,并且可以由一个或多个设定它的人独立完成。一个目标通常应该是:
定性和励志的
很难但并非不可能实现的
限时的
可由团队独立操作的
关键结果采用所有鼓舞人心的语言并将其量化。你可以通过问几个简单的问题来创建它们:我们如何知道我们是否达到了目标?哪些数字会发生变化?一家公司的每个目标应该有两到五个关键结果。一般来说,关键结果可以基于你可以衡量的任何内容。
目标和关键结果 (OKR) 定义
OKR 将目标设定的最佳方面结合到一个框架中:一个高度鼓舞人心的定性愿景,具有简洁和可衡量的指标来确定成功或失败。关键结果采用所有鼓舞人心的语言,并通过 2-5 个整体衡量标准对其进行量化。
如果你明智地选择 KR,你就可以平衡增长和绩效或收入和质量等因素,确保你能同时拥有潜在对立的力量。
OKR 的“发明”通常归功于安迪·格罗夫(Andy Grove)在英特尔任职期间。后来,通过谷歌等硅谷公司的广泛实施,它得到了普及。虽然许多人钦佩谷歌在员工绩效管理方面所做的改进,但 OKR 已经进化并变得更多。
这是一个 OKR 设定的示例:
• 目标:我们是一个集成的、成熟的平台解决方案
• 关键结果 1:我们的企业客户满意度 >75%
• 关键结果 2:没有因为“产品不成熟”而失去销售机会
• 关键结果 3:100% 的受访者将我们的网站与“企业”、“值得信赖”和“有能力”等词联系起来
如今,OKR 对敏捷产品团队的吸引力在于其改进我们工作方式的核心承诺:
1.更专注
2.更自主
3.更一致
更专注
OKR 的典型周期是一个季度。较小的公司可以将其与年度 OKR 结合起来,让每个目标都瞄准未来三个月之后的目标。
此外,虽然每个季度为一个团队设置最多三个 OKR 是标准的(并且可以),就能够专注于一些关键举措而言,这已经带来了巨大的进步。虽然一些利益相关者将“敏捷”与每两周在 Sprint 计划中改变主意相混淆,但 OKR 提供了贯穿整个季度的持续路径。
此外,即使 OKR 不一定需要涵盖你的所有工作(每个人都知道一些维护工作可能很关键),但它们应该反映对你的团队来说最重要的事情。
更自主
按照设计,有效的成果 - OKR 不谈论功能。相反,他们将对话转移到团队应该寻求产生的影响上,而不是衡量已发布功能的数量。
对于你的利益相关者环境,这意味着他们将推迟与你讨论他们的功能愿望清单,而是首先就一组结果指标达成一致。稍后我们将讨论结果目标。
对于团队来说,这意味着首先关注(最关键的)问题以达到他们的(雄心勃勃的)关键结果。
更一致
定义 OKR 的过程应该涉及公司的各个层面。虽然领导团队制定公司级别的 OKR 是很自然的,但下一步是让公司的其他成员参与进来。这就是单个团队如何受到公司总体方向的启发,以匹配的 OKR 的形式定义他们的贡献。在季度开始/结束时对整个公司进行 OKR 定义和评审,从而显着减少团队之间的误解。
结果 OKR 与输出 OKR 对比
许多产品团队正在寻找方法来改变他们的工作方式和思维方式,以取得成果。无论是通过基于主题的路线图、影响地图,还是...目标和关键结果 (OKR)。
然而,人们普遍错误认为 OKR 具有“内建”成果。以这种方式设定目标会自动将你的讨论限制在更少的解决方案上,例如产出。
现在,在我们进一步讨论之前,让我们先回顾一下我在谈论成果和产出时的意思。
对我来说,成果描述了促成影响的可衡量的行为变化。另一方面,产出是通过活动交付的工件。无论是针对客户、用户还是内部利益相关者,它都是创造这种行为变化的一种方式。
OKR 可以与成果或产出一起使用。与每个框架一样,OKR 的好处在很大程度上取决于你如何使用它们。当然可以将部分或全部关键结果设置为产出。在某些情况下,这甚至可能是更好的开始方式。一些团队陷入关键结果的定义过程,因为他们试图将一切都变成成果—只是为了它而做它。
以下是一个实际示例,关于成果 OKR 和产出 OKR 设定可能有什么不同:
但是,在你的组织中转向基于成果的产品目标不仅仅是定义更多的“成果式”关键结果。
将成果付诸实践需要在定义 OKR 之外对流程进行更改。
结合 (OKR) 和敏捷产品管理
本章将阐明团队如何有效地将 OKR 的优势与现有的敏捷实践(如产品发现、产品路线图和Scrum)相结合。
构建数字产品通常似乎就是推票和发布代码。相反,我想为可持续的敏捷产品管理过程的三个层次拓宽你的视野:
1.产品路线图
2.产品发现
3.产品交付(如使用 Scrum)
如果敏捷产品团队能够将关键结果集中在成果上并将 OKR 集成到现有工具、实践和例程中,那么他们会从使用目标和关键结果中体验到最大的附加价值。
定义他们的 OKR 有助于产品团队调整目标并致力于实现目标。但是他们仍然需要一个额外的会议来选择具体的举措和后续步骤。为了让团队进入问题空间的产品发现阶段或(先前发现的)解决方案的交付阶段,需要专门的会议来确定史诗和计划的优先级。但是你怎么能组织这个会议呢?
在 OKR 定义研讨会之后使用影响地图选择史诗
让我们在这个史诗选择会议期间阐明影响地图如何帮助产品团队。
快速回顾一下,以下是我的五个影响地图级别:
为何 - 对整个公司/部门都很重要的影响级别目标。
是谁 - 对影响做出贡献的(内部和外部)用户群(参与者)。
如何 - 团队试图为操作者创造的行为变化。
什么 - 团队可以追求的潜在解决方案(产出)以改变行为。
是否 - 产品团队正在运行的实验,以确定产出是否值得追求。
如果你使用公司级别的 OKR,则这些关键结果很可能可以作为你的影响作为起点的候选者。这代表了从季度或年度角度对公司成功的定量衡量。
基于以前的研究工作,操作者层面应该一清二楚。如果没有,请安排本季度的额外研究。
如果你的团队已经建立了以成果为导向的关键结果,那么这些结果现在可以作为 怎么级别的输入。理想情况下,你的影响地图已告知你的 OKR 定义过程,因此两个观点之间没有差距。
因为你(应该)知道关键结果形式的哪些成果是优先事项,所以你现在可以过渡到解决方案空间。如果这些结果是基于现有的产品发现工作,那么你的下一步行动之一应该是结构化构思以提出功能想法。
这些想法(连同以下实验)可能在上一季度已经发生,以告知你现在想要关注的交付工作。因为毕竟,你可能只能通过提供的解决方案实现这些关键结果。
使用基于主题的路线图沟通史诗和举措
遗憾的是,大多数企业仍然依靠甘特图样式可视化后基于时间的路线图来计划未来 12 个月的产品开发。虽然这种方法可能适用于我们“过去”所做的静态瀑布规划,但它几乎不适用于拥抱不确定性而不是试图与最后期限斗争的敏捷和迭代方法。
规划你的工作更合适的方法是根据所谓的基于主题的路线图。它们使你能够优先考虑更广泛的举措,而不是固定的功能集,并在展望未来时得知不断增加的不确定性。
你还可以将主题作为特定史诗的父元素进行比较。一个主题代表一个更重要的用户或业务问题,你可以利用该问题来发现解决方案(如Epic)以实现你的目标。
典型的基于主题的路线图的三个类别可以这样区分:
1.现在 - 已经过验证、已经被更详细地说明并且当前正在实施的想法。
2.然后 - 产品团队将使用产品发现探索战略优先级列表。
3.以后 - 可能适合当前战略重点的想法,但尚未用于发现或交付工作。
主题的示例可以是诸如“用户增长”、“收入”、“流失”或“企业”之类的内容。相应的史诗可能是“推荐机制”、“免费试用”、“自助服务中心”或“单点登录”。
OKR 和基于主题的路线图在你提交并对齐 OKR 集后(例如每季度一次)就可以很好地结合在一起。你不必立即将关键结果转换为发布日期和甘特图。相反,路线图中的主题会告知您的 OKR 优先事项,反之亦然。
但这不是关于在主题或史诗之间进行选择的问题。基于主题的路线图还包含史诗(如果通过产品发现识别)。
但是,如果您还没有完成决定要追求哪个史诗的工作怎么办?那么首先使用成果 OKR 几乎没有意义。你可以让团队负责构建“这个东西”。
基于日期的发布计划是有时间和地点的。但是直接从 OKR 定义研讨会沟通选定的史诗不是其中之一。
结合 OKR 和产品发现
产品发现描述了协作回答两个关键问题的迭代方式:
1.这是一个值得解决的问题吗?
2.这是一个值得追求的解决方案吗?
就像目标和关键结果(OKR)一样,我更喜欢帮助团队找到他们自己的方式,以对自己有效的方式使用产品发现技术,而不是规定给定的流程。
因此,我开发了适应性产品发现方法,该方法指导团队完成非线性过程,以减少给定任务的问题空间周围的不确定性。
如前所述,产品发现与基于主题的路线图结合使用效果很好,因为它鼓励您的产品团队考虑成果,而不是从一开始就解决详细的功能想法。
但在产品发现中使用 OKR 时也存在挑战。首先,有时间方面的问题:当你再本季度开始时定义了 OKR,然后开始了(典型的)6 周探索阶段,你几乎没有足够的时间来对你的正在做的工作产生影响。请记住,交付的功能有时需要数周才能让客户掌握,然后才能导致行为和指标发生变化。
另一方面,如果您还不知道下一季度的目标,你应该如何决定关注哪个领域?这就是基于主题的路线图的概念派上用场的地方。
因为你对你的团队想要和需要在“稍后”工作的领域有一个粗略的了解,所以你可以为当前季度定义产品发现 OKR。这可能包括如“了解 10 个企业产品前景的关键需求”等关键结果作为下一季度的“企业”主题。
通过这种方式,敏捷团队的双轨工作可以使用 OKR 进行组织,并且产品经理可以清楚地知道她的产品发现工作的重点是什么:
虽然产品发现侧重于问题空间,但许多关键结果侧重于交付和业务结果(这本身就是另一个讨论)。这里最大的问题是,这会将注意力从团队的发现活动中转移开。通过商议并定期重新访问专门的发现OKR,团队可以提高对他们工作中这部分(通常是看不见的)的认识。
如果你的公司认为 OKR 应该反映最高优先级这一事实,那么使用一组专门的产品发现 OKR 的理由就更大了。毕竟,产品发现应该是你的首要任务之一。单独的 OKR 集可以帮助建立对此的共同理解。
在我看来,OKR 对敏捷环境最重要的额外好处之一是与日常任务的(持续的)连接。因此,当你将 20-30% 的日常活动花费在发现上时,我认为应该为这些任务制定一个总体目标。
有效的 OKR 提供了整体视角。因此,除了业务结果(效能方面)之外,还值得整合产品质量或流程改进等内容。产品发现 OKR 可以帮助在个人和团队之间建立一致,以专注于基本实践。或者,你也可以将特定的发现方面建立为单独的关键结果,而不是将整个集合专用于它。
请记住,产品发现 OKR 的主要工作是使产品发现工作成为你团队的可见的优先事项。它不一定是现有 OKR 蓝图的完美化身。
如何结合 OKR 和 Scrum?
在产品交付方面,你需要确保产品待办列表中尽可能多的条目可以与 OKR 相关联。这是将团队的日常任务与组织的更高目标联系起来的唯一方法。如果你使用JIRA来管理你的用户故事和敏捷流程,你可以通过一组自定义字段轻松集成此 OKR连接。
然后,内置仪表板会简要概述团队为达到 OKR 所做的工作量:
接下来,你还可以通过将你的活动与与之相关的问题联系起来,进而把你的每个敏捷例行工作与你的目标联系起来 :
双周冲刺计划:在我们的 OKR 方面取得进展的下一个优先事项是什么?
双周评审:我们取得了哪些产出和成果?
双周回顾:我们的协作如何符合我们的规范?
产品目标示例
无论你是使用 OKR设置产品目标还是面临基于你所在行业的特定挑战,本章都将提供实际示例来激发你的下一个目标周期。
除了页面浏览量、转化率、客户满意度或流失率等一些通用指标外,我想在本节中介绍一些特定领域的产品目标示例。
SaaS 产品管理的产品目标
SaaS 产品主要使用订阅收入将其产品货币化。这意味着在中短期内,产品经理需要关注比实际流失事件更切实的领先指标。
从产品战略的角度来看,将降低流失率作为公司的首要任务可能是有意义的。但是为了衡量正在进行的产品工作的成功,团队需要看向其他地方。
以下是产品经理可以采用的一些示例指标:
入职步骤完成率
在前 30 天实现的关键指标数量(如连接数量、收集的研究见解、建立的集成)反映了你的用户的满意时刻
使用频率,同时牢记产品的应有的使用模式
在中长期层面,也可以使用其他指标,如 ARR、头像数量或年度合同价值,使战略方向(增长、货币化、保留)更加切实可行。
企业产品管理的产品目标
在为企业构建产品时,许多产品经理会因缺乏定量数据而感到沮丧。
毕竟,该新产品领域的页面浏览量是否达到 70 或 75,通常都无关紧要。然而,这是为有限数量的公司制造问题的现实,每个帐户的用户数量甚至更有限。
但这并不意味着目标会过时。相反,你必须在定性指标和卓越的内部流程上加倍努力。
这里有些例子:
客户报告的实时错误数量
每个客户的功能使用频率(正确细分!)
客户投入得分(即每个新发布的功能)
产品交付 OKR 示例
• 目标:满足现有企业客户,为续约奠定基础
• 关键结果 1:每个客户端 0 次重大事件(如阻断错误或数据丢失)
• 关键结果 2:每个请求和实现的特性至少被相应的客户端使用一次
• 关键成果 3:建立企业客户反馈流程,平均反馈“满意”

• 目标:成功推出我们主要产品的第 3 版
• 关键结果 1:在超过 15 种出版物中获得已发表的产品评论
• 关键结果 2:获得 10.000 个新注册
• 关键成果 3:实现试用付费比例超过 50%
产品发现 OKR 示例

• 目标:我们的用户对我们接下来要构建的内容感到兴奋
• 关键结果 1:JIRA 集成用户研究、构思和最有前途的想法的验证
• 关键结果 2:测试三种新的研究技术来捕捉用户的兴奋

• 目标:激活我们产品的用户测试
• 关键结果 1:进行 21 次面对面的用户测试和面试
• 关键结果 2:从 Usertesting.com 获得 15 个视频采访

——译者:Leo Yan
参考资料:
(1)Product Goals - Using Objectives and Key Results (OKRs) for Agile Teams (2020)