又是一年四月,转岗产品已经一年了,一直想说对自己做的项目或者工作做一个复盘和整理,但是人总是有惰性,而没有付诸行动。然而不得不承认，作为产品经理，一定要在意系统性的对自己脑袋中的东西进行梳理，系统性地输出，这才会有所成长。

这张图就是我入行的时候给自己梳理的基本能力图，当时标注了自己想提升的一个优先级顺序，当前的能力水平以及期望达到的能力水平。按照一年期的时间来规划，现在看来这个定的有些“积极”。不过这也是主观上的认识，产品经理要求的能力比较综合，偏“软性能力”，所以说怎么定义还是看自己。

在程序员眼里，产品经理可能就是提需求和画画原型，但是其实前面还有很多的工作，比如用户调研，业务场景梳理，最后才能展现逻辑清晰，明了的原型图。其次，讲完原型也不是全部，后期跟进，迭代也是日常工作。作为一个产品，看似每天在办公室喝茶，其实可能也在深夜提灯写PRD。

1.市场判断,业务分析

首先是行业和业务的分析能力，从B端产品而言，首先就要理清楚整个业务流程，然后再去研究每个阶段每个场景使用者的操作，这是做B端产品最基本的要求。同时也需要关注一下特殊场景的需求，这个可能不是使用者的痛点，但是一定是他的痒点。现在大部分实业企业都有自己的科技公司或者科技部门，这时候我们打造的系统就是为自己的企业服务，所以说某个功能做出来就是为某个角色服务，可能需求就是来源于几个人。所以说这时候的功能点就偏向于定制性，可能偏离于理论上的功能设计。

2.用户调研和需求分析

关于用户调研和需求分析，为什么这两块放在一块写呢，这是因为用户需求的提出必定是基于他的角色身份，很有可能他只站在自己的角度上提出想法，但是忽略了这个想法很有可能给其他角色造成影响。

举个例子，我们工厂麻袋送到仓库，从仓库的角度来说，签收，拆包，验货这个流程自然是越简单越好，尤其是在麻袋多的时候，如果按照这个流程，仓库可能要操作到半夜，所以仓库的需求是，不需要验货，直接签收就行。但是如果工厂出货也不准呢，这就会导致仓库签收的数量与实际的数量对不上，我们系统中这个SKU的库存与实际的数量就有出入，并且只能在拣货下架或者盘点的时候碰到才会发现，那这个时候就已经无法追责了。

所以说用户提出的需求往往是站在他自己的角度上，作为产品经理，就不能只看到这一面,而需要去了解这个需求下真正的问题是什么。 所以在对业务了解的基础上, 在调研用户的同时进行需求的分析, 才能不被用户“牵着鼻子走”。

3.需求管理

关于需求管理这块,就是需求优先级的划分了。一般项目来说的话,当公司打算同时进行几个项目的开发,项目的优先级一般由领导层来定,这个时候也不用跟别的项目组去争资源。对于一个项目下需求和开发计划来说,个人一般会给他按紧急性和重要性来定,分为四个层级,重要且紧急,紧急不重要,重要不紧急以及不重要也不紧急,然后以P0,P1,P2标记,数字越小表示优先级越大。有时候人手不够的时候, 可能你项目组的人还会被拉去干点别的需求,这也是正常的。需求排好之后, 你的用户(业务方)可能也会来催他的需求进度, 这个时候如何安抚好他们,以及催促开发进度,或者调整需求优先级,都是需要去做的。

4.产品设计

前面讲了这么多, 接下来就是产出你的原型了。 原型怎么样画都行,只要能被别人看懂, 小公司迭代速度较快,往往会把PRD结合在原型中,在原型中做好标注即可。原型怎么画,仅仅只是产品经理的个人风格问题而已。画原型之前,业务流程图, 产品架构图的输出也可帮助你整理思路和顺利表达。

5.项目管理,沟通协调能力

其他的话,关于项目管理能力, 协调沟通能力都是软性实力,个人觉得60%看先天性格,40%看后天获得。 产品经理被称为是“小CEO”, 如果之后往管理方面走,也可以多注重一下项目管理方面能力的培养。

6.其他能力

最后,其他的辅助能力,则是一些锦上添花的东西了,比如跟开发怼实现,跟UI怼风格,跟业务和运营怼数据, 那都不认输的。说实话这些没有必要花大精力去学,日常工作中涉猎一下或者和开发小哥哥,设计小姐姐讨教一下就行。 我还是觉得,产品做好自己的专业工作即可。 对于B端产品经理,最重要的还是精通业务,和用户站在一起,深入他们的需求,做出让用户“乐”用的系统。在我认为, B端系统远远不止能用就性, 好用是必须,“乐”用是追求,提升用户工作的幸福感,应该也是B端产品经理要考虑的。

这篇文章不谈具体工作内容，只谈想法和感受。一年前对产品工作初涉猎，整理了一个能力模型，现在拿出来比比，谈谈初心，是不是朝着最开始的路在走，有没有像龟兔赛跑的兔子一样在半路睡大觉，或者岔到别的小路上去了，有没有达成过几个小目标，或者收获过几个项目果实。

欢迎有观点的伙伴来撩,微信: yyl210210210