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