在每完成一个项目后的复盘对于产品经理而言，是极其重要的事情，能够帮你找到失败的关键问题、能提出有建设性的建议。而不懂得复盘的产品经理，要么靠着天分真的会做的很好，要么就是瞎猫碰死耗子，要么就是只会做功能。
工作复盘的价值1. 作为向上汇报的工具
定期采用复盘的方式向上汇报，告诉老板他允许你投入资源项目产出的结果如何。
【做的好】老板对你信任感加剧，他看见了你的能力，未来更放心交给你更多项目和更多责任。
【做的不好】不要害怕老板会觉得你不行，你复盘的好，找到失败的关键问题、能提出有建设性的建议，他会觉得你知错就该，学习能力高、潜力大。
2. 作为自己定期的结果产出
面试的时候，面试官总是抓住一个重点项目用STAR问你项目的结果。一个项目的结果=你的能力+形势+团队。
如果是你独自负责的项目能给说明你的业务能力；如果是你配合的项目，那么进一步询问你是否知道这个项目为何能达成目标，如何达成目标的，看出你是否拥有相关经历的视野和经验。
所以，复盘可以让你定期总结自己的工作成果，为你在对内和对外展示自己能力的时候给出充分的依据。
3. 作为自己成长的阶梯
在产品工作中，我们产品一直都是在做选择，确保自己在做一定时期、一定情景、一定资源下最正确/最合适的决定。
那么何为正确？这是最难解释的。
有一些正确是靠着产品经理对人、对经济模型的理解作出的推断，有一些正确是靠着经验和经历证明的。
需求的复盘恰恰就是用数据总结出之前的选择是否正确，我们也用复盘的结果判断是否可以把这种功能和思维延伸使用在别的类似场景、需求、产品设计上。
我是非常认同这点的。
试想一下，如果一位产品经理内心对一个选择根本没有风险和成功概率的意识，那么如何做出合适的选择？这种风险、成功概率的意识从哪来呢？
如果是一款功能，那么可以依赖于你做过后的数据结果。如果是一个项目思路，那么依赖于其他成功项目做对的总结。
所以，不懂得复盘的产品经理，要么靠着天分真的会做的很好，要么就是瞎猫碰死耗子，要么就是只会做功能，别人说什么自己做什么，直到需要自己独自承担责任的时候就很难产出结果了。
工作复盘的时机
关于复盘时机，我的建议是：做过的都要复盘。但是我们可以根据自己时间、上级的要求和项目/需求的大小决定自己投入的复盘时间和产出的格式。这里特别提醒一句，不要因为产出的格式而提高了复盘的难度。有时候一段话、一个表格即可。
产品复盘的结论范围
我把产品经理的工作分为两类：产品探索和产品优化。这里根据不同复盘结论，列出细节点：
1. 产品探索
从业务本身要打造的产品模型是否完成？
产品本身是服务于场景下的需求的，根据用户使用数据（尤其是留存数据）和用户反馈查看你的模型是否真的给用户带来价值。
目前产品模型运行的问题在哪？解决这个问题关键是什么？接下来关键点如何迭代？
2. 产品优化
产品迭代的优化是否完成目标？
优化后，相关的数据提升如何？是否对其他相关功能带来负面的数据？
是否还需要继续优化？下一步优化的方向在哪？
复盘报告的内容
简单列一下我梳理出的比较正式的产品功能复盘报告必要的内容。
1. 结论：做到结论先行
写自己项目/功能目标是否完成，完成度如何。
写功能的价值，通过量化数据说明迭代后对什么数据有正面和负面的影响。
2. 具体问题
通过此次复盘数据和需求上线后你观察的情况写出关键的几个问题。
3. 建议
针对关键问题提出具有建设性的方向，最好是此阶段可行性比较高的建议。
建议和问题要做到有一定的对应关系，要不就失去了分析问题的意义。
4. 具体数据项目/模块的整体数据自己迭代功能的具体数据自己迭代功能的其他相关功能的数据
举个例子，假设我做个一个功能目的是提升UGC内容发布。
那么，复盘要包括：
（1）结论：UGC内容发布数据是否有提升，提升多少。促进UGC内容发布迭代的功能本身使用UVPV、留存如何。对内容浏览、互动是否有正向影响，若没有可以不写。
（2）问题：通过功能数据，发现添加话题功能并没有起到预期的作用，可能关键原因是什么。
（3）建议：关键原因的解决方案如何，下一步该如何行动（包括自己解决和跨部门协作）。
（4）具体数据：内容的产出、互动、消费数据；内容发布功能的使用情况和漏斗模型。
写在最后
研发总是质疑：产品经理就是抄别人的功能有些人总是自我怀疑：我到底如何选择，为什么最终做了这个选择？
产品经理这个职业是非常综合的职业，它对一个人本身的软性能力要求偏高，包括深度思维、沟通能力、逻辑思维能力、共情能力等等。很多时候我们做出选择，有时候靠着感觉，而感觉又难以说服别人。
那么我提倡在提高自己产品思维的基础上，我们通过复盘可以从数据、结论给自己选择提供一些基础依据。
做一个拥有选择底气、踏实成长的产品经理，不香吗？
本文由 @阿琼 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
