惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
M
MIT News - Artificial intelligence
Recent Announcements
Recent Announcements
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Stack Overflow Blog
Stack Overflow Blog
J
Java Code Geeks
Microsoft Azure Blog
Microsoft Azure Blog
罗磊的独立博客
博客园 - 【当耐特】
H
Help Net Security
腾讯CDC
大猫的无限游戏
大猫的无限游戏
GbyAI
GbyAI
Last Week in AI
Last Week in AI
Jina AI
Jina AI
博客园 - 聂微东
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
Y
Y Combinator Blog
C
Check Point Blog
博客园 - 司徒正美
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品团队的 OKR 该怎么制定才「好」(下)
骆齐 · 2023-03-11 · via 人人都是产品经理

我们常常将OKR工具使用在团规管理、个人规划等层面上,那么当你想将OKR运用于团队管理时,你要怎么制定好目标,让OKR可以真正起效,而非成为团队的压力或阻碍?在本篇文章里,作者就总结了如何制定OKR的优缺点,以及如何制定OKR的实际方法,一起来看一下吧。

在上篇文章中,我们讨论了什么是 OKR与什么才是「好的」OKR。这一篇我们将会接续聊聊 OKR 的优缺点、适合哪些团队,流程上又该如何实际上和团队一起设计 OKR,还有一些运用上的常见问题。

一、OKR 的优缺点?

OKR 不是什么用了就会让产品突飞猛进的仙丹,它就只是一把很好用的测量工具,端看你的用法,也会有不同的优缺点产生。

1. 优点

1)专注于成果(Outcome)而非产出(Output)

上一篇我们有聊到成果和产出这件事情,以及如何将 OKR 的定义环绕着成果。

这也代表 OKR 定得好的话,它可以很有效的鼓励大家专注在成果而非产出。从目标开始思考要做什么产品改动的话,项目与成果的连结性自然就会产生。在规划项目的过程中,可以提醒自己「做这件事情会帮助我的 OKR 吗?」「如何最小化的成本测试目前的点子或策略方向是否有帮助达成 OKR?」,透过不断的反思,可以加强产出 ➡️ 成果两者的连结。

如果做了某功能之后,发现一直没有达成我们期望的成果,只要还是同样的成果,就可以调整项目方向,不用硬着头皮做没有效用的投资。

2)有一把尺来衡量进度、判断优先顺序

产品的优化是永无止境的,如果只是做「对」的事,有的时候很难取舍,但当有了 OKR 后,团队会有明确的承诺和责任,可以专注在真的可以帮助成果的事,避免和主要目标不相关的事情占用团队的精力。

如果能够搭配 Dashboard,每周或双周检视 OKR 的进展,也会比较有回馈感,知道自己有在向前迈进。如果没有,也能借此提醒自己是否应该试试不同做法。

3)协助达成共识

把目标写出来之后,可以清楚看见不同团队的目标和最终成果是否有相冲突,如果有的话,就可以在规划阶段提前先协调沟通。如果某 OKR 需要其他团队的认同才能达成,也可以讨论看看是否两个团队共用同一项 OKR,当目标相同时,资源和优先级都会更好讨论。

例如,我目前的团队在内容策略,需要隔壁的推荐算法团队支援才有办法交付成果,两个团队讨论过后决定共用一个「借由个人化内容达成更高」的 OKR(*非真实 OKR,只是举例用),并且定期开会,一起讨论点子来共同贡献相同的目标。

2. 缺点

1)定义不当的话容易沦为待办清单

OKR 的框架很好,但目标和 KR 的制定需要练习,如果太专注在执行的「方式」和「时限」,而非专注在专注在成果(outcome),就没有办法达到 OKR 的本意。

Output 是你的「输出」,是你直接产出的第一手结果,在数位产品中可能是个功能,在内部营运中可能是一套新的流程。而 Outcome 是「成果」,是你的输出带给人们的影响,在数位产品中是每个功能带给用户的效益、改变的行为,在内部营运中是新的流程被运用后的那份价值。

在上一篇 OKR 的介绍中我也有提供一些协助大家专注在成果的范例与方法,如果还是不清楚的话,也非常非常推荐大家这本书《Outcome over output》,我非常喜欢他对于这些名词的定义和心态建议。

2)Key Result 定得过高,带给团队不必要的挫折与压力

我不知道该不该说这是缺点,感觉只要是目标框架,不管是 KPI、OKR 还是其他,都有可能会有这个问题,毕竟人类天生就不擅长做假设与预估。

但我很肯定的是我刚开始用 OKR 的时候,每一次都定得过高,这种情况可能持续了不只一季两季,而是持续了一年两年,虽然一直下调还是很难达到。

我只能说各位 Leader 请面对现实,OKR 不是用来鞭策大家然后逼迫大家加班烧脑的,OKR 是来定方向的。不是说定得很高就更有机会达标!达不到就达不到,试着找到无法达成的原因加以调整,也同时修正 OKR 让它更靠近现实吧!虽然可能需要好一阵子的练习,但只要领导者愿意修正并接受自己估计错误这件事,相信团队不会过度责难的。

3)运用不当时可能造成团队各自为政的情况

如果因为 OKR 划清楚界线后,过度保护自己的目标而忽略其他人的目标,容易带来团队保护自己资源、各自为政、互不支持的负面效应,这个时候上面提过的「共用 OKR」就是一个有效的方法来突破这种状况。

共用 OKR 有几种常见的方向,最常见的莫过于在紧密合作的成员身上(e.g. A 和 B 团队有共同的项目要推动,共享一个 OKR),也可以是在垂直组织上(e.g. 所有「买家体验」相关的团队,大家共用一个目标,共同协助买家找到喜欢的商品并购买),也可以是用在横向组织上(e.g. 全公司的设计团队都必须一起遵守设计标准)。尽早找出和你相依性高的团队,一起定目标吧!

二、什么样的团队适合用 OKR?

如果我是 OKR 的发明者,我可能会说「任何人都可以用 OKR!」(会吗)但事实上,我觉得虽然说的确他可以被运用在很多不一样的产业和组织,但我自己觉得弹性大、变动性高、需要探索试错的团队,其实是最适合使用 OKR 框架的。

我会这样认为的原因是,OKR 的最大优点是帮团队创造一个既模煳又清晰的空间,让团队在特定方向下还保有弹性与提升的空间。所以如果你的团队一直在跑实验、做测试、探索方向,那么你可能很需要这样子的空间,才不会把目标定太死,遏制了团队的发展。

三、手把手教学!该如何带领团队一起定 OKR?

我的领导风格比较是带领大家一起协作,所以会希望让团队成员都可以参与目标的设定,以下和大家分享我和团队一起订 OKR 的步骤与流程,让第一次尝试的人有个方法可以参考。假设你已经有很明确的团队愿景和目的,只是要规划下一个季度或年度的话,可以往下看。

步骤一:定义目标(Objectives)

首先,我会收集团队对于下一个季度的想法。如果你的团队是会对于目标有想法的,可以问大家「到下一个季度结束之前,我们想要达成什么?」,整理想法之后做总结;如果你的团队习惯自上而下的目标制定方式,那么你可以先定出一个目标草稿,分享给大家,问大家「这个目标大家觉得优点是什么,缺点是什么,是可行的吗?」,整理反馈之后做总结。

步骤二:定义关键成果(Key Results)

目标有个方向之后,接着可以问大家「我们该如何知道我们正在朝这个目标前进?」我会建议不要直接问「我们要用什么指标」或「我们该如何衡量」,不是每个成员都会对商业指标和衡量方式有熟悉度,所以当你这样问的时候,有些人会不知道说什么。问上面的这种开放式问题,会比较容易开启对话!一样,收集反馈,询问大家为什么觉得这样衡量是好的,再总结。

步骤三:写出第一版草稿、获取团队与合作伙伴的反馈

最后,OKR 还是必须由少数人来做取舍与决定,所以产品经理可以把大家的反馈听进去之后,写出第一版草稿,并且分享给团队与相关的伙伴们获取反馈。让团队参与 OKR 的定义好处多多,定出来的目标更容易让团队买单,也更容易创造责任感(ownership)。

四、其他 OKR 应用常见问题

Q:通常都多久定一次 OKR 呢?

A:以互联网行业来说,因为变动很快,每一季的 OKR 应该都要被重新讨论与调整,但一整年度的 OKR 大方向不应该改变。

Q:如果定完下一季 OKR 之后,做了一个月之后发现 OKR 定得不够好,这个时候还可以改吗?

A:当然! 我刚开始用 OKR 的时候常常会把 OKR 奉为圣旨,不敢动它,现在用久了,我不想让 OKR 主宰我的生命啊。老话一句,面对现实,如果它不合时宜,在和自己团队、相关讨论过后决定要改动,那就改!改动之后也要好好告知所有人「为什么」要改,沟通清楚就没问题啦。

Q:我们每周和老板报告 OKR 进度的时候,都很任务导向,像在报告我们之前做了什么、之后又要做什么,太过于琐碎,要如何更改报告方式让我们更专注在目标呢?

A:首先,我还是会建议可以重新检视现在订的 KR 是否太「产出」导向。那么假设你的 KR 设定都没有问题,纯粹是报告的方式想要被调整的话,我认为在报告的环节上,或许可以从 what works/what doesn’t work/what’s next 的角度切入,也就是说,不用说出所有事情,聚焦在「学到的东西」和「因为我学到这些我会这样调整」的内容身上,可以更有效的开启对话。如果有其他 OKR 的应用问题,欢迎私信交流。

就说这么多。

作者:骆齐;公众号:产品经理骆齐

本文由 @产品经理骆齐 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。