Best Practice of OKRs I——刘亚平：产品经理「更」需要 OKRs

写在前面的话

「听过很多道理，依然过不好这一生。」from 《后会无期》

「OKRs 是一个用来沟通目标和评估进度的工具」，过去一段时间，同大量团队的交流过程中反复提到这句话。但是，这句定性的关于 OKRs 的描述，在方法论层面虽然有足够的信息量，在操作层面则让很多没有相关经验的团队感到一头雾水，像开头那句来自《后会无期》的台词一样，熟记 OKRs 的定义和理论内容，与 KPI 驱动的管理方法的异同也了然于胸，这样就真的能够非常顺利的在团队中推行 OKRs 吗？「如果采用了 OKRs，那绩效管理怎么做？」，「我怎么知道到底 OKRs 对我的团队适用不适用？如何在团队里面落地？」，「能不能分享一些更具体的实例？」等等实际操作层面的问题则是大家更关心的。

所以，我们邀请了几位不同专业背景的资深人士，从他们独特的视角聊一聊关于 OKRs 在职能团队落地以及相关的 best practice 等方面的话题，整理成了这个「Best Practice of OKRs」系列。这些内容会在接下来几周时间里，陆续连载在这个专栏，欢迎大家持续关注。第一篇内容，来自刘亚平。亚平曾在腾讯、Google、Microsoft 等公司担任 Product Designer。加入豌豆荚后，历任 VP of Product and Design、CEO of Wandoujia Appstore，在产品战略规划领域有非常丰富的经验。一个资深的产品经理是如何理解 OKRs 的，我们一起来听听亚平怎么说。

我过去在豌豆荚工作的五年，自己动手写过不少于 30 次的 OKRs，类型覆盖了产品经理个人、产品团队和业务部门，修改和审批过超过 200 个个人和团队的 OKRs。应 InnoKit 创始人赵望野之邀，总结下我关于产品经理 OKRs 的经验。如果你还不了解什么是 OKRs，请阅读这个专栏的历史文章。

产品经理为什么「更」需要 OKRs？

一，产品经理处在研发的最上游

研发流程中，产品经理（产品需求）是处在流程的最上游的，也是万恶之源。一个产品最后失败了，往往追溯到最后发现，团队努力满足的不过是个伪需求。如果在需求阶段错了， 那么所有后续的努力都是扯淡。所以，产品经理没有正确的奋斗目标，危害性相比起更下游的环节中（例如视觉设计师盲目追求酷炫的动画）大得多。

二，多维度的产品竞争更需要做优先级取舍

在今天的互联网上，任何一个产品，都面临着全方位多维度的竞争。传统的「单点突破」只能给产品带来一时的竞争力，而要长治久安加宽护城河，需要在各个不同的方面都去做改善。如果要列出一个 dashboard 来衡量自己的产品的状态，我一分钟就可以列出 20 个指标来。关注很多指标，当然能更全面的看到产品的全貌，但是也意味着注意力极大的分散。而资源永远是有限的，作为产品经理，哪怕是 KPI 导向的，也得清楚列知道导向哪个 KPI 才行。

对比下来，OKRs 的作用在这样的状况下就体现非常明显了。OKRs 的建立，是一个强制的不断筛选真正重要的事情的过程。既然你不可能把 20 个 KPI 都写进 OKRs，那么总要有个取舍吧？取舍的过程，必然是要去思考对于当前的产品来说什么是最重要的。

产品经理怎么建立合理的 OKRs？

以下方法是我自己常用的，供参考。

一，讲个好故事

亚马逊的产品立项时，都要先模拟写一份新闻稿，来描述产品发布的时候行业和用户会怎么描述，由此来倒推产品的差异点和策略。这个道理可以直接复用到 OKRs 上，作为一个产品经理，想（y）象（y）下，你的产品成功的时候，应该是什么的景象？如果你能清楚的生动的描述出产品成功时的样子，而不只是用「有多少万用户」来撑场面，你就可以写出一份优秀的 OKRs。

这个 yy 的结果一方面它能帮助我节省无数的沟通时间，要知道，讲故事永远比说数字来得更直观更容易被团队听懂，省去了很多口舌之劳。另外，它能在实际执行过程中不断提醒自己回顾下，起到纠偏的作用。最后，这个 yy 是我觉得最接近产品的「初心」的东西，当你觉得时间太紧压力太大老板太不讲道理同事太不理解你要坚持不下去了的时候，它时不时的会给你一点鸡血。毕竟，人总是要为自己吹过的牛逼奋斗。

二，用产品的形容词作为 Objective

这一点和前面一点是息息相关的，一个产品在市场竞争中获得成功，必然要有自己独特的优势。这个优势在市场初期还有可能是功能上的差异（例如你提供了在线叫车而对手没有，或者是压根没有对手，也就是 Kano 产品质量模型里面的 Attractive Quality），但是在市场充分竞争的阶段，不论你的 PR 稿怎么写，你在用户的认知里，往往就是用一个形容词来描述你，XX 的 YY，做得好的话就是最 XX 的 YY。其中 YY 是你的产品品类，XX 是你的形容词。例如最公平公正的搜索引擎（百度），最安全的浏览器（360）等等。用户接受了这个形容词， 就意味着你在用户认知里有一席之地，当他关心这个形容词时，你就是他的默认选择，你就能获得稳定的用户口碑和自然流量。

简单的列几个误区：

• 对用户不重要的形容词：「快」对于外卖来说，显然是最重要的，而对于购买 3C 产品来说，显然是 nice to have 的，远远不如便宜重要。想象下你的产品在什么形容词上做到极致，形成是量级的差距，就能够让用户蜂拥而来，最终碾压竞品？这个形容词就是你在找的东西。
  

• 贪心：你对用户说我的产品有 387 个优势，最后的结果多半是什么都记不住。「多快好省」显然是个宇宙内都行之有效的形容词，放在一个具体的产品上其实没有什么意义。

• 选错产品品类：用户是会在一个产品品类内比较的，所以品类选错了风险非常大。你明明是个浏览器，要把自己定位成新闻资讯引擎，那就意味着浏览器的一切优势对用户来说价值为零，以己之短攻敌之长，胜算会小很多。

• 创造产品品类：用户是很懒的，所以面对理解不了的产品品类，用户的应对一般是...不去理解。所以自己创造产品品类就像在玩火，除非你有非常大的优势来定义标准，例如 Tesla 之于「电动汽车」，iPhone 之于「智能手机」，否则，在用户眼里你可能什么都不是。

• 经常改变形容词：产品迭代可以很快，可是用户形成认知却很慢。经常换形容词的问题在于，之前的印象还没有固化，要接受新的等于一切要从零开始，本质上，这是在用自己的资源左右互搏。所以一旦选定形容词，接下来一两年之内应该是固定不变的。

三，保持 O，经常更新 KR

如果你已经为你的产品准备了一个好的故事，并且清楚的定义了产品的形容词，那么下一步自然是具体怎么达到了，这就要进入了 KR 阶段。

在 Obejctive 不变的前提下，KR 在不同阶段可以是完全不一样的。最简单的例子，「在线高清视频」的「高清」在五年前和今天是完全不同的概念。市场变化很快，每隔一段时间重新思考下，到底用什么样的 Key Results 来支撑 Obejctive（即使 Obejctive 完全没变过），也是一件很有帮助的事情。

另外一个经常改变 KR 的原因是，每次改进产品的一个细分领域，圈定一小块出来做重点投入，把它做到能让用户惊喜的程度，也是我个人很推荐的方法。举个例子，如果目标是做一个最「全」的应用商店，那么每次改进一个门类，如果你能在一个季度里做到海外的游戏和应用收录很全，就已经能获得一批死忠用户了。

常见的注意事项

最后，总结几个常见的对 OKRs 理解容易出现失误的地方。

• O 在各个团队不能保持统一：经常会看到同一个项目团队内各个职能大家写的 O 就各自不一样了，这样子各个团队会产生自己独立的小目标，而不是在一个大目标的不同方面努力。我的推荐是 O 应该在各个团队保持统一，例如「最全的应用商店」，工程团队可以 focus 在高效自动化抓取更多内容上，而产品可以考虑建立 UGC 机制来实现，Product Marketing 则可以在让用户感受到「全」这一点上持续发力。

• KR 必须是数字：虽然说我们非常提倡 Key Results 清晰可衡量，但是也不意味着一定是数字。「设计一个团队每个人都说好的新版 Quorum」在我看来，是一个很不错的 KR，只要你的读者对某一条 KR 的理解不会产生歧义，就不一定非得用数字。

题图来自：https://www.flickr.com/photos/jfleming701/4452629067/in/photostream/

这是一只严肃脸的产品汪