产品经理该如何写好一篇复盘报告?

6 评论 30265 浏览 147 收藏 9 分钟

产品经理要怎样才能写好一篇复盘报告呢?一篇复盘报告里要包括哪些内容呢?

对于产品经理来说,每一次有大的项目上线,总是需要进行复盘的。说简单一点,复盘就是一次思想的迭代,为下一次做出更好的产品做准备,也是一次成果分享,与研发、设计、数据等兄弟团队共享工作成果。

而对很多新人产品经理来说,写需求单容易,画原型图容易,但写复盘报告很难。是的,在我们公司,复盘报告的格式要求已经从PPT转为了word。你可以试试,用PPT做一次复盘很容易,但用word就难得多。

这是因为,你必须要用文字本身,去帮助读文档的人理顺逻辑,这并不容易。

那产品经理该如何写好一篇复盘报告,我用自己做过的一次复盘来简单分享一下。话不多说,先给到我整理的脑图,用以说明报告框架及各部分的作用。

下文将基于脑图来展开:

框架是我们阐述复盘内容的逻辑骨架,框架搭得好,能够帮助读者看完你的内容。的确,如果看你文档的人能够坚持读完,并且能记下一些东西,那这篇文档就算是成功了。

要做到这点,框架就得符合金字塔原理。(如果不清楚什么是金字塔原理,非常建议去阅读《金字塔原理》这本书,这是美团点评内部的必读物)

(1)背景

直接指出项目的背景,少说废话。一个新产品的上线,要么是从0到1,此时应该讲清楚为什么要做这个产品,支撑起了什么样的业务战略;要么是优化,此时要讲清楚旧产品有什么样的缺陷,影响范围是多少。

(2)关键结论

关键结论一般包括两部分,一是与产品需求单中的核心指标相关,用于回顾产品整体效果;二是产品上线之后一些额外的数据反馈,用于指导产品后续的迭代方向。

关键结论一定是基于数据!数据!数据!不能够量化的结果,尽可能不要放在关键结论部分。

可以这么说,关键结论是整篇复盘报告中最值钱的部分,是金字塔原理的充分体现。如果你的老板是一个很忙的大佬,看到你的复盘时,可能只会挑选关键结论看看。

有人可能问,如果关键结论这么重要,为啥不一开始就直接写关键结论呢?

我的理解,还是要保证可读性。如果读者不是一个对你的项目背景特别了解的人,直接读关键结论,可能吸收起来会比较困难。

(3)目标

按照普通的逻辑,背景之后应该是目标了。只是从信息的表达效率考虑,将关键结论前置是有必要的。但从整体上来说,复盘报告还是会按照STAR法则展开。因此,在这一步,我们该介绍(回顾)项目的目标了。

(4)落地抓手

确定了目标,即想要做的事情之后,下面就该介绍你到底做了什么样的事情了。这部分与你的实际工作内容息息相关,也是衡量你工作量的部分。

为了保证逻辑上的连贯,这个部分我一般会跟结论相对应,即一个关键结论,对应一个落地抓手。这样读起来,在逻辑上会十分友好。

当然有时候项目比较复杂,很难做到一一对应,此时将你做的事情做合理的拆分即可。有关拆分,一般遵循的原则是MECE(穷尽且独立)。即你所写的内容代表了你做的全部的事情,且各个小点之间没有重复。

(5)具体分析

具体分析,就是核心结论的数据分析过程。

但说实话,这部分的内容可读性要求没有那么高,它唯一的目的是保证你在开头得出来的关键结论是准确的。

也就是说,很多人可能不会看你的分析内容,但是当他们对你的结论合理性存疑的时候,你的分析内容需要能够证明结论的正确性。

基于此目的,我的建议是具体分析包括结论回顾+图表+文字说明这三个部分。其中图表是核心,优秀的图表往往不需要很多的文字说明,就能够很直观地表达出你的结论。(在这里推荐《用图表说话》这本书,也是咱们公司内部的必读物)

(6)认知迭代

认知迭代是一个项目上线之后,我们对于整个产品开发过程的思考。大体来说包括三个方面,做对了什么,做错了什么,下一步的计划是什么。

其中最核心的是下一步计划,这块内容往往就是产品后续迭代的方向。

(7)补充说明

这部分是对整篇文档的补充说明,一般包括起到补充说明作用的数据报表、产品的视觉图或者其他你认为能够起到补充说明作用的内容。

基本上到这里,一篇完整的产品复盘报告就算完成了。

当然了解了框架,也不一定能够做好一次复盘。其中的关键,在于“以终为始”。从最后的结论出发,推导出文档里我们要填充哪些内容。

而在这一过程中,数据是最关键的内容。

记不记得我在一开始说的,关键结论一定要基于具体的数据。那到底要看哪些数据?这决定于产品在策划阶段就必须要想清楚的——

为什么要做这块产品?用什么样的数据去衡量效果?

想清楚了这个,则在产品开发的过程中,你自然会重视打点的过程。可以说,如果打点不全,有时候产品真的是算白做了。

没有打点就没有数据,没有数据就得不到量化的反馈,不知道产品效果如何,不知道最初制定的目标完成效果如何,就更谈不上复盘了。

话说回来,做产品过程中的一点一滴,都是环环相扣,而贯穿整个链路的,可以说数据是最关键的了。

最后想说的是,模板也好,框架也好,其实都是辅助的工具,最终的目标都是为了帮助自己写出一篇好的复盘报告,让自己和其他人愿意读、读得懂、有收获。

但无论形式融合,很多法则总是被验证且经久不衰的。比如金字塔原理、比如STAR法则,比如MECE法则。

有了这些武器,我们就知道该如何组织,该如何表达。至于具体每个部分说什么,怎么说,取什么样的副标题。还得是根据自己的项目再具体安排。

 

本文由 @爱思考的大力哥 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 如果有实例就好了,更容易理解。

    来自广东 回复
  2. 复盘 是否就是找到已经处理过项目的问题,为之后提供经验教训?总感觉写复盘写的就是在找问题,然后如何做的更好

    来自浙江 回复
  3. 厉害👍

    回复
    1. 😳😳😳

      回复
  4. 最开始不应该是目标达成情况吗?

    来自湖北 回复
    1. +1,对内复盘肯定是先给目标完成情况。感觉文中的文档有点像给其他团队的分享文档,估计是放在背景里的。

      来自四川 回复