产品经理的“年终述职报告”怎么写？-鸟哥笔记

2019即将逝去，相信很多小伙伴们，都在忙碌地享受着2019最后的狂欢，抑或是提前感受到了2019曲终人散的孤单。在此之际，让我们一起来总结一下吧，年终述职报告不仅仅是工作中的一个过场，更是我们职业生涯阶段的一个结点。认真对待每一次总结，不为别人，只为自己，方能不负华年。

前言

2020年的到来，预示着自己将成为一个6岁的互联网人，4岁的产品经理了。当人们开始回忆的时候，总是免不了一些伤感的氛围。写到这里，不禁有些感慨时光如梭，岁月蹉跎。好了，牢骚的话咽在心里，努力向前，尽人事，听天命！

此次年终述职报告的的性质我们前面也提了，其一是工作中的一个任务，其二是对于自己职业生涯的阶段性小结。既然性质如此，我们就需要两者兼顾。根据自己的工作情况，我在年终述职中，主要想表达三个核心观点：

专业度

以专业的方法论来以正视听，让大家明白，我们产品经理并不是互联网公司总打杂，也不是单纯的作图仔，产品经理也是一个极具专业性的岗位。

责任心

总结工作中存在的问题，包括个人层面与团队层面的，并给出相关的解决方案。能够发现问题，并能够给出解决方案，这本身就是有责任心的体现。

产品价值

产品的价值包括两个方面，一个是使用价值，另外一个是商业价值。在很多时候，两者是相辅相成的，提升产品的使用价值，必然能够为产品的商业价值赋能；但有时候两者又是相生相克的，不得不为了产品的商业价值而牺牲部分的使用价值。如何为产品赋能，这是领导层非常愿意听到的话题。

我们来看一下，在年终述职报告中，第一个观点表达自己的专业度，第二个观点表达自己的责任心，第三个观点表达如何创造产品价值。试问，如果是你作为领导，听到这样的年终述职报告，你会不为之心动吗？

接下来，我们以ppt图片+备注的形式，来看一下这份产品经理的年终述职报告，看看你是否也会有些许的感同身受。

报告

自己的述职内容，主要包含了三个部分：

第一部分年度工作概述，主要是回顾一下一年来自己主要的工作内容；

第二部分工作复盘分析，我认为总结的目的主要就是为了发现问题并解决问题。这部分主要分析了一下整个工作过程中自己存在的，以及在协作程中存在的一些问题，并思考了一下这些问题的解决方案；

第三部分是自己对于未来工作的一个展望。

我这边从三个维度总结了一下自己的工作，分别是项目维度、职业维度以及产出维度。

这一部分内容，真的只是走过场。因为这一年下来，你到底做了什么，有哪些贡献，领导大概都是知道的。你再怎么描绘的丰富多彩，领导也只是听一听而已。但作为述职汇报，这方面的内容又是必不可少的~

有这两个方面值得注意的吧：

1. 拿数据说话；

2. 描述进度状态。

例如我在这一方面，会讲解经历的项目包含哪些主要模块，x、y表示数据，状态包括落地阶段和设计阶段。整体表达了自己一年经历了几个项目，然后每个项目中已经落地的模块有x个，还在设计阶段的模块有y个。

当然，大家如果有更加丰富的数据维度的话，可以继续往上列举，例如营收数据，用户数据等等。

这张PPT主要总结了自己工作过程中涉及的“面”。

产品经理的技能树大家或许见过，涉及的内容特别多，也充分体现了产品经理这个岗位的特性——“综合性”。我这里只列举了这几个方面，其一是因为这些方面是自己工作过程中接触最多的，其二也是因为自己对于这些方面感受最深，有很多想要总结的地方。

我们先来看两方面的分析：

B端产品的核心价值之一就是提升用户的效率，而提升效率的关键就在于业务流程的固化与优化，所以分析的第一方面就是业务流程；而业务场景，是产品设计的依据，是价值传递的介质，是沟通交流的基石，离开业务场景，我们设计的产品都可以说是雾里探花、水中望月。

我们再来看两方面的梳理：

这两个方面分别是信息梳理和功能梳理，对应的产出物是信息结构视图和功能结构视图，这也是功能概设阶段最主要的内容了；

最后就是大家最熟悉的原型设计方面了，还有就是相关文档的整理工作。

从职责维度概括一下的话，自己今年主要负责的有以上六个方面。

从产出维度来总结一下，自己的产出内容，大概有这样八种。

分析阶段产出的第一项内容是业务流程图，这个大家应该是都比较熟悉的。另外就是用于描述业务场景的用户故事，这是我们目前所缺乏的内容。用户故事能够让整个团队更加清晰地理解业务，以及明白自己做的产品为用户解决了什么问题，有什么存在的意义。用户故事表达的核心就是“作为一个，我想要<完成xx活动>，以便于<实现xx价值>”。

梳理内容的产出，刚才我们提到过了，包括信息结构视图与功能结构视图。这两项内容，相当于设计阶段的工程图纸，是设计的依据。

产品设计的产出，一个功能原型，这种类型的原型图主要是为了表达，我们设计出来的产品解决了用户的哪些问题，让用户觉得产品“能用”；另一个是交互原型，这种类型的原型图则是为了表达，在操作过程中怎样能更好地帮助用户解决问题，让用户觉得产品“好用”。

文档整理的产出，一个是面向技术端的需求文档，有很多时候，这种需求文档也会以原型备注的形式呈现；另一个是面向业务端的解决方案。

第二部分工作复盘分析，我将从个人层面、协作层面以及资源层面来总结一下其中存在的问题，以及自己能够想到的解决办法。

这张PPT可以说是对于自己职业生涯的总结。

首先自我评价一下的话，可以说是“经验掌握不足，知识掌握不够”。而这似乎又是一个伪命题，因为经验与知识永远都没有足够的时候。我们所能做的，只有不断地成长。

但很多时候，我们又会陷入这样的一个怪圈当中：我们做了一个又一个的产品，看了一本又一本书籍，但当我们开始下一个项目时，仍旧会感觉一切如此之“新”，似乎所有的都需要从头再来。

究其原因，是因为我们做的一个又一个产品，只是获得了“经历”，并非吸收了“经验”；我们看的一本又一本书籍，也只是获得了“知道”，而并非掌握了“知识”。中华文字，博大精深，两个词语的一字之差，其中的深意，真的很耐人寻味。

而这两者之间进行转变的途径就是“总结”。就比如我们现在正在进行的年终总结。

在今年9月份左右的时候，我也是为自己立下了这样的目标：“树立产品思维，构建知识体系”。我是觉得，无论在哪个行业，如果想要成为一个“专家级”角色的话，那么一定要有属于自己的方法论。

协作层面，我这边想总结的一点就是，缺乏了明确的流程规范。长此以往这样下去，造成的影响，存在于三个方面：

第一个方面就是会造成沟通反复，影响效率。人的反馈是感性的，感性就代表着这种反馈会根据周围环境的不同，或者是人们当时心境的不同而产生变化。所以很多时候会出现自己否定自己之前想法的情况。而理性的流程规范就能够有效地避免这方面的问题。

第二个方面是第一个方面的延伸，如果一味地以人为反馈为标准的话，那么久而久之就会产生“你说的都对”、“你让我干什么我就干什么吧”这种心态，这样就会造成自驱力将会被逐渐地消磨殆尽的后果。

第三个方面，是增加理解成本，浪费人力资源。从本质上说，人都是有惰性的，如果没有必要的条件约束，大家肯定都会选择简单省事的选项。而这样就容易产生一份需求不明确的需求文档，或者是设计不清晰的原型图，接收人理解起来就需要花费大量的功夫，到头来还可能出现设计与实现不一致，到最后再次返工的情况，浪费了人力资源。

所以说，我是觉得，在协作层面，逐步地建立起明确的流程规范还是很有必要的。

例如需求规范，我们可将需求分为问题级需求和方案级需求。

问题级需求是客观存在的，我们的一切出发点，就是为了帮助客户解决业务问题；而方案级需求，就会出现仁者见仁智者见智的情况，是有待探讨的。

在需求分析里面，有一句相当经典的话是这样说的：“客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题”。

所以我们每一次的需求分析，都应该经过“澄清问题—>了解背景—>建议并确定解决方案“的步骤。

再例如设计规范，按钮是我们最常见的功能了，PPT中这张图是我自己所用的组件库里面，关于按钮类型的规范。界内的规范有很多，而在以后工作的过程中，需要做的就是筛选出适合于我们的设计规范。

对于工作复盘分析，第三方面的总结就是资源层面的内容。主要分为设计资源和需求资源。

对于设计资源我想说的是产品经理、UE设计师，UI设计师这是不同的岗位，原型图可以往精细化的方向处理，但原型图毕竟不是效果图。所以说，我们要跟UE多交流，这也是团队目前有在做的事情。然后呢，虽然我们是B端产品，但UI这个环节我是觉得不能够省略的，毕竟术业有专攻，我们能够给出UI层面的直接体验反馈，但是我们无法给出专业的意见和建议，更无法从专业的角度进行UI层面的体验设计。

对于需求层面的，主要是指售前资源和用户资源。我们设计的产品，想要避免闭门造车的情况，就必须充分了解需求。这方面呢，我以后自己也需要主动地跟售前和用户进行沟通，另一方面，也希望领导帮忙协调这些资源。因为有时候想要了解一个情况，我确实不知道找谁。