产品经理年终总结

产品经理年终总结

编辑导读：2020年的时间彷佛被人按了加速键一般，转眼间就到了年底，很多人要开始写年度总结报告了。回顾一年的工作经历其实并不简单，简单的罗列看起来太费力，在工作数据的基础上进行总结分析才是一份合格的年度总结报告。本文作者从产品经理日常工作出发，制作了几张“数据总结”图对自己的一年工作进行了总结，一起来看看~

俞军老师曾说过：“面对需求合理性的取舍，往往能决定一个产品生与死，而这恰恰是产品经理存在的原因”。

但残酷的现实是大部分产品人在需求取舍的敏锐度上基本缺失，也没有去挖掘需求的合理性。比如之前在Blues团队对需求的挖掘和梳理有一套完备的机制。所以这些产品经理在工作中放弃对“需求”这个最重要环节的掌控权，甘于成为“需求的搬运工”，所有力气和才华花在了自认为的“Do the things right”——生产环节：系统设计、交互、需求文档、项目管理。

如果你心里永远有条业务线和一张不断修正的产品蓝图。对于你自身来说，你将不会失败。用一张图来梳理下：

前面稍微聊的有点多。接下来John通过产品经理日常工作制作了几张戏谑的图，来聊聊产品经理年终报告：（踏实做好每一步，将每块产品知识碎片拼凑起来，才能更好更快的成长。图片纯属虚构哈。如有雷同，你就太牛X了。）

01 关于业务需求

可能大部分产品经理在梳理业务层模块时，往往会被业务方牵着鼻子走。其中需要和业务同事进行有效沟通，主要分为三部分：

• 首先产品经理需要对整个业务非常熟悉——现有业务（直接呈现给用户的）和后续方向（业务规划和竞品梳理）；
• 和业务方沟通时，要有针对性追问业务同事提出方案的合理性。这不是抬杠，是说清楚做这个事情的意义和背后的目的。达成一致才能更高效做事；
• 背后的目的和当前优先级必须贴合当前OKR。

“业务”和“需求”是产品经理入行的必修课。业务的制定策略，可能产品经理不太清晰，但是业务的实现逻辑以及业务规划，产品经理要非常明白。

02 关于用户需求

大部分的用户需求合理性一定是用户在一段时间使用产品后反馈的需求，所以这就是为什么要时时刻刻跟踪用户，跟踪用户最好的方式是把用户凝聚在一个群里互相沟通。这也就是搭建核心用户群最好的办法。John一般是这么做的：

• 适当的福利加引导，尤其是新版本更新时，非常有必要去做；
• 比如在电商产品中，每天有效的做好任务引导（核心群设定对应的任务环节），并做好优惠+奖励；
• 其他的，运营需要准备对应的方案。

需要注意的是：一定要有了完备的方案才考虑拉核心用户群，且核心用户群目的是为了用户反馈需求。一定要围绕这两点出发才行。否则就变成营销群。

03 关于数据需求

数据的重要性对于产品来说就不言而喻了吧。但是…但是…数据字段的定义是基础点。如果数据定义都产生分歧or模糊不清，那再多的数据都是扯淡了。那么产品经理和业务一定要尽可能有完备解释每个数据的定义。比如：

• 新增用户(7日平均):最近7日(不含今日)每日新增用户的平均值
• 新用户次日留存率(7日平均):最近7日(不含今日/昨日)新增用户次日留存率的平均值
• 使用时长(7日平均):最近7日(不含今日)用户每日使用时长的平均值
• 活跃用户(7日平均):最近7日(不含今日)每日活跃用户的平均值
• 7日总活跃用户数(重) :最近7日(不含今日)活跃用户的总数(去重)
• 30日总活跃用户数(去重) :最近30日(不含今日)活跃用户的总数(去重)
• 累计用户数:截止到当前时间，启动过应用的所有独立用户(去重，以设备为判断标准)
• 总崩溃率:每日错误数/启动次数

先定义好数据字段，在去梳理数据分析。

04 关于产品拆解

“如果你认真拆解3款产品后，你真的会上瘾。”如果只是完成任务，你会越拆解越难受。所以试着去拆解下产品，真的贼有用。新读友可以看看拆解的三步法：

• 产品架构——梳理下产品功能清单（尽量无遗漏的写出来）；
• 运营体系——结合该产品的历史版本迭代记录和结合市场分析做出运营体系梳理；
• 商业模式——梳理下该产品的盈利模式。

（还可以加上以下两条：

• 核心流程梳理——把该产品的核心流程及其有关联的流程全部梳理出来；
• 特色功能——特色功能的交互和页面流程梳理有必要整理出来。）

建议产品小伙伴都去拆解下，哎哟……真的会上瘾哦~

05 关于产品路线图

对产品规划和业务规划非常清晰，并且对于竞品有一定的认知后，再来制作产品路线图。且产品路线图一定要落地……

所以路径一般是这样的：产品规划蓝图→产品需求；业务OKR→业务需求；用户核心群→用户需求；数据分析→数据需求。把以上需求进行紧急优先级梳理和排序，和各方小伙伴进行版本梳理。

制定了就需要推行落地，有调整就修改……

06 关于产品设计

产品设计处于基本功，清晰的产品原型展示是传达给项目组的基础。需要考量的点是：

• 产品设计的原则要和UI叙述清楚，让UI能从产品原型中明白你的意思；
• 产品原型在技术眼中要清晰功能的重要优先程度。

John一般针对于原型的设计是黑白灰的线框图。给UI在设计的过程中，尽量不要造成配色上、布局上的歧义。在交互上，有条件的尽量可以完善交互和用文字表述清晰。

另外，有参考图会更佳。核心点就是通过你的产品原型设计，能让项目组明白布局、功能的优先级。一定是梳理清晰了，最后进入原型阶段。来来来，一个口诀：重要核心功能，原型展示粗大黑；边缘辅助功能，原型上轻呈现，留入口。

上周天晚上发了一个朋友圈帖子——当遇到一个已前端优化为主又没有思路的项目的时候，你可以：

• 看看哪些信息需要组织 ——— 对界面元素信息的重新归类和划分，划分信息层级；
• 看看哪些信息需要展示 ——— 对界面元素重要程度的划分，调整信息要素；
• 看看哪些信息需要隐藏 ——— 对界面不常使用的元素进行隐藏，增加界面的扩展；
• 看看哪些信息需要规范 ——— 对界面的可视化保持统一和复用，减少认知和设计成本；

相信你对产品设计就有一定的认知了。

07 关于产品逻辑

产品逻辑真的是要命，99%的产品经理在逻辑上必定失手。主要体现在：

• 单独的模块的正向流程中的逻辑说明——能完成99%；
• 单独模块中的字段梳理和边界值——能完成90%；
• 单独模块的异常流程（边界值、空白页、网络环境、提示等）——能完成75%；
• 多模块串联的正常流程、异常流程、边界值、历史流程关联——能完成50%。

你瞧瞧，技术能不崩溃么？John梳理的自查表只能解决80%（主要针对于单独模块），那多模块串联主要是要看历史文档和对用户路径和流程的敏锐度。所以为什么说梳理产品时一定要把用户路径整理出来呢？

业务流程和用户多路径并发，是梳理清楚产品逻辑的基础。加上John梳理的自查清单，应该能解决99%的问题。

08 关于产品评审

产品评审的过程貌似感觉是把产品经理送上“审判台”似的。每个项目组的同事都在看你的“洋相”。稍有不慎，这评审会必定变成需求讨论会，无论多少次评审，肯定没有终点。所以就需要产品经理在评审前、中、后有效的组织。

评审前，一定要把相关的需求清单和原型知悉给参与项目的伙伴；

评审中，切勿针对需求做二次发散，每次发散都是需求的不确定性；

评审后，会议纪要和需求澄清说明。并在二次澄清会上给予需求排期。

09 关于项目协同开发

“小步快跑，快速迭代”是我一直在项目管理中实行的。尤其是多项目组并发时。但是有几个前提条件：

• 梳理产品版本时，应该尽可能的完善，无遗漏，给项目组传达的内容要足够清晰；
• 落地且切合实际、成熟的项目协同流程，做到协同高效清晰；（可以公众号回复关键词：项目协同，查看John整理的项目协同流程。）
• 产品经理和业务牵手齐步走，才不至于出现“产品经理催着业务要业务方案”、“业务催着产品经理知悉上线进度”。

以上三个点，缺一不可。只要缺失一项，产品、技术、业务会被拖死的。同时也需要制定产品路线的清晰性和完备性。

10 关于加班

如果上面任何一步都没有做好，长时间的加班肯定是在所难免的。加班真的不可怕，可怕的是加班效率还贼低。

我非常不鼓励团队的小伙伴加班，因为正常的加班只有两种情况：

• 时间没有分配好，该搬砖时在摸鱼，所以下班就赶进度；——按时定点的完成，绝对不说。
• 工作效率低，重复性的工作太多（需求没有搞清楚，反复修改原型之类的）。——那就需要聊聊做事的方式了。

鼓励的是下班后，留一个小时一起学习、讨论、交流。。。

11 关于OKR

OKR绝对来不了半点虚的，一定是要落地的。过程中的每一步必须要做到有迹可循。尤其是作为产品经理在梳理产品OKR拆分时，并不能停留在PPT上，而是一五一十落地到产品路线图中。因为制定的OKR是最终到公司资源投入层面上，只有做好和有效果，整个公司才能往前走。

除非，您是用来炫技的。。。

最后想聊的是尽管图片上都是段子，但是也是我们正在遇到的“糟心事”。这也就是产品经理的价值：能尽量正确的处理好每一步。简单的做好了才能判断复杂的决定。站好马步后才能开始习武。

一遍一遍的理需求和一步一步过流程后，你才能看到产品框架。竞品拆解多了，你就能看到产品架构、商业模式和运营体系。

勿以事情零碎而不为，否则永远都是站在岸上游泳。

作者：John，产品狗一枚，微信公众号：产品狗聚集地。

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

题图来自 Unsplash，基于 CC0 协议