最近在进行年底的工作总结和汇报，各个团队向CEO进行工作总结以及新年度的目标规划，听了近20个人工作汇报，协同团队提问、Diss以及老板的点评后，总结在工作汇报中常见的坑点，分享给你，或许在你下一次晋升汇报或者工作总结的时候，可以有所帮助，至少可以先扫个雷。
一、避免沉浸式自嗨，学会讲故事
晋升评审或者大型的工作汇报，对于听众来说，多数未必清楚你所做的事情的，如果只是站在自己或部门的角度去讲了很多专有名词，听众听得云里雾里，提问都不知道如何下口，只能挑一些通用的数据指标或者边角的细节进行展开。听到最好的汇报是从故事开始，去讲在做产品市场调研时遇到的一些用户经历的事情，客户遇到的痛点和困难，再回归到为什么要做这款产品，能够帮用户、公司带来什么价值。
二、数据指标既要相对值，也要绝对值
用数据说话是为了更客观，有说服力，但如果呈现的数据无法准确的表达其含义，会带来更多的解释成本。例如利用算法能力之后运营效果转化率提升了200%，是不是本来数据基数很小，从1到3，还是从1W到3W，两者结合，才会更有说服力。
三、数据转化为通用的业务含义，避免单纯的数据呈现
例如通过一个季度的努力，订单转化率从58%提升到60%，对于不做这块业务的人来讲，看到这个2%的提升是没有感觉的，甚至会想才提升了2%有啥好讲的。如果能把这个2%体现的业务价值进一步地量化，例如带来XX订单增量，XX营收金额，XX新客，这样更直观。
四、多和行业对比，竞对对比
怎么评价产品、技术做的好?自己当前做的事情，究竟是个什么水平，是真的好还是王婆卖瓜自卖自夸呢?可以多把自己和行业作对比，可以是量化指标的对比，例如客户服务的一次性解决率，也可以是产品能力、用户力等方面的对比
五、产品功能目标转化成业务目标
B端系统的产品研发往往会从产品做了哪些功能或者计划要做哪些功能出发，更聚焦与做的事情的本身。对于其他不了解这块业务的其他听众来说可能会云里雾里。而如果能够从为什么做，需要给业务或者用户解决什么问题的角度出发去讲，目标会更加的清楚。
六、需求不是做的越多越好，要定好需求价值的评判标准
B端产品做项目汇报时经常会罗列做的功能或事项，例如本季度用户提了200个需求，完成180个，完成率90%，未必就能证明做的好。而应该从每个需求的价值角度，去看完成的需求带来多少业务价值，比如带来用户的增长、业务的增长等。
七、目标规划要有时间点
工作汇报时，老板或者有工作协同的兄弟部门，如果你的目标是和他相关、比较感兴趣的，他们最关注的往往不是你准备怎么做的细节，而是你做的这个产品、功能他什么时候可以用上，不需要非常准确的时间，但要有个时间的心理预期。
