06 OKR大咖说：产品技术部门的OKR从何而来
From 黄勇：
每家公司都有一套自己的管理和协作方式，每位领导者都有一套自己的实施心经。为了让你能够更加全面地了解目前国内外互联网公司（包括创业公司）的实施流程和落地标准等内容，更多元化地了解各位大咖对 OKR 的想法，我和极客时间团队一起为你策划了“OKR 大咖说”栏目。在这个栏目中，我会邀请不同公司的大咖来从不同的角度为你分享他们的实施心经。
今天邀请到的是任向晖老师，他是中国最早实施OKR的企业家之一，专注于企业协作平台的设计和开发，同时关注先进的协作理念与工具。他已有十多年的创业经历，先后创办索易、梅花网、明道云，另外著有《高绩效团队的三个秘密》和《OKR实践指南》。
你好，我是任向晖，明道云创始人。我本人很早就在企业内践行OKR管理方法。作为一家产品技术型公司，我发现一般意义上的OKR目标分解会给产品技术Leader带来一些困扰，我们自己的实践中也有相关的教训。因此，我撰写了这篇文章，希望给同行们一些有益的启发。
去年，受极客邦邀请，我撰写了一篇《产品技术团队OKR使用法则》。在文中，我表达了产品技术团队能够进行有意义目标管理的先决条件：部门应该对产品的设计、开发和交付的整个过程负责，具有相当程度的主控能力；部门不是围绕客户项目展开工作的开发服务性团队，而是要围绕自己所拥有的产品和项目展开工作；公司的成败很大程度上取决于产品本身的特性和表现，对销售市场环节的依赖度有限。
简单说，它必须是一个产品型公司的技术团队，才能从 OKR 工作法中获益。而外包开发型团队的目标管理直接受制于客户合同，基本上可以概括为交付目标，它理想的管理手段就是瀑布式项目管理，而基本不需要 OKR 方法。
坦率地说，去年这篇文章中我的观点还是比较中庸的，迎合了一些大企业实施 OKR 过程中目标层层分解的要求。产品技术部门往往没有机会站在公司角度直接识别组织的关键目标，而是被给予一个更高等级的目标后，依据这个目标来分解自己的部门目标。
这个实践，给产品技术团队带来很大的困扰，他们面对含糊和概括性的企业目标，以及被约束的部门职责范围时，茫然不知从何着手，建立有意义的部门 OKR 就已经有所阻碍，更不要说去富有成效地执行了。
因此，我再来写这篇文章时，意图用更鲜明的观点，来更直接地说明 OKR 工作法的实质，以及它对产品技术管理者意味着什么。
产品型公司落地OKR的一些思考
概括来说，产品型公司的 CTO、技术 VP 等，应该就是企业 OKR 工作法的主要设定和执行者，他们从来不需要，也不应该依据另外一个层级的目标进行分解，而是应该依据企业长期使命和竞争处境，直接定义企业短期目标。
然而，这些被识别出来的短期目标，无论是不是属于同一个技术问题，都和产品技术团队息息相关。因此，CTO 应该和 CEO 及其他管理伙伴一起磋商企业的 OKR，而不是只对技术工作相关的 OKR 负责。
接下来，我来说清楚为什么，以及产品技术领导者应该怎样去做。
为什么产品技术团队不能从企业目标中进行分解？
产品型公司（无论软硬件，还是互联网服务），它的企业发展阶段几乎总是按照一个模型在发生：产品原型- 早期用户发展- 基本验证- 产品市场适配- 增长模式确定- 规模化成长。
图1 产品型企业发展模型
不过，只有少数企业足够幸运，能够很快跑完整个过程，进入快速增长阶段，即最后的规模化成长阶段，但大部分企业并不能顺利实现这“六连跳”，需要磕磕碰碰很多年，甚至很多都走不过第二关。
然而，成功的概率低，并不代表创业团队会悲观，相反，大多数团队似乎都对迈入用户发展和规模化成长这两个阶段，表现得极为乐观，不信你看，很多企业的 OKR 一写出来就是“获得X万客户数量，增长Y万销售金额，拓展 Z 个渠道”。而落到产品技术部门，却常常就是一些版本交付、特性开发、缺陷消除这样的目标。
这样的目标识别，大多数人都可以使用OKR 方法做到，但几乎起不到任何聚焦关键问题的作用。理论上，从公司经营目标分解出来的各个职能目标，能够彼此关联，但因为本位主义和思维局限，它所提倡的“上下同欲”则往往显得没有那么真诚。
至此，产品型公司的发展规律告诉我们，企业往往不是依赖销售目标去牵引，而是通过产品技术竞争力去推动的。而我们识别目标，无非是为了识别增长的原动力、自变量，而不是反反复复去鉴别哪个结果指标对自己有意义。用户数量、客户数量、销售收入和客户留存等，都是高价值的结果，它们本身并不会自动变化。
所以，我强烈建议：产品型公司的 OKR 目标识别，可以默认地从产品技术角度出发，心无旁骛地聚焦原动力问题，而不用担心会在营销、销售等职能上缺乏目标指引，其实这些职能从来不缺清晰和有诱惑力的目标。
不过我这么说，并没有想贬低业务团队价值的意思。因为产品技术要解决的问题，以及产品发展方向的确立，都必然离不开业务团队的信息输入。而且，在产品市场适配度目标达成之后，建立增长模式和快速发展业务，也都离不开有经验的业务和运营人才，他们会是企业发展的“乘数”。
但是，在理想的市场需求适配度目标达成之前，若将企业聚焦的目标错误地设定在非产品技术环节上，那往往会是非常容易令你感到懊悔的事。
产品技术领导者在不同阶段的目标逻辑是什么？
如果我前面的建议打动了你，那么作为 CTO，应该怎样理解企业在不同阶段的目标选择呢？
首先，在初创阶段（从产品原型到基本验证），由于企业目标一般集中在验证产品和商业计划的可行性上，因此技术负责人在厘清怎么做好产品之前，要先对企业希望达成的商业目标、目标客户的选择，以及要解决的客户问题上，做到心知肚明。
在明确这个上下文的基础上，企业早期目标通常集中体现在以下几个方面上：产品试制成功、获取早期用户、验证产品性能（满足客户需求的程度）、用户留存能力判断。
既然初创这个阶段的终点是商业设想的验证，那也就一定程度上意味着并非要制定遥不可及的目标，过高的目标不仅毫无必要，而且还会给市场验证环节带来干扰。
虽然，我们在制定目标的时候总希望有一个好的结果，但是如果我们的设想的确不符合客户期待的需求，那么盲目和机械地提高这个指标并无意义。
我曾经目睹了一个团队在连续三个月里，无法将次月留存率提高到20%以后，最终坚决摒弃了整个产品的场景。如果你了解游戏产品市场的运作规律，你就会知道验证就是验证，绝对不要把验证环节做成盲目坚持。
如果进行完了初步的市场验证，那么很可能团队还要面临真正的产品市场适配考验。
尤其是 B2B 类产品，早期用户与主流用户的差异巨大，初期的验证成功并不能代表未来的普通用户都能够对产品服务满意，更加不要说积极帮助你来传播你的品牌了。
在这个阶段，有意义的企业OKR 集中在这五个方面上：
- 识别标杆客户；
- 提升销售转化率；
- 完善关键产品特性；
- 消除量产缺陷；
- 偿还技术债务。
甚至可能因为产品定位的调整与修正，而促使产品重构目标。
你可以看出，这个阶段产品技术团队的压力是非常大的，客户数量不仅在增长，而且在逐渐多样化，业务团队也开始增长，内外部用户提出的产品改进意见越来越多，而产品研发的资源几乎是捉襟见肘的。这关乎企业的命运，更是企业的关键时刻，能够决定命运的是企业在这个阶段所能够形成的修正决策，而这个决策的成败几乎就是取决于产品技术决策了。
到底我们应该聚焦到发展哪个细分市场，从而决定产品重构的方向和原则呢？又应该用何种标准来要求和衡量产品质量呢？同时，我们应该放弃哪些选择，从而将资源聚焦在可能让我们快速发展的机会上呢？
此刻，我们可以想象，如果企业 OKR 不是基于产品技术决断，而是业务目标牵引，那企业能不能走上成功路径，就只有天知道了。
在此之前，我注意到很多企业的 OKR 目标都只能停留在业务绩效目标上，而且都容易过度乐观，那么在这种情况下，团队很难逃脱目标不聚焦、不断做加法，最终实际绩效大幅低于期望的噩梦。
不过，如果团队足够幸运，成功地达成了 PMF（Product / Market Fit，产品和市场的匹配度），此刻团队的感受是十分美妙的。业务水平和能力的提升，能够感觉到有强大的拉动力，客户自己会找上门来，成交转化效率会很理想，而且留存和扩散都会比较顺利。这时，团队就是高速成长企业的候选者了。
但是，也有很多企业，在这个时刻由于各种各样的原因而错失机会，从而昙花一现。
这个阶段的企业目标看似应该是业务部门来主导了，但我认为：产品技术继续参与，依然对企业有巨大的好处。因为企业把握住快速增长机会的关键点通常在增长模式的合理选择，以及为这个增长模式打造的运营系统。
假设 30 人的业务团队把企业带入到了PMF，那么接下来最首要的目标就是 300 人能否驱动至少 10 倍的业绩成长。当业务系统扩张、销售组织膨胀、渠道伙伴增加的时候，绩效能否等比增长？如果我们不在管理目标上主动寻求改善，那么结果显然就是边际效益递减，更多的投入开始产生较平均水平更低的收益。
所以，CTO 在这个阶段可以着眼于这五个方面：打造中后台系统、提供数据分析能力、赋能业务团队、提升运营效率。
然而，CEO 的首要责任就是要坚决地将资源投入到最佳的增长因子上，这些因子：
- 可能是线下团队，它们依赖于高效率自动化的运营系统；
- 也可能是广告投资，他们依赖于营销效果分析和优化系统；
- 还可能是渠道和伙伴关系，他们依赖于一个无缝的赋能平台，让合作伙伴可以拥有和自己一样的资源和能力。
遇到难以量化的OKR怎么办？
在上面的内容中，我提供了产品型公司在不同阶段识别有意义目标的逻辑。但是在完善目标管理的可量化性方面，产品技术领域的确面临很大的难题。
比如，如果我的目标是提供营销效果分析平台来提高 ROI（投资回报率），那么 KR 是非常容易定义的，它一般和广告投入的 ROI 值有关。但是，如果面临在 PMF 之前重构产品的目标，怎样才能找到一个量化指标呢？
首先，解决上面这一问题的基本思路，还是要将每个产品技术目标和客户市场联系起来。如果将产品重构作为目标，那么需要追问这个重构主要是为了更好地满足哪一类型的客户的？在这个细分市场证明产品重构价值的最佳指标是什么呢？可能客户转化率和留存率都是。
不过，由于不同的产品在不同的阶段、在不同的细分市场可能都不一样，因此我觉得不同企业可以有更恰当的选择。
其次，如果短期内（比如，一个季度）来不及兑现客户转化和留存这样的外部结果，那我们就不必强迫自己量化，因为寻找一些过程性的量化指标不见得对实现目标有任何的帮助。
我们可以用颗粒度更细的里程碑尽力提升交付速率，但它并不是问题的关键。如果团队没法说服自己，就坦诚地写一个 KR：“我们暂时不知道”，或者“暂时不能衡量”。
最后不得不说，OKR 工作法，它的实际聚焦价值、执行的自律度，以及团队对它的坦诚程度，要比它的形式要求更重要。
总结
产品型公司的发展规律告诉我们，企业往往并不是依赖销售目标去牵引，而是通过产品技术竞争力去推动的。
在产品型公司从产品原型 - 早期用户发展 - 基本验证 - 产品市场适配 - 增长模式确定 - 规模化成长的全过程中，产品技术负责人可以根据不同阶段的内在逻辑找到那些有意义的目标，这不仅可以作为本部门的OKR，也是整个公司应该全力以赴要聚焦的目标。
思考时间
看了此文，你觉得您所在的企业今天在发展路径上的哪个阶段？在这个阶段，围绕产品竞争力和市场适配度，是否还有值得聚焦解决的问题？如果市场适配度已经足够高，产品技术部门应该如何帮助企业做增长？
我的分享就到这里，如果今天的内容让你有所收获，或有新的启发，欢迎你在留言区留言，与我分享你的故事，也欢迎你把它分享给你的朋友，一起沟通探讨。
- Jxin 👍（15） 💬（2）
1.有个感觉很牛逼又理解不来的点：不能靠业务目标做牵引，要靠技术竞争力做推动。我觉得这句话含糊，理解不来。首先，所有技术实现都是为了产生业务价值（直接或间接），那么业务目标作为技术选择的依据有什么问题？再来说技术竞争力，如果技术能成为竞争力，那么意味着垄断和技术壁垒的存在，这种实在有点难，而且一旦实现只要是市场需求的产品，稳步增长不带用脑。当下大部分的现有产品的竞争力个人认为是具有积累效应的业务带来的难以替换。（微信很牛逼，但要实现一个微信这样的聊天工具不难，难的是9亿现有用户，这也奠定了其在国内难以取代的地位）。新产品的竞争力一般也聚焦在新领域的突破，可以理解为时间纬度上的技术壁垒，而如果新产品没能在这份时间优势里落地自己的增长模式，或则说积累策略，那么当其他人也打破壁垒时，这个竞争优势将当然无存。而在中国，山寨大国，除非非常巨大的技术差距，不然想模仿一个产品的技术只是时间多少的问题。所以说，个人不是很看好以技术本身作为核心竞争力，因为你能做别人也能做，而且随着时间推移优势是下降趋势的。而以具有积累效应的业务作为核心竞争力，初步必然是带来不了多大价值，但随着时间推移它的竞争力是增长趋势的。所以，如果产品是短期一锤子买卖，那么快速落地投入市场，边际效益低于底线就弃了，如果产品有长期，稳步积累的价值，就在市场验证成功后，重心落地增长模式，积累往后在竞品中的核心竞争力。 2.老师这个文章核心有两个点，增长理论的抓大放小，选对增长点和经济学的合理分配资源，着力于总效益最大（边际效益）。 3.小人物一枚，但公司目前的情况让我很担忧。结合上述，我认为我们公司当前处于市场验证成功，增长模式落地这里。北极星指标我觉得也定的没问题，问题在拆解下来的落地okr的o上。大包大揽全面尝试，一步到位投入巨大。广泛撒网，偏离北极星指标的增长模式确立，一步到位，财大气粗缺少mvp概念，没有产品反馈调整的精益理念。当然，大佬们有大佬们的考量，我并不认为他们会不懂这些。只是自己的纬度还看不到大佬们关注的东西。仅以细枝末节妄下定论。
2019-07-14 - 西西弗与卡夫卡 👍（8） 💬（0）
OKR中的K提醒我们，定义的是Key结果，不是任意的结果，更不是看起来好定义（好定义不是指结果中的数字好达成）的结果。是否Key来自于企业对自身使命、当前所处阶段及核心目标和核心能力等的思考认知。 就像黄老师前面提及的，KR是路标。不指向目标的标识只是风景，主要用途是分散自己的注意力，耗散资源。 见过一些团队，在模式验证阶段，花很多精力研磨产品交互，技术指标弄得很好。创新是很不容易的，大概率是试错。如果没想清楚验证什么，一旦指标不好用户寥寥，团队就容易陷入互相质疑，在前进还是止损上产生分歧。验证阶段团队给资源投入设立退出机制，或许是个可行的方法。
2019-07-10 - 麻瓜编码师 👍（4） 💬（0）
其实如果产品型公司的企业成长过程并不是很明确的情况下，很容易产品技术团队跟着大家跑，只能尽全力完成任务，很难和公司整体的o呼应。
2019-07-10 - 行者 👍（4） 💬（0）
谢谢老师分享，在很多团队里，产品技术团队沦为任务的执行者，按照领导的要求做事。丧失自主权，每天很忙，但因为不聚焦，没有成果。 这样的团队，能否成功只有天知道。
2019-07-10 - 果然如此 👍（2） 💬（0）
很巧本课程提到了增长，而我在学的另外一个叫增长的课程也提到了OKR，两个课程可以结合
2019-07-12 - w*waiting 👍（1） 💬（0）
外包公司，OKR我感觉终极目标是客户满意，做好服务。 阶段性目标，就是商务（时间角度），技术（系统性能），售后（响应速度）互相配合跟客户达成共识。
2019-07-16 - KK_TTN 👍（1） 💬（0）
大咖说很棒，不同的角色、经历都可以给OKR实战提供不同的视角
2019-07-13 - Ethan New 👍（0） 💬（0）
说的有点大，可能是我水平还太次，暂时理解不了，以后回头再看看
2022-09-29 - 牛牛肥 👍（0） 💬（0）
作者是提出了不同阶段应该用不同的方法应对，个人感觉是第一步是能结合意愿和现实，提出正确、有效的问题。而OKR可以作为意愿和现实的平衡支撑点。
2021-08-13 - 余音（余晓玲） 👍（0） 💬（0）
太赞了，觉得产品、技术、运营管理团队的小伙伴应该要反复琢磨这一篇
2020-03-19 - 李双 👍（0） 💬（1）
说的挺大的
2019-09-03