在当今快速发展的互联网行业，产品经理的角色变得越来越复杂。本文详细分析了产品经理在不同阶段的工作重点，以及如何与市场、运营、技术和设计等部门协作，共同推动产品从概念到市场的全过程。

凯文·费奇是漫威影业掌舵人。

可能很多人都忘记了，在他统领之前，超英电影曾大多是票房毒药。

今天聊这个，那我可就不困了。

看今天的这个标题有多长，就知道我的怨念有多深。

从十几年前开始，年轻人们一批批的进入互联网这个行业。

一部分会编程的，做了程序员，另外那些不会编程的，就做了产品经理。

为什么做产品呢？因为能挣钱呀~！

所以，各种各样的人都进入到了产品经理这个行业。

没关系啊，英雄不问出处，大家都“年入百万”嘛~

也就造成了从业者如此的鱼龙混杂，千奇百怪。

（调侃下，不用太认真）

一、做好的产品经理：不仅仅只会做产品设计

↑我将以此图为大纲，帮助创业团队完善产品能力

今天这一篇，开始针对看板图的右边中间的：

产品设计能力

二、产品经理不能只做产品设计

我当然不认可，把产品经理的工作就完全等同于产品设计。

但从现实出发，貌似很多互联网从业者的认知，以及不及格产品经理的行为就是如此。

大家都在主动或被动的，仅执行产品设计的工作。

看看我的帮助创业团队做产品的产品能力看板，就能发现，只有产品设计能力，是产品经理可以独自完成的，其余都需要产品经理进行跨部门的合作。

1. 需求分析能力

需要联合运营部门、业务部门一起收集和分析需求，才能确定战略战术方向。

2. 流量承接能力

更是需要和上游的市场、BD部门，以及下游的运营部门联合成作战小组，才能最大程度的发挥产品的作用。

3. 产品设计能力

对于初进入产品领域的年轻产品经理来说的话，往往一开始接触到的就是在上级的安排下进行产品设计。

但要明白产品设计是果不是因，没有对需求的分析、对业务的了解，产品设计就只能成为对经典和竞品的致敬（也就是俗话说的抄~）。

4. 项目推进能力

更是跨部门的管理工作，需要以时间进度为核心，带领大家按时和保质的完成任务，对领导力和团队管理能力都有相当的要求。

5. 业务了解能力

更着重于道，也就是产品经理想要做好工作，必须要对所在的行业有深入的了解，并且有超越同行的认真，才能成为一个好的产品经理。

6. 团队管理能力

不用说了，这是高级产品经理必须要具备的能力。

产品经理的职责正在被切掉

大家听说过切香肠的理论吗？

现在也在产品经理这个行业中发生着。

不知从什么时候开始，产品经理的职责正在一块块被切掉：

1. 需求分析能力，被市场部门、运营部门、用户体验部门拿走了。
2. 流量承接能力，被运营部门把持着。
3. 项目推进能力，有专业的项目经理操刀。
4. 团队管理能力， HRD也有了越来越重的话语权。
5. 甚至连产品设计能力，也被交互设计师分走了一部分工作。
6. 所以，不少产品经理最终也不在乎业务了解能力了。

那么长此以往，产品经理还能剩下什么？？

我们都知道，在国外的互联网行业中，并没有很明确的产品经理的岗位。

那是因为在国内的互联网发展初期，产品经理其实来源于BOSS的赋权，通过专业和全面的能力来代理了BOSS一部分的权责。

所以产品经理的发展，就和国外的路径有了那么一些区别，也就因为此，产品经理才会如此的耀眼。

虽然在今天，产品经理的职责被切走了不少，但优秀的产品经理反而更加抢手了，因为具备专业和全面的能力的人才，在现在和未来其实更为稀缺。

想要成为优秀的产品经理，必须要努力去多争取一些权责，获得实战的训练，这是非常重要的事情。

需要加油哦！

三、产品设计的要点就是对齐：和需求和实现分别对齐

产品设计的本质是什么？

本质上是需求部门（业务、销售、运营、BD等）和实现部门（研发）的一个连接器。

很多水平不足的产品经理上来就画线框图，东抄西抄抄，也不知道画的出发点是什么。

有没有充分的思考呢？能力是否能匹配呢？

后端上（逻辑端）上要和开发沟通。

前端上（应用端）上要和运营沟通。

1. 产品架构要和技术架构对齐

还是延续刚才的话题，很多产品经理上来就只会画线框图，把产品设计完全等同于前端设计。

其实属于没有搞清楚产品设计的底层逻辑。

能不能规划一下业务对象的信息结构？

会不会画一个完善的流程图？

会不会梳理状态位？

这些都是能够跟技术人员直接进行逻辑层面对话的部分，也是可以低分歧沟通的标准需求形式。

2. 产品路径要和运营路径对齐

任何稍微重要的产品，呈现在用户面前的时候，都需要运营去发力的。

所以用户在产品上的使用路径，同时也是运营的工作路径。

运营是否理解并接受？

运营是否便于开展工作？

运营是否有了相应方案的准备？

……

以上这些内容，我可以在未来再水一两篇，阐述得更细致一些。

四、产品设计的五层模型：和不同合作对象的产出物

关于产品设计的五层模型，可以去参考那本经典的产品教科书：

《用户体验的要素》

这本书有多经典，当然毋庸置疑，大家早已熟知这里面的内容。

但我想谈一些不太一样的地方。

这里面有两个核心诉求：

1. 每一层的产出物是什么？
2. 每一层的产出物应该和谁来进行沟通？

但要记住，永远的大前提：最终的服务对象是用户。

战略层

要讲明白为什么是要做这件事情，建议利用黄金圈法则来讲清楚问题的核心，就是why？

沟通对象是Boss，毕竟这是一个向Boss要资源的事情，项目组一开动，那就是大炮一响，黄金万两。

• 比如我们这个电商产品为什么要加入信用支付？
• 比如我们这个社交产品为什么要引入视频？
• 比如我们这个旅行产品为什么要更新点评维度？

这些大问题一定要说清楚前提。

注意要以用户的定性和定量需求出发，能拿出数据或需求报告出来才具有有说服力。

另外，虽然我这里写了产出物是PPT，但对于公司内部来说，尤其是创业公司，最好拿一个简单的文本就可以让大家开展讨论。

做PPT这个事情，真是太消耗内部资源了……

有空，结合之前的需求分析，我后面再水一篇。

范围层

Boss给资源了，项目组就也能成立了，下来就是战术层面的问题了。

目标就是攻下那个山头，那么各队友都要做怎样的协助呢？

聚起项目组，分解需求，然后向大家要资源、一起列计划：

• 开发的同学，前端、后端、测试都需要多少资源配合？
• 运营的同学，需要做什么样的工作？是参与到需求的提出，还是负责需求的验证？
• 设计的同学，需要怎样配合？
• 其他业务的同学，乃至法务、人力等等同学，是否需要协助？

这些都需要快速的厘清，并放置到同一张项目进展图中。

有空，针对这个，我再水一篇。

结构层

就是上面所说的：

信息结构、流程图、状态位，再加上策略。

这四样东西，组成了后端产品PRD的核心内容。

如上所说，产品架构要和技术架构对齐。

这些都是能够跟技术开发人员直接进行逻辑层面对话的部分，也是可以低分歧沟通的标准需求形式。

有空，必须水一篇。

框架层

前端框架层当然也跟技术开发人员相关，毕竟也是需要前端开发来帮助实现。

但也如上面所说，产品路径要和运营路径对齐。

所以为了保证产品在日后能够扩大影响力边界，运营人员的提前参与也是非常重要的。

有空，可以水一篇。

表现层

这部分就不用太多说了，主要还是由设计师来进行主导，分为视觉和交互两个方面。

确保视觉效果足够好看，同时要避免使用歧义。

这个比较简单，水不水都可以喽。