重视每次复盘，在复盘过程中，更容易发现自己的问题。对已发现的问题，进行及时调整改进，再次输出，等待新一轮的反馈。

前言

随着人口红利消失，存量时代的来临，企业想要增长，都在用什么方法呢？对用户进行精细化运营，是大家现阶段都在用的方法之一。那在精细化运营阶段，需要能够更好的触达到用户，让用户尽快下单，促成交易转化，这才达成了终极目标。

对于“触达用户”，我们在产品侧做了两大功能。该功能上线后，领导让做一次宣讲会，我当时思路很清晰，想着汇报时，总共分为3部分：现有功能框架介绍、回顾数据、未来的规划。

按照这个思路，PPT做好后，就开始汇报了，但没想到汇报之后，发现自己的汇报真的是逊爆了。于是开始进行自我反思，分析问题出在哪。

问题：发现不足

1. 只写了项目目标，没写其推导过程

当时是把目标思考清楚，定义好，写在PPT上面。这样讲下来后，发现因为没输出自己的推导过程，所以这个项目的目标，对听者来说不够有说服力。

罗列式的目标，让人听过后很容易忘记，就像在走形式，没有记忆上的存留。经过思考，我做了如下改正：首先，先讲业务流程。其次，在业务流程这个框架内，讲解自己是怎么推导出这几个目标的。

这样做的益处是：

1. 业务流程能让听者了解到全貌，让听者感受其中的逻辑关系，结构性。所有人的大脑都喜欢结构化的东西，这样会更容易让人记住。
2. 讲解自己的推导过程，好处是会让听者更信服你的目标，也更坚定这个目标。

总结，下次在汇报方案时，一定要把框架或业务流程说出来，并且说明目标在框架或业务流程内是怎么被推导出来的。

2. 能抽象成框架的，绝不要简单罗列

当时是把现在已经实现的功能，用表格的形式罗列出来。觉得这样看起来逻辑更清晰一些。但是对用户而言，缺少了框架上的梳理，直接看表格中的功能，没办法形成对该该功能框架上的认知。

经过思考后，我把前后台的功能抽象出来，形成框架图。首先，先讲框架层面的前后台结构，其次，在从框架中进行拆解，讲前台目前都实现了哪些功能的表格。

这样做的益处是：

1）首先，帮助听者先建立起框架认知；

2）其次，在框架中进行拆解，使读者能够更好的吸收和记忆。

如果你在汇报功能现状时，也和我一样，仅是罗列现在已经实现了哪些功能。那建议你尝试下，把已实现的前后台功能先抽象出一个框架，先讲框架，在讲框架拆解后的，前台已实现功能，后台已实现功能。

3. 要讲自己本次功能的数据评价指标是什么，不要上来直接罗列数据

一般我们在给领导汇报方案时，通常都会说下现在的数据表现情况怎么样，以及接下来打算怎么做。那在汇报现当前数据表现情况时，我本次犯了一个错误就是直接罗列数据，然后说了下数据分析后的结论

可是领导其实很关注，为什么一开始你要设立这几个数据指标，作为本次功能的评价指标？也就是从事情的本质出发去思考。因此，你得要先概括的说下，自己根据功能，拆解出本次功能的数据评价指标分为哪几个，这几个分别能说明什么。然后在去讲每个指标的具体数据情况

如果你在汇报时，也和我一样是罗列数据。那建议你也尽快迭代下自己的汇报方法吧。例如，可以尝试下，先讲自己为什么提炼出这几个指标？这几个指标的好与坏分别代表着什么？然后再说具体的数据表现情况及其分析结论

总结：探寻规律

重视每次复盘，在复盘过程中，更容易发现自己的问题。对已发现的问题，进行及时调整改进，再次输出，等待新一轮的反馈。这个循环，是增强回路。要做的是，在此循环中，不断的迭代打磨自己

虽然成长的过程伴随着阵痛，但不要沉浸痛苦之中，而是复盘总结，探寻规律，为下次更好的出发做准备。经过这次，我总结了如下两点，送给自己做警示，也送给你们，共勉之~

1. 认真对待每一次交付物

稻盛和夫的《干法》一书中，提过2个问题，给我留下了特别深刻的印象。

这2个问题分别是：

1. 你是否付出了不亚于任何人的努力？
2. 你的工作方法是否不亚于任何人？

这次因为有好几个需求在并行，时间特别紧张，所以对宣讲会的准备，没花太多的时间和心思。但经过这次，发现这样做是不对的。即使在忙，也要认真的对待自己的每一次交付物。为什么呢？

你每次的交付物都代表着一个作品，每个人都会对这个作品打分，对你这个人打分。如果你的作品一次好，一次坏，不稳定，那就是有问题的。要保持稳定的曲线，保持每次作品都是90分以上，就需要付出不亚于任何人的努力。

你的每个交付物都在大家心中留下了印象，代表着你的专业能力。如果你的交付物一直很专业，那会吸引更多的同事，愿意和你合作。从而你将会有越来越多的机会，展示自己。

2. 不断的向上抽象框架

其实已经抽象框架了，但经过和另外一个，一同做汇报的PM对比后，发现抽象的还不够。引发了思考是：到底抽象到什么程度才算抽象完成了呢？

我思考的结果是：不断问自己，就这样了么？一定还可以在向上抽象，在想想，在通盘想想。把这个问题，问自己3遍，直到3次都答真的抽象不出来了，在停止。

抽象出的框架主要价值在于，能让听者更容易看到全貌，而不是庖丁解牛中的一小部分。先把抽象出的框架进行讲解，让听者看到整个功能各个系统之间的全貌，在去拆解每个系统中的逻辑，讲解局部的信息。按照这个逻辑讲下来，会让人感受到逻辑关系的递进，更容易理解和记忆。

以上，是本次复盘的2点想法，分别是：一定要认真的对待自己每次的交付物，不断的向上抽象框架。希望在你日后汇报方案时，也能多检查几遍自己的方案，问问自己如果满分是10分，你给自己现在的方案打几分？

如果打7分，那为了打到9分，你认为是因为你做了哪些事情，让方案可以达到9分了呢？希望对你有启发~

本文由 @产品跃迁 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。