产品岗和需求岗像一对“异卵双胞胎”

3 评论 2353 浏览 11 收藏 10 分钟

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

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

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

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

一、确有很多相同

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

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

二、却有很多不同

1. 在工作内容上

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

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

2. 在团队组成上

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

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

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

3. 在企业类型上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

写在最后

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

 

公众号:不想延期了

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

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 产品&需求 日常相爱相杀 偶尔相亲相爱(doge

    来自福建 回复
  2. 认同,写的很真实,可以感受到你真诚的分享,很棒!

    来自广东 回复
    1. 感谢认可,也欢迎关注我的公众号“不想延期了”,会有其他方面真诚的分享,谢谢~

      来自河北 回复