|产品复盘的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)前应充分考虑可行性，不要急于求成，好的方法是在公司内部打探类似产品的数据指标，或者公司其他产品经理的经验教训，综合考虑，不要给自己挖坑。
【|产品复盘的5点总结，纪念那些踩过的坑】 02 产品需求要以产品目标为导向
互联网公司强调高效，迭代节奏非常快，如何管理需求，把握好迭代节奏，是产品经理的硬功夫。
尤其在产品初期，可以做的事情太多了，除了产品经理自己思考的需求，市场上一大堆竞品可以抄，老板会有想法，开发也会有想法，甚至手下的实习生也会积极出谋划策。
产品经理需要在杂乱的信息中确定什么需求是有价值的，什么先做，什么后做，什么不做，判断时应该明确想要达成的阶段性目标是什么，最终目标是什么，这个需求对于达成目标有什么帮助，以此评估某个需求在此时此刻的价值。
产品经理在决策时，不能凭心情拍板，自己喜欢怎么做就怎么做，这样是对产品，对公司不负责的表现。完成既定的产品目标是产品经理的使命，在管理，规划和决策时应该以产品目标为导向。
在这个方面我们团队踩坑不少，以我们的项目为例，我们的目标是帮助APP提升新增次留，接手时产品精简，有两个需求要迫切处理，一个是新手引导的优化，一个是UI的改良，资源有限只能一个一个做，当时做出的决策时先改UI, 因为觉得改为UI后会焕然一新，界面变得更漂亮，但后来我们复盘时觉得还是新手引导能够直接作用新增用户，对于提升新增次留来讲，更加犀利，带来的效果也更好一些，而且改UI的时候还遇到一个坑，后面再说。
还有一个更坑的例子，在其中一个产品的新增次留迟迟不出效果时，临近ddl,我们想出的办法是给用户多送一些“游戏币” ，牺牲一些游戏的盈利希望能换取用户更好的游戏体验，以此来冲刺一波留存。
这个逻辑和方向是对的，但是效果却不明显，直到后面我们发现我们忽略了一点，在送“游戏币”时我们没有将新用户和老用户分开，导致发出去的“游戏币”大多落在了更活跃的老用户中，新用户能够获得的“游戏币”与预期相比大大减少。
总结下来就是产品需求或多或少都要和产品目标挂钩，这样才能高效的走在正确的路上。
03 时刻保持用户思维
互联网常说用户思维，那么用户思维究竟是什么。当然你可以百度，我自己的体会所谓的用户思维就是把用户放心上，去感受用户的情绪，去尝试贴近用户，了解用户，为用户服务。
你必须明确你的产品是要为用户服务的，而不是去压榨用户，欺骗用户，那样你的产品不会长久。即使产品不得不为了商业化或其他因素而短暂牺牲一些用户体验，你也必须思考产品是否能提供其他价值，来平衡用户体验的缺失。
产品在做需求时切忌不要把自己当成用户，以为自己觉得好就是好，这样的错误很容易犯。之前我们在改一款产品的UI时，改为团队都觉得好，我也觉得变漂亮了！然而我们觉得的“漂亮”并不等于用户觉得的“漂亮” ，当时产品的用户大多是中老年用户，他们喜欢什么？喜欢的是大红大紫，字要打，按钮要大，他们的审美能和我们年轻的团队一样吗？
做需求一定要站在用户的角度去考虑，充分利用公司的资源去尝试分析他们的用户画像，定期做用户调研，不断增强对用户的了解，能否了解用户，是产品的命门！
04 数据分析的正确思路：先业务，后逻辑，最后数据
数据分析这个词已经烂大街了，究竟应该怎么做数据分析？
数据分析第一步：找准业务切口
数据分析的目的是什么？解决问题，指导业务！不能够指导业务的数据分析是没有意义的？这也要求数据分析师们每做一份数据分析报告，都要思考你的报告指导的to do是什么？
另外一点，对于新手数据分析师来说，一定要注意细节，切忌“大”和“空” ，又大又空的结论是不好落地去做的，不如去以数据为支撑去解决那些具体而实际的问题来得有价值。
记得我第一个提的需求是改变道具的摆列顺序，我从数据中发现摆在第一个道具的使用率最低，用户获取道具获得的成本也最大，把它放在第一个是不是符合用户的心理预期？很明显我老大在设计产品的时候并没有考虑的那么细，但是我利用数据加上合理的逻辑，让我老大觉得这个需求是好的，是能够优化产品，提升用户体验的，哪怕很细小，但是他很实在不是吗?
数据分析第一步要找业务切口，寻找业务切口的能力决定了数据分析师的核心价值，优秀的数据分析师往往能切得又准又狠！
以我的经验和思考，低级数据分析师的业务切口往往是去找原因；中级的数据分析师我觉得是能够去总结和复盘一个完整项目的；高级的数据分析师有能力在产品经理束手无策，产品看似僵死的时候，能够拨开云雾见日出，为产品指明方向。低级的数据分析师依靠逻辑，高级的数据分析师靠的是行业经验，或者说，所谓的嗅觉。
数据为后，逻辑先行
当找到了业务切口时，不要着急去拉数据，数据为后，逻辑先行。
思考你的数据分析的逻辑是什么？对于产品经理或一些业务型的数据分析师来说，最常用的数据分析方法不过是逻辑的推理，并不需要一些时下热门的机器学习的算法，就连普通的统计学方法也可能很难用到，这不是说逻辑推理不好，相反，逻辑推理效率高，站得稳，并且你弄得懂，你的团队和老板也听得懂。
关键是得把逻辑讲好了，不能有漏洞。一旦逻辑上出现漏洞，一切结果都站不住脚，拉再多数据也白搭。所以在实际动手做数据前，一定要先把逻辑想清楚了，捋顺了。
同样举个例子，我老大有一天想做个数据分析，然后让我拉各种数据，又做了表格，等到日会上汇报时，所有的一切被老板一句话怼回去：我们要做的不是提升新增用户的数据吗，那你分析全部用户的数据干什么？现实就是那么残酷，所以想清楚了再拉数据！
以我的理解，产品经理未来对能力的要求中，数据分析将从加分项变成必须项，产品经理是最适合做数据分析的人，因为他最懂自己的产品。所以别总是原型图了， SQL也要学起来，相信我，会SQL拉数据的产品经理工作效率会大增，因为他再也不用追着数据分析师要数据了！
05 正确解读AB实验
AB实验的重要性就不多说了，除非出现新的更好的统计方法， AB实验永远会是大数据时代下的焦点。我相信大多数产品都知道AB实验是什么，但其后一些人可能并不会正确理解和灵活运用AB实验，读者可以尝试回答以下一些问题：

实验显著意味着什么？不显著又意味着什么？
空转实验是什么？一定要做空转实验吗？
当确定了产品目标，例如留存提高1% ，那么至少需要多少流量跑多少天？
实验跑了很多天，一会儿高一会儿低，数据一直不显著怎么办，还要继续吗？
实验数据很难看，但是实验还不显著，要停掉实验吗，怎么和老板解释？
实验数据很漂亮，但是实验还不显著，能向老板汇报作为结果吗？
明明是一个提升性的需求，实验数据却变差，怎么办？

其实理解了AB实验后的统计学原理，这些问题都不难，我将近期发表一篇文章专攻AB实验的统计学原理，或许会帮助大家更好的理解，有兴趣的可以关注。
最后，我想做产品的大家都是有理想的吧，愿大家每一岁都奔赴在自己的热爱里！
PS：本人目前统计专业研究生在读，第一次尝试发文章，非常欢迎一些志在互联网发展的同学们来一起讨论，一起进步，有想交个朋友的可以私信我哈哈哈。
作者：产品小强，北师大应用统计研究生
本文由 @产品小强原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash ，基于CC0协议