okr复盘所以模板(产品复盘的5点所以)
导语:本文是产品踩坑所以,作者复盘了之前做过的三个产品项目,结合实际项目经历,所以一些方法论和经验,一方面是自己的沉淀,一方面也希望带给读者一些启发和帮助,与大家分享。
刚从某互联网公司离职,在公司做了3个项目,都是h5小手游,休闲游戏 ,内嵌在宿主APP中。其中一个项目被业务方魔改,畸形上线,一个项目成功推至全量上线,还有一个项目离职时还在灰度测试中,生死未卜,我将结合实际的项目经历,所以一下经验和教训,主要以下几点:
01 产品目标要合适
公司采用的是OKR制度,从上至下依次确定目标和行动,当时制定的O(object)是带动宿主APP新增次留提高xx个百分点,后来实践过程中才发现这个O并不合适,也导致了后面的一系列恶性环。
为什么不合适?以数据来说明:我们的h5在APP中的**率只有10%,这意味着如果我们的目标是提升100个人的留存,那么我们的产品只能影响其中10个人,剩下90个人的一点风吹草动可能都会将我们产品输出的价值给淹没。
另一方面:能在APP中察觉到h5入口,并且点击进入已经是一个活跃度门槛了,能够进入h5的用户的活跃度已经高于普通用户,这在留存数据上有直接体现,进入h5的用户的新增次留已经接近80%(大盘60%),能够提升的空间很小。
我们只能通过提升这些10%本就高留存用户的留存来尝试撬动整体大盘(100%用户)的留存,难度相当大。公司的文化是object一旦确定,就像立下了军令状,没有回转的异地,老板就只看这个O,所有的成果都必须指向新增次留这个目标,其他指标的提升没有意义。
作为产品只能破釜沉舟,all in OKR , 不然OKR没完成的下场,轻则扣绩效,重则要么产品死,要么产品经理死。
所以:制定产品目标(或者说KPI/OKR)前应充分考虑可行性,不要急于求成,好的方法是在公司内部打探类似产品的数据指标,或者公司其他产品经理的经验教训,综合考虑,不要给自己挖坑。
02 产品需求要以产品目标为导向
互联网公司强调高效,迭代节奏非常快,如何管理需求,把握好迭代节奏,是产品经理的硬功夫。
尤其在产品初期,可以做的事情太多了,除了产品经理自己思考的需求,市场上一大堆竞品可以抄,老板会有想法,开发也会有想法,甚至手下的实习生也会积极出谋划策。
产品经理需要在杂乱的信息中确定什么需求是有价值的,什么先做,什么后做,什么不做,判断时应该明确想要达成的阶段性目标是什么,最终目标是什么,这个需求对于达成目标有什么帮助,以此评估某个需求在此时此刻的价值。
产品经理在决策时,不能凭心情拍板,自己喜欢怎么做就怎么做,这样是对产品,对公司不负责的表现。完成既定的产品目标是产品经理的使命,在管理,规划和决策时应该以产品目标为导向。
在这个方面我们团队踩坑不少,以我们的项目为例,我们的目标是帮助APP提升新增次留,接手时产品精简,有两个需求要迫切处理,一个是新手引导的优化,一个是UI的改良,资源有限只能一个一个做,当时做出的决策时先改UI, 因为觉得改为UI后会焕然一新,界面变得更漂亮,但后来我们复盘时觉得还是新手引导能够直接作用新增用户,对于提升新增次留来讲,更加犀利,带来的效果也更好一些,而且改UI的时候还遇到一个坑,后面再说。
还有一个更坑的例子,在其中一个产品的新增次留迟迟不出效果时,临近ddl,我们想出的办法是给用户多送一些“游戏币”,牺牲一些游戏的盈利希望能换取用户更好的游戏体验,以此来冲刺一波留存。
这个逻辑和方向是对的,但是效果却不明显,直到后面我们发现我们忽略了一点,在送“游戏币”时我们没有将新用户和老用户分开,导致发出去的“游戏币”大多落在了更活跃的老用户中,新用户能够获得的“游戏币”与预期相比大大减少。
所以下来就是产品需求或多或少都要和产品目标挂钩,这样才能高效的走在正确的路上。
03 时刻保持用户思维
互联网常说用户思维,那么用户思维究竟是什么。当然你可以百度,我自己的体会所谓的用户思维就是把用户放心上,去感受用户的情绪,去尝试贴近用户,了解用户,为用户服务。
你必须明确你的产品是要为用户服务的,而不是去压榨用户,欺骗用户,那样你的产品不会长久。即使产品不得不为了商业化或其他因素而短暂牺牲一些用户体验,你也必须思考产品是否能提供其他价值,来平衡用户体验的缺失。
产品在做需求时切忌不要把自己当成用户,以为自己觉得好就是好,这样的错误很容易犯。之前我们在改一款产品的UI时,改为团队都觉得好,我也觉得变漂亮了!然而我们觉得的“漂亮”并不等于用户觉得的“漂亮”,当时产品的用户大多是中老年用户,他们喜欢什么?喜欢的是大红大紫,字要打,按钮要大,他们的审美能和我们年轻的团队一样吗?
做需求一定要站在用户的角度去考虑,充分利用公司的资源去尝试分析他们的用户画像,定期做用户调研,不断增强对用户的了解,能否了解用户,是产品的命门!
04 数据分析的正确思路:先业务,后逻辑,最后数据
数据分析这个词已经烂大街了,究竟应该怎么做数据分析?
数据分析第一步:找准业务切口
数据分析的目的是什么? 解决问题,指导业务! 不能够指导业务的数据分析是没有意义的?这也要求数据分析师们每做一份数据分析报告,都要思考你的报告指导的to do是什么?
另外一点,对于新手数据分析师来说,一定要注意细节,切忌“大”和“空”,又大又空的结论是不好落地去做的,不如去以数据为支撑去解决那些具体而实际的问题来得有价值。
记得我第一个提的需求是改变道具的摆列顺序,我从数据中发现摆在第一个道具的使用率最低,用户获取道具获得的成本也最大,把它放在第一个是不是符合用户的心理预期?很明显我老大在设计产品的时候并没有考虑的那么细,但是我利用数据加上合理的逻辑,让我老大觉得这个需求是好的,是能够优化产品,提升用户体验的,哪怕很细小,但是他很实在不是吗?
数据分析第一步要找业务切口,寻找业务切口的能力决定了数据分析师的核心价值,优秀的数据分析师往往能切得又准又狠!
以我的经验和思考,低级数据分析师的业务切口往往是去找原因;中级的数据分析师我觉得是能够去所以和复盘一个完整项目的;高级的数据分析师有能力在产品经理束手无策,产品看似僵死的时候,能够拨开云雾见日出,为产品指明方向。低级的数据分析师依靠逻辑,高级的数据分析师靠的是行业经验,或者说,所谓的嗅觉。
数据为后,逻辑先行
当找到了业务切口时,不要着急去拉数据,数据为后,逻辑先行。
思考你的数据分析的逻辑是什么?对于产品经理或一些业务型的数据分析师来说,最常用的数据分析方法不过是逻辑的推理,并不需要一些时下热门的机器学习的算法,就连普通的统计学方法也可能很难用到,这不是说逻辑推理不好,相反,逻辑推理效率高,站得稳,并且你弄得懂,你的团队和老板也听得懂。
关键是得把逻辑讲好了,不能有漏洞。一旦逻辑上出现漏洞,一切结果都站不住脚,拉再多数据也白搭。所以在实际动手做数据前,一定要先把逻辑想清楚了,捋顺了。
同样举个例子,我老大有一天想做个数据分析,然后让我拉各种数据,又做了表格,等到日会上汇报时,所有的一切被老板一句话怼回去:我们要做的不是提升新增用户的数据吗,那你分析全部用户的数据干什么? 现实就是那么残酷,所以想清楚了再拉数据!
以我的理解,产品经理未来对能力的要求中,数据分析将从加分项变成必须项,产品经理是最适合做数据分析的人,因为他最懂自己的产品。所以别总是原型图了,SQL也要学起来,相信我,会SQL拉数据的产品经理工作效率会大增,因为他再也不用追着数据分析师要数据了!
05 正确解读AB实验
AB实验的重要性就不多说了,除非出现新的更好的统计方法,AB实验永远会是大数据时代下的焦点。我相信大多数产品都知道AB实验是什么,但其后一些人可能并不会正确理解和灵活运用AB实验,读者可以尝试回答以下一些问题:
实验显著意味着什么?不显著又意味着什么?
空转实验是什么?一定要做空转实验吗?
当确定了产品目标,例如留存提高1%,那么至少需要多少流量跑多少天?
实验跑了很多天,一会儿高一会儿低,数据一直不显著怎么办,还要继续吗?
实验数据很难看,但是实验还不显著,要停掉实验吗,怎么和老板解释?
实验数据很漂亮,但是实验还不显著,能向老板汇报作为结果吗?
明明是一个提升性的需求,实验数据却变差,怎么办?
其实理解了AB实验后的统计学原理,这些问题都不难,我将近期发表一篇文章专攻AB实验的统计学原理,或许会帮助大家更好的理解,有兴趣的可以关注。
最后,我想做产品的大家都是有理想的吧,愿大家每一岁都奔赴在自己的热爱里!
PS:本人目前统计专业研究生在读,第一次尝试发文章,非常欢迎一些志在互联网发展的同学们来一起讨论,一起进步,有想交个朋友的可以私信我哈哈哈。
相关文章:
相关推荐: