在当今快速发展的互联网行业,产品经理的角色变得越来越复杂。本文详细分析了产品经理在不同阶段的工作重点,以及如何与市场、运营、技术和设计等部门协作,共同推动产品从概念到市场的全过程。
凯文·费奇是漫威影业掌舵人。
可能很多人都忘记了,在他统领之前,超英电影曾大多是票房毒药。
今天聊这个,那我可就不困了。
看今天的这个标题有多长,就知道我的怨念有多深。
从十几年前开始,年轻人们一批批的进入互联网这个行业。
一部分会编程的,做了程序员,另外那些不会编程的,就做了产品经理。
为什么做产品呢?因为能挣钱呀~!
所以,各种各样的人都进入到了产品经理这个行业。
没关系啊,英雄不问出处,大家都“年入百万”嘛~
也就造成了从业者如此的鱼龙混杂,千奇百怪。
(调侃下,不用太认真)
一、做好的产品经理:不仅仅只会做产品设计
↑我将以此图为大纲,帮助创业团队完善产品能力
今天这一篇,开始针对看板图的右边中间的:
产品设计能力
二、产品经理不能只做产品设计
我当然不认可,把产品经理的工作就完全等同于产品设计。
但从现实出发,貌似很多互联网从业者的认知,以及不及格产品经理的行为就是如此。
大家都在主动或被动的,仅执行产品设计的工作。
看看我的帮助创业团队做产品的产品能力看板,就能发现,只有产品设计能力,是产品经理可以独自完成的,其余都需要产品经理进行跨部门的合作。
1. 需求分析能力
需要联合运营部门、业务部门一起收集和分析需求,才能确定战略战术方向。
2. 流量承接能力
更是需要和上游的市场、BD部门,以及下游的运营部门联合成作战小组,才能最大程度的发挥产品的作用。
3. 产品设计能力
对于初进入产品领域的年轻产品经理来说的话,往往一开始接触到的就是在上级的安排下进行产品设计。
但要明白产品设计是果不是因,没有对需求的分析、对业务的了解,产品设计就只能成为对经典和竞品的致敬(也就是俗话说的抄~)。
4. 项目推进能力
更是跨部门的管理工作,需要以时间进度为核心,带领大家按时和保质的完成任务,对领导力和团队管理能力都有相当的要求。
5. 业务了解能力
更着重于道,也就是产品经理想要做好工作,必须要对所在的行业有深入的了解,并且有超越同行的认真,才能成为一个好的产品经理。
6. 团队管理能力
不用说了,这是高级产品经理必须要具备的能力。
产品经理的职责正在被切掉
大家听说过切香肠的理论吗?
现在也在产品经理这个行业中发生着。
不知从什么时候开始,产品经理的职责正在一块块被切掉:
- 需求分析能力,被市场部门、运营部门、用户体验部门拿走了。
- 流量承接能力,被运营部门把持着。
- 项目推进能力,有专业的项目经理操刀。
- 团队管理能力, HRD也有了越来越重的话语权。
- 甚至连产品设计能力,也被交互设计师分走了一部分工作。
- 所以,不少产品经理最终也不在乎业务了解能力了。
那么长此以往,产品经理还能剩下什么??
我们都知道,在国外的互联网行业中,并没有很明确的产品经理的岗位。
那是因为在国内的互联网发展初期,产品经理其实来源于BOSS的赋权,通过专业和全面的能力来代理了BOSS一部分的权责。
所以产品经理的发展,就和国外的路径有了那么一些区别,也就因为此,产品经理才会如此的耀眼。
虽然在今天,产品经理的职责被切走了不少,但优秀的产品经理反而更加抢手了,因为具备专业和全面的能力的人才,在现在和未来其实更为稀缺。
想要成为优秀的产品经理,必须要努力去多争取一些权责,获得实战的训练,这是非常重要的事情。
需要加油哦!
三、产品设计的要点就是对齐:和需求和实现分别对齐
产品设计的本质是什么?
本质上是需求部门(业务、销售、运营、BD等)和实现部门(研发)的一个连接器。
很多水平不足的产品经理上来就画线框图,东抄西抄抄,也不知道画的出发点是什么。
有没有充分的思考呢?能力是否能匹配呢?
后端上(逻辑端)上要和开发沟通。
前端上(应用端)上要和运营沟通。
1. 产品架构要和技术架构对齐
还是延续刚才的话题,很多产品经理上来就只会画线框图,把产品设计完全等同于前端设计。
其实属于没有搞清楚产品设计的底层逻辑。
能不能规划一下业务对象的信息结构?
会不会画一个完善的流程图?
会不会梳理状态位?
这些都是能够跟技术人员直接进行逻辑层面对话的部分,也是可以低分歧沟通的标准需求形式。
2. 产品路径要和运营路径对齐
任何稍微重要的产品,呈现在用户面前的时候,都需要运营去发力的。
所以用户在产品上的使用路径,同时也是运营的工作路径。
运营是否理解并接受?
运营是否便于开展工作?
运营是否有了相应方案的准备?
……
以上这些内容,我可以在未来再水一两篇,阐述得更细致一些。
四、产品设计的五层模型:和不同合作对象的产出物
关于产品设计的五层模型,可以去参考那本经典的产品教科书:
《用户体验的要素》
这本书有多经典,当然毋庸置疑,大家早已熟知这里面的内容。
但我想谈一些不太一样的地方。
这里面有两个核心诉求:
- 每一层的产出物是什么?
- 每一层的产出物应该和谁来进行沟通?
但要记住,永远的大前提:最终的服务对象是用户。
战略层
要讲明白为什么是要做这件事情,建议利用黄金圈法则来讲清楚问题的核心,就是why?
沟通对象是Boss,毕竟这是一个向Boss要资源的事情,项目组一开动,那就是大炮一响,黄金万两。
- 比如我们这个电商产品为什么要加入信用支付?
- 比如我们这个社交产品为什么要引入视频?
- 比如我们这个旅行产品为什么要更新点评维度?
这些大问题一定要说清楚前提。
注意要以用户的定性和定量需求出发,能拿出数据或需求报告出来才具有有说服力。
另外,虽然我这里写了产出物是PPT,但对于公司内部来说,尤其是创业公司,最好拿一个简单的文本就可以让大家开展讨论。
做PPT这个事情,真是太消耗内部资源了……
有空,结合之前的需求分析,我后面再水一篇。
范围层
Boss给资源了,项目组就也能成立了,下来就是战术层面的问题了。
目标就是攻下那个山头,那么各队友都要做怎样的协助呢?
聚起项目组,分解需求,然后向大家要资源、一起列计划:
- 开发的同学,前端、后端、测试都需要多少资源配合?
- 运营的同学,需要做什么样的工作?是参与到需求的提出,还是负责需求的验证?
- 设计的同学,需要怎样配合?
- 其他业务的同学,乃至法务、人力等等同学,是否需要协助?
这些都需要快速的厘清,并放置到同一张项目进展图中。
有空,针对这个,我再水一篇。
结构层
就是上面所说的:
信息结构、流程图、状态位,再加上策略。
这四样东西,组成了后端产品PRD的核心内容。
如上所说,产品架构要和技术架构对齐。
这些都是能够跟技术开发人员直接进行逻辑层面对话的部分,也是可以低分歧沟通的标准需求形式。
有空,必须水一篇。
框架层
前端框架层当然也跟技术开发人员相关,毕竟也是需要前端开发来帮助实现。
但也如上面所说,产品路径要和运营路径对齐。
所以为了保证产品在日后能够扩大影响力边界,运营人员的提前参与也是非常重要的。
有空,可以水一篇。
表现层
这部分就不用太多说了,主要还是由设计师来进行主导,分为视觉和交互两个方面。
确保视觉效果足够好看,同时要避免使用歧义。
这个比较简单,水不水都可以喽。
本文由 @觅云人 原创发布于人人都是产品经理。未经作者许可,禁止转载。
题图来自 Unsplash,基于CC0协议。