编辑导语：对于需求岗和产品岗，很多人都有感知，二者之间差异不大，工作内容也类似，但是就是说不清哪里不一样。作者针对于这两个岗位，分析二者差异，帮你理清它们的区别，帮助你更好选择。

我是从需求分析岗位逐渐转型的产品岗，转型之后也会经常支持交付团队的需求分析工作，最近两年在团队发展的过程中，产品和需求也同步在招聘。

很多人认为两个岗位的差异不大，或者不清楚具体差异体现在哪里，感觉工作内容也差不多。同时很多企业针对这两个岗位的定位也千奇百怪，有挂着产品的名头，做着需求分析的工作，斩不断理还乱。

所以今天想聊聊我对这两个岗位的看法，与大家一起探讨。

一、确有很多相同

需求和产品，平日的工作大部分时间都是在接需求、谈需求、写需求、讲需求、画原型（有些纯后台或弱渠道项目不涉及）、跟进度、做验收、应对突发情况等等。也都会或多或少做一些市场/用户调研、竞品分析、用户答疑等。这方面不再展开描述，因为本身大家对这些内容认知也是类似的。

所以这两个岗位可以说是“同根同源”。

二、却有很多不同

1. 在工作内容上

产品岗会更注重版本的迭代，产品愿景的规划，需要更注重用户体验，同时要结合多方因素进行优先级排期，维护需求池。有些行业或公司的产品岗，还需要兼顾运营、兼顾售前方案，同时还会引申出兼顾商业模式。当然有些是需要达到高级或总监级才会涉足的内容。

需求岗更注重解决方案的落地，功能的细节，对客户的引导，需求变更、需求蔓延等问题的控制力，对解决方案的开发工作量也有一定的要求（最小化可执行方案的设计）。同时和技术团队的沟通、对项目管理、软件工程的认知等方面，也会比产品岗更重要。

2. 在团队组成上

产品岗后续作为总监，可能会负责多个产品条线，或者同一个大产品条线下的多个应用模块，会管理多个产品经理、产品助理等，形成产品团队。在管理上要兼顾各个产品线的行业动向、场景规划、应用效果、研发资源配合等，还需要在团队内部工作分工、人员成长等方面做到因材施教、知人善任。

需求岗后续作为解决方案团队，可以一个人支持多个交付项目的需求分析工作。如果所做的业务有相似性，可以逐渐形成产品方案，孵化出产品团队；如果所做的业务相对独立，那这种模式其实在发展和效率上都会存在较大的瓶颈。团队管理者则更需要探索如何更好地支持多个交付项目，如何安排多任务并行及多人员协同，尤其会涉及远程协同。当然也有很多企业会把解决方案团队隶属到交付团队下，由交付总监统一调度。

有些长期稳定的交付项目，需求人员也是一直在一个项目中工作，这种机会其实可以更多向产品思维转变，深入了解行业、竞品、用户，在后期的项目迭代中引导客户。

3. 在企业类型上

需求岗位更多体现在外包类、解决方案类IT企业，在交付团队中设立需求岗进行定制化，并持续挖掘甲方的新需求（当然很多人力外包团队也在招产品经理，可实际工作内容更偏向需求分析）。

同时像我所在的公司和很多同类友商，虽然是以项目外包为主，但也都设立了研发团队，不断加大研发投入，进行标准化产品孵化，从而形成了一个又一个产品团队。

而像互联网自研团队，大多数会设立产品岗位而非需求岗，即便可能有些公司工作内容也是以需求分析为主。类比于：领导是你的甲方，研发团队是你所处的交付团队，这种情况产品岗和需求岗会有更多相同之处。

当然，我以上所说只是表明不同岗位的侧重点会有不同，并不代表某个能力在某个岗位下不重要，而且大家的工作经验不同、所处环境不同、行业不同，对这些“开放性”话题都会有自己独到的见解，千万不要把我的理解全然套在自己的实际情况下进行判断。

包容与接纳也是我们在工作中始终需要追求的一件事。

三、经验互通，把握底层能力

不同的岗位，收获的经验与能力可以互通。两条路都值得持续深耕，但要看准发展方向。

我们可以把产品岗、需求岗统称为“业务条线”，在业务线持续深耕，最终所需要的底层能力是类似的，无论在哪个岗位、哪个行业、处于怎样的团队，都需要刻意提升自己的业务底层能力。简单概括为结构化思维（解决方案能力）、同理心、聆听与表达、创新力、设计能力、文档能力、决策力等等，这些经验不仅可以互通，还能相互促进形成“良性的成长循环”。

因此我们在工作或者找工作时，我个人的建议是不要在意具体的岗位名称和职责，重点关注这份工作是否可以提升我们的业务底层能力，是否能够形成个人职业发展“良性的成长循环”，之后再去选择管理路线或高阶成长路线。

四、岗位之间的转变需要过程

我大概做了三年需求分析，然后转型产品。刚转型时一直在用需求的思维设计功能，考虑这个功能是否好实现，这样做工作量要多少，特色化功能如何满足等等，而缺少了对全局性、场景化、通用性、商业化等等多角度的思考，尤其是在用户体验及拓展性上存在很多不足。

而后当我作为产品成功发布第一个版本后，又去交付团队协助产品落地，即从产品岗转变为需求岗。同样会更多站在产品角度设计落地方案，缺少了对交付周期、交付成本的考虑，同时在收到客户很多“伪需求”或特色化需求时，缺少了需求人员应有的辨别与引导。

我想表达的观点就是，这两个看似很像的岗位，虽然“同根同源”，但最终的发展方向，进阶角度，思维模式等等都存在较大的区别，犹如一对“异卵双胞胎”。

如今我的产品小组也要不定期切换需求的身份协助交付进行实施，这个转变过程漫长而纠结。尤其是当你怀着产品心追求某个功能的完美时，又不得不进行现实的妥协。反之亦然，当你的需求无法得到团队或客户认可时，又不得不考虑产品后续的发展路径是否需要调整。其中的酸甜苦辣只有自己慢慢体会。

最终，只有真的在两个岗位上都达到一定的功力之后，才能在不同的环境下展现出合理的状态，做出相对正确的决定。

写在最后

业务条线的工作很有意思，也很有意义，希望我们每个人都能在职业发展和个人中远期规划上越走越好，越来越不可替代。我们的成果可能无法像文化革命或科技革命那样改变世界，但是可以用微创新的力量影响用户、促进行业发展，即便我们只是一朵浪花。

公众号：不想延期了

本文由 @不想延期了 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议。