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

推荐订阅源

Recent Announcements
Recent Announcements
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
Engineering at Meta
Engineering at Meta
Stack Overflow Blog
Stack Overflow Blog
Google DeepMind News
Google DeepMind News
Microsoft Security Blog
Microsoft Security Blog
aimingoo的专栏
aimingoo的专栏
I
InfoQ
B
Blog
WordPress大学
WordPress大学
Jina AI
Jina AI
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
酷 壳 – CoolShell
酷 壳 – CoolShell
阮一峰的网络日志
阮一峰的网络日志
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
G
Google Developers Blog
C
Check Point Blog
月光博客
月光博客
L
LangChain Blog
GbyAI
GbyAI

人人都是产品经理

为什么你的产品找不到差异化?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-02-16 · via 人人都是产品经理

近几年,OKR框架在国内掀起了一股风潮,许多公司都开始使用它来追踪产品团队的成效,然而并不是所有公司都能正确使用OKR这个工具。本文作者结合自身使用OKR的经验,分享了OKR在产品开发团队中的运用、如何设计好以及他的使用心得,一起来看一下吧。

OKR 框架这几年在国内掀起一股风潮,听闻许多公司都开始使用这样的目标框架来追踪产品团队的成效,但也听说有些人不觉得自己的公司有真正正确使用 OKR 这个工具。所以想说综合一下过去几年使用 OKR 的经验,来分享一下 OKR 在产品开发团队中的运用、如何设计好的 OKR 和我自己的 OKR 使用心得。

01 什么是 OKR?

OKR = Objectives(目标)& Key Results(关键结果)

OKR 顾名思义,就是一个拿来设定目标与追踪进度的框架。如果团队是一辆火车,那麽「目标(Objectives)」就是我们旅程的终点站,是我们想要去到的地方;而「关键结果(Key Results)」则有点像是中途停靠的站点,经过每一次确认中停的车站,来确认我们走在对的方向上。

这个框架比起过往的 KPI(Key performance indicators),更专注在前面的 O,也就是你做这些事情的目标与动机,而 KR(Key Results),只是拿来测量我们是否在正确方向上的一把尺。

OKR 的框架可以被运用在个人计划、团队目标、组织目标管理等等,根据使用范围的不同,标准也会稍微不同。越高层级的目标,预留的弹性就要越高,让下面的团队有好的自主性、在弹性下调整自己的目标与方向;越执行面的目标,会越来越明确。

这一篇我想分享的 OKR 使用,主要是针对产品开发团队的目标制定,通常会是数个人到十几个人共用的一个目标追踪方法。在这样的团队规模,非常需要抓准弹性 VS 具体性的平衡,让团队既有明确方向,但也能持续保持敏捷,试错调整。

02 「好的」OKR 是长什么样子?

听完上面的解释,可能对很多人来说 OKR 还是有点抽象,这边举几个例子:

【范例一】

公众号希望可以督促自己不要偷懒,持续更新,给粉丝提供价值。

Objective:固定持续产出新的内容;

Key Result 1:每个月发表至少 2 篇文章;

Key Result 2:每个月组织一次读书会活动。

【范例二】

我们是一个电商平台,我们想帮助买家更容易搜寻到想要的东西并购买。

Objective:提升搜索效率;

Key Result 1:首次搜索结果页的商品访问次数提升X%;

Key Result 2:用户搜索到下单行为的转化率提升Y%。

这里的目标是改善搜索的效率,所以第一个指标看的是「第一页的搜索结果是否更相关了」,第二个指标看的是「用户看了之后有没有进一步动作/购买」,如果结果更相关、用户都有往下一步前进,那么搜索的效率就变得更高了。

如果大家看以上的案例,可以发现,目标只会定义方向,而关键结果则会和我们怎么执行有关系。两者加起来,让人一看就可以知道你为什么要做这件事情、怎么做、以及最后理想成果的样貌。

03 「不太好的」OKR 范例

好的,看完一些范例之后,那我们再来看看什么叫做不那么好的 OKR!

【范例一】

产品精英社希望可以督促自己不要偷懒,持续更新,给粉丝提供价值。

Objective:继续写文章,组织读书会等活动;

Key Result 1:产品思维方向今年写出 12 篇文章;

Key Result 2:行业洞察方向今年写出 20 篇文章;

Key Result 3:通用能力方向今年写出 5 篇文章;

Key Result 4:思考读书会到底要读哪些书籍;

Key Result 5:思考如何跟粉丝有更深入的互动。

好的,那么这种写法有什么问题呢?

错误一:在目标上就太过明确的指出做法

的确写文章和读书会都是提供服务的方法,但是我们的目标如果是提供服务,其实还有其他的方式,如果在目标阶层就把「方法」锁得太死,会降低弹性,也容易让人忘记当初到底「为什么要做这些事」。

错误二:把关键结果(KR)当 To Do List 在用

OKR 不是你的 to do list!关键结果只是帮助自己确认方向正确,不需要把每一项任务都写在上面,这样反而会让目标追踪很失焦。

网上大多推荐 2–4 个 KR,所以我一开始用的时候都硬要写到 3 个 KR,不过我用下来觉得好像还是太多,发现 2 个左右就蛮够用了。把数量减少的同时,也会强迫自己想把优先级想的更清楚,所以我个人会建议尽量精简即可。

错误三:参入了无法明确衡量的关键结果

你有发现吗?KR 4 的定义非常模煳,「思考读书会要读哪些书籍」,到底怎样叫做有思考,怎样叫做没思考?如果我洗澡的时候想了五分钟,这样算有还是没有?OKR 的重点就是要足够弹性但又足够具体,这种有和没有之间的事情我们是不能接受的。

那再让我来举另一个例子:

【范例二】

我们是一个电商平台,我们想帮助买家更容易搜索到想要的东西并购买。

Objective:提升搜索效率;

Key Result 1:搜索转化率提升 X%;

Key Result 2:开发三个以上功能提升用户搜索体验;

Key Result 3:搜索带来的收入提升10%。

错误一:指标定义太过模煳

在电商世界大家常常把转化率挂在口中,但这转化率到底是从哪里转换到哪里?在定义 OKR 的时候一定要非常明确,案例里的 KR1 来说的话,光写出 转化率是不够的,写出详情页到下单的转化率,或者浏览到详情页的转化率才是正确的做法。

错误二:关键结果和目标没有直接相关性

在 KR 2 中,范例提到想要开发三种新功能,但是在实际的产品开发中,真的是功能越多越好吗?这可不一定,所以在订 OKR 的时候最好避免「做多少功能」这样的写法。

不过!这不代表我们不能放上「执行面关键结果」,有些情况下,其实使用执行性的关键结果是更好的,比如说,假设我们的目标是要去了解一个新的产品领域,在这种探索问题的阶段,就可以写「执行 X 场用户访谈来了解用户」这样子的执行性 KR,因为研究做得越多,我们就会更了解这个新的产品领域,两者是有明确直接相关性的。

另外一种也很适合放在 OKR 中的「执行面关键结果」是采用率,比如说如果我们要将旧系统迁移到新的系统,比起说「我们完成了多少个功能的迁移」,不如说「有多少百分比的用户已经开始使用新系统的功能来达成目标」等等,换一个角度以用户的目标来思考,也会帮助自己设定更好的 OKR。

错误三:把商业影响当作产品成果

这一点其实并不是真正的「错误」,而比较是我个人对于产品团队 OKR 的看法。我们的确可以把商业影响放在目标上或关键成果上,尤其在组织等级的 OKR,这似乎是蛮合理的,但是若要用在产品团队上,我个人认为这并不是最好的产品指标。

当我们做了新的产品功能或改动,这叫做团队的产出,当我们的产出实际影响了用户行为、产生价值,这时候会创造出的是用户的行为成果,而当用户的行为成果转换成了商业价值,那么才会带来商业影响。

在产品团队的营运中,产品经理与团队成员们应该要长期关注的是用户行为的成果以及用户成果与商业影响的关联性,而非只关注商业影响。我做的功能是否有解决用户问题?解决这个用户问题是否可以替公司带来正向影响?而不是思考如何去用各种手段刺激营收的增加。

用成果当作 Key Result 有一个很大的好处,就是因为成果是人类的行为,所以它们通常都是可衡量、也可直接观察到的,非常符合 OKR 的定义。

当我们只关注营收,不关注用户成果的时候,除了可能会变成乱枪打鸟,而且还可能产生很多所谓的 Dark UX pattern,比如说在电商网站上常常会跳出折价券对话框,一个按钮是「登入获取折价券」而另一个按钮上面写着「我不想要有折扣」。这样的设计我想或许对营收有帮助?但是这真的有解决用户问题吗?用户当然还是想要有折扣,但这样的文字好像有点……

不过就算把关注点放在用户成果,我们还是要非常关注用户行为和商业成果两者的关联性,毕竟公司要可以赚钱才可以生存。所以在设定 OKR 时锁定的用户行为,也要和商业影响有明确的正相关才行!(例如用户看越多商品、搜索越多、加入购物车越多,都代表他们找到好物,也代表会替公司赚钱,这些都是不错的指标)

总结来说,我个人是比较推崇把产品团队的 OKR 主要关注点放在用户的行为改动上,这样的关注点比较能够兼顾商业影响与用户问题两大天秤,不会一昧地倒向一侧。

下一篇我会继续分享 OKR 在产品团队的应用上的优缺点,并且分享我和团队合作制定 OKR 的流程。

就聊这么多。

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

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

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

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