CategoryResourceRepost/极客时间专栏/黄勇的OKR实战笔记/OKR快速入门/06 | OKR大咖说:产品技术部门的OKR从何而来.md
louzefeng d3828a7aee mod
2024-07-11 05:50:32 +00:00

128 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<audio id="audio" title="06 | OKR大咖说产品技术部门的OKR从何而来" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a5/24/a58b1f0660d82f4849585ba169f23724.mp3"></audio>
>
<p>From 黄勇:<br><br>
每家公司都有一套自己的管理和协作方式,每位领导者都有一套自己的实施心经。为了让你能够更加全面地了解目前国内外互联网公司(包括创业公司)的实施流程和落地标准等内容,更多元化地了解各位大咖对 OKR 的想法我和极客时间团队一起为你策划了“OKR 大咖说”栏目。在这个栏目中,我会邀请不同公司的大咖来从不同的角度为你分享他们的实施心经。<br><br>
今天邀请到的是任向晖老师他是中国最早实施OKR的企业家之一专注于企业协作平台的设计和开发同时关注先进的协作理念与工具。他已有十多年的创业经历先后创办索易、梅花网、明道云另外著有《高绩效团队的三个秘密》和《OKR实践指南》。</p>
你好我是任向晖明道云创始人。我本人很早就在企业内践行OKR管理方法。作为一家产品技术型公司我发现一般意义上的OKR目标分解会给产品技术Leader带来一些困扰我们自己的实践中也有相关的教训。因此我撰写了这篇文章希望给同行们一些有益的启发。
去年,受极客邦邀请,我撰写了一篇[《产品技术团队OKR使用法则》](https://time.geekbang.org/column/article/7991)。在文中,我表达了产品技术团队能够进行有意义目标管理的先决条件:**部门应该对产品的设计、开发和交付的整个过程负责,具有相当程度的主控能力;部门不是围绕客户项目展开工作的开发服务性团队,而是要围绕自己所拥有的产品和项目展开工作;公司的成败很大程度上取决于产品本身的特性和表现,对销售市场环节的依赖度有限。**
简单说,它必须是一个产品型公司的技术团队,才能从 OKR 工作法中获益。而外包开发型团队的目标管理直接受制于客户合同,基本上可以概括为交付目标,它理想的管理手段就是瀑布式项目管理,而基本不需要 OKR 方法。
坦率地说,去年这篇文章中我的观点还是比较中庸的,迎合了一些大企业实施 OKR 过程中目标层层分解的要求。产品技术部门往往没有机会站在公司角度直接识别组织的关键目标,而是被给予一个更高等级的目标后,依据这个目标来分解自己的部门目标。
这个实践,给产品技术团队带来很大的困扰,他们面对含糊和概括性的企业目标,以及被约束的部门职责范围时,茫然不知从何着手,建立有意义的部门 OKR 就已经有所阻碍,更不要说去富有成效地执行了。
因此,我再来写这篇文章时,意图用更鲜明的观点,来更直接地说明 OKR 工作法的实质,以及它对产品技术管理者意味着什么。
## 产品型公司落地OKR的一些思考
概括来说,**产品型公司的 CTO、技术 VP 等,应该就是企业 OKR 工作法的主要设定和执行者**,他们从来不需要,也不应该依据另外一个层级的目标进行分解,而是应该依据企业长期使命和竞争处境,直接定义企业短期目标。
然而这些被识别出来的短期目标无论是不是属于同一个技术问题都和产品技术团队息息相关。因此CTO 应该和 CEO 及其他管理伙伴一起磋商企业的 OKR而不是只对技术工作相关的 OKR 负责。
接下来,我来说清楚为什么,以及产品技术领导者应该怎样去做。
## 为什么产品技术团队不能从企业目标中进行分解?
产品型公司(无论软硬件,还是互联网服务),它的企业发展阶段几乎总是按照一个模型在发生:产品原型- 早期用户发展- 基本验证- 产品市场适配- 增长模式确定- 规模化成长。
<img src="https://static001.geekbang.org/resource/image/0e/74/0e34d56512301c1205eff4612812bb74.png" alt="">
不过,只有少数企业足够幸运,能够很快跑完整个过程,进入快速增长阶段,即最后的规模化成长阶段,但大部分企业并不能顺利实现这“六连跳”,需要磕磕碰碰很多年,甚至很多都走不过第二关。
然而,成功的概率低,并不代表创业团队会悲观,相反,大多数团队似乎都对迈入用户发展和规模化成长这两个阶段,表现得极为乐观,不信你看,很多企业的 OKR 一写出来就是“获得X万客户数量增长Y万销售金额拓展 Z 个渠道”。而落到产品技术部门,却常常就是一些版本交付、特性开发、缺陷消除这样的目标。
这样的目标识别大多数人都可以使用OKR 方法做到,但几乎起不到任何聚焦关键问题的作用。理论上,从公司经营目标分解出来的各个职能目标,能够彼此关联,但因为本位主义和思维局限,它所提倡的“上下同欲”则往往显得没有那么真诚。
至此,产品型公司的发展规律告诉我们,**企业往往不是依赖销售目标去牵引,而是通过产品技术竞争力去推动的**。而我们识别目标,无非是为了识别增长的原动力、自变量,而不是反反复复去鉴别哪个结果指标对自己有意义。用户数量、客户数量、销售收入和客户留存等,都是高价值的结果,它们本身并不会自动变化。
所以,我强烈建议:产品型公司的 OKR 目标识别,可以默认地从产品技术角度出发,心无旁骛地聚焦原动力问题,而不用担心会在营销、销售等职能上缺乏目标指引,其实这些职能从来不缺清晰和有诱惑力的目标。
不过我这么说,并没有想贬低业务团队价值的意思。因为产品技术要解决的问题,以及产品发展方向的确立,都必然离不开业务团队的信息输入。而且,在产品市场适配度目标达成之后,建立增长模式和快速发展业务,也都离不开有经验的业务和运营人才,他们会是企业发展的“乘数”。
但是,在理想的市场需求适配度目标达成之前,若将企业聚焦的目标错误地设定在非产品技术环节上,那往往会是非常容易令你感到懊悔的事。
## 产品技术领导者在不同阶段的目标逻辑是什么?
如果我前面的建议打动了你,那么作为 CTO应该怎样理解企业在不同阶段的目标选择呢
首先,在初创阶段(从产品原型到基本验证),由于企业目标一般集中在验证产品和商业计划的可行性上,因此技术负责人在厘清怎么做好产品之前,要先对企业希望达成的商业目标、目标客户的选择,以及要解决的客户问题上,做到心知肚明。
在明确这个上下文的基础上,企业早期目标通常集中体现在以下几个方面上:产品试制成功、获取早期用户、验证产品性能(满足客户需求的程度)、用户留存能力判断。
既然初创这个阶段的终点是商业设想的验证,那也就一定程度上意味着并非要制定遥不可及的目标,过高的目标不仅毫无必要,而且还会给市场验证环节带来干扰。
虽然,我们在制定目标的时候总希望有一个好的结果,但是如果我们的设想的确不符合客户期待的需求,那么盲目和机械地提高这个指标并无意义。
我曾经目睹了一个团队在连续三个月里无法将次月留存率提高到20%以后,最终坚决摒弃了整个产品的场景。如果你了解游戏产品市场的运作规律,你就会知道验证就是验证,绝对不要把验证环节做成盲目坚持。
如果进行完了初步的市场验证,那么很可能团队还要面临真正的产品市场适配考验。
尤其是 B2B 类产品,早期用户与主流用户的差异巨大,初期的验证成功并不能代表未来的普通用户都能够对产品服务满意,更加不要说积极帮助你来传播你的品牌了。
在这个阶段有意义的企业OKR 集中在这五个方面上:
- 识别标杆客户;
- 提升销售转化率;
- 完善关键产品特性;
- 消除量产缺陷;
- 偿还技术债务。
甚至可能因为产品定位的调整与修正,而促使产品重构目标。
你可以看出,这个阶段产品技术团队的压力是非常大的,客户数量不仅在增长,而且在逐渐多样化,业务团队也开始增长,内外部用户提出的产品改进意见越来越多,而产品研发的资源几乎是捉襟见肘的。这关乎企业的命运,更是企业的关键时刻,能够决定命运的是企业在这个阶段所能够形成的修正决策,而这个决策的成败几乎就是取决于产品技术决策了。
到底我们应该聚焦到发展哪个细分市场,从而决定产品重构的方向和原则呢?又应该用何种标准来要求和衡量产品质量呢?同时,我们应该放弃哪些选择,从而将资源聚焦在可能让我们快速发展的机会上呢?
此刻,我们可以想象,如果企业 OKR 不是基于产品技术决断,而是业务目标牵引,那企业能不能走上成功路径,就只有天知道了。
在此之前,我注意到很多企业的 OKR 目标都只能停留在业务绩效目标上,而且都容易过度乐观,那么在这种情况下,团队很难逃脱目标不聚焦、不断做加法,最终实际绩效大幅低于期望的噩梦。
不过,如果团队足够幸运,成功地达成了 PMFProduct / Market Fit产品和市场的匹配度此刻团队的感受是十分美妙的。业务水平和能力的提升能够感觉到有强大的拉动力客户自己会找上门来成交转化效率会很理想而且留存和扩散都会比较顺利。这时团队就是高速成长企业的候选者了。
但是,也有很多企业,在这个时刻由于各种各样的原因而错失机会,从而昙花一现。
这个阶段的企业目标看似应该是业务部门来主导了,但我认为:产品技术继续参与,依然对企业有巨大的好处。因为**企业把握住快速增长机会的关键点通常在增长模式的合理选择,以及为这个增长模式打造的运营系统**。
假设 30 人的业务团队把企业带入到了PMF那么接下来最首要的目标就是 300 人能否驱动至少 10 倍的业绩成长。当业务系统扩张、销售组织膨胀、渠道伙伴增加的时候,绩效能否等比增长?如果我们不在管理目标上主动寻求改善,那么结果显然就是边际效益递减,更多的投入开始产生较平均水平更低的收益。
所以CTO 在这个阶段可以着眼于这五个方面:打造中后台系统、提供数据分析能力、赋能业务团队、提升运营效率。
然而CEO 的首要责任就是要坚决地将资源投入到最佳的增长因子上,这些因子:
- 可能是线下团队,它们依赖于高效率自动化的运营系统;
- 也可能是广告投资,他们依赖于营销效果分析和优化系统;
- 还可能是渠道和伙伴关系,他们依赖于一个无缝的赋能平台,让合作伙伴可以拥有和自己一样的资源和能力。
## 遇到难以量化的OKR怎么办
在上面的内容中,我提供了产品型公司在不同阶段识别有意义目标的逻辑。但是在完善目标管理的可量化性方面,产品技术领域的确面临很大的难题。
比如,如果我的目标是提供营销效果分析平台来提高 ROI投资回报率那么 KR 是非常容易定义的,它一般和广告投入的 ROI 值有关。但是,如果面临在 PMF 之前重构产品的目标,怎样才能找到一个量化指标呢?
首先,解决上面这一问题的基本思路,还是**要将每个产品技术目标和客户市场联系起来**。如果将产品重构作为目标,那么需要追问这个重构主要是为了更好地满足哪一类型的客户的?在这个细分市场证明产品重构价值的最佳指标是什么呢?可能客户转化率和留存率都是。
不过,由于不同的产品在不同的阶段、在不同的细分市场可能都不一样,因此我觉得不同企业可以有更恰当的选择。
其次,如果短期内(比如,一个季度)来不及兑现客户转化和留存这样的外部结果,那我们就不必强迫自己量化,因为**寻找一些过程性的量化指标不见得对实现目标有任何的帮助。**
我们可以用颗粒度更细的里程碑尽力提升交付速率,但它并不是问题的关键。如果团队没法说服自己,就坦诚地写一个 KR“我们暂时不知道”或者“暂时不能衡量”。
最后不得不说OKR 工作法,**它的实际聚焦价值、执行的自律度,以及团队对它的坦诚程度,要比它的形式要求更重要。**
## 总结
产品型公司的发展规律告诉我们,企业往往并不是依赖销售目标去牵引,而是通过产品技术竞争力去推动的。
在产品型公司从产品原型 - 早期用户发展 - 基本验证 - 产品市场适配 - 增长模式确定 - 规模化成长的全过程中产品技术负责人可以根据不同阶段的内在逻辑找到那些有意义的目标这不仅可以作为本部门的OKR也是整个公司应该全力以赴要聚焦的目标。
## 思考时间
看了此文,你觉得您所在的企业今天在发展路径上的哪个阶段?在这个阶段,围绕产品竞争力和市场适配度,是否还有值得聚焦解决的问题?如果市场适配度已经足够高,产品技术部门应该如何帮助企业做增长?
我的分享就到这里,如果今天的内容让你有所收获,或有新的启发,欢迎你在留言区留言,与我分享你的故事,也欢迎你把它分享给你的朋友,一起沟通探讨。