作为一个B端产物司理，笔者将团结本身的事情实践和认知，与各人分享一下本身的B端产物司理的事情流以及每一个流程中详细的思考点和留意点，但愿能提供一个真正实用的事情流程，给与各人开导和思考。

看过一些总结B端产物司理事情流程的要领论或指南，总体来说步调差距不大，但大部门会较量空，汇报步调点到为止，缺少真正的实用性和开导。笔者作为一个B端产物司理，团结本身的事情实践和认知，与各人分享一下本身的B端产物司理的事情流以及每一个流程中详细的思考点和留意点，但愿能提供一个真正实用的事情流程，给与各人开导和思考。

作为一个转行的产物司理，最初看了许多先容产物司理事情流程的文章及书籍，为了辅佐本身能尽快上手，但发小大部门都是先容的很简朴，只给了步调可能概略要领，本身在实践进程中照做了，可是该踩的坑一个都没少，通过2年产物的事情经验以及本身的事情内容及行业性质，总结了本身的事情流，出格是每个步调中需要的思考点，出格合用于B端产物司理。

我的整体事情流程：

看起来步调会较量多，假如是大项目，根基每一步城市需要，小项目或优化类，按照实际需要做删减即可。其实整体事情流程和许多作者总结的事情流大同小异，如下图是别的一位作者写总结的B端事情流，也给了我一些开导，各人也可以去阅读一下。

摘自：人人都是产物司理文章《我的B端产物事情流》

那下面重点为各人具体先容，在我的每一个事情流步调中，需要留意的点以及思考偏向，这些内容也是本身在一次次项目进程及项目复盘中总结出来的，但愿给各人在实际事情中有必然开导。

01 收集需求

在业务型公司中，大部门业务提出需求其实会相比拟力单方面，许多没有具体思考就提出，可能仅办理一个姑且问题，因此在对业务提出的需求相同中，产物司理需要相识清楚需求本质，引导业务思考。主要需要收集以下信息，以下内容可以作为【产物需求收集表】来要求业务提交需求时填写，同时也是辅佐业务本身对需求举办思考。

需求范例：优化，bug，新成果等。

优先级：需求的紧张水平。

成果利用频率：这里也是之前本身碰着了坑，业务提出一个成果优化需求，做好上线今后，发明业务根基就不利用这个成果，导致上线后没有实际意义。因此在需求收集阶段，出格是针对某成果优化，必然要清楚业务对这个成果的利用频率。

需求配景或原因

需求目标/办理什么痛点/实现什么效益

需求详情：对需求的具体描写。

在收集需求阶段，若能相识到以上内容，说明该需求是业务仔细思考过的，同时也辅佐本身后头对该需求公道性的判定。

02 思考需求公道性

这一点在做产物初期没有意识到这个问题的重要性，导致很容易做着做着就酿成了需求输出东西，厥后做了许多项目复盘，才意识到业务许多提出的需求不公道，很姑且性，会导致系统成果臃肿，因此当收集完业务的需求后，必然要思考需求的公道性，只管让每个需求做的都有代价。主要思考点可以环绕一下几点：

复盘业务提出的需求内容：按照收集到的业务需求，具体相识业务诉求，查对其真实性及是否有逻辑斗嘴。

数据调研：许多需求或项目标提出，在启动之前都需要从现有数据长举办必然水平的阐明预估可达到的方针，同时也可看该成果的利用数据环境，思量其有没有优化代价。

需求内容的合用场景：许多业务会提一些非凡场景的优化可能非凡处理惩罚逻辑，产物做成果逻辑只管能统一化，制止非凡逻辑，后期会欠好打点，也容易留坑。

技能架构的影响：有的需求也许看起来很简朴，但其实技能实现很是巨大可能现有架构不支持，若碰着这种拿禁绝的环境可以先和开拓聊一下，简朴评估一下，这样对项目标定位也会更清晰。好比我碰着一个场景，业务提出但愿订单能归并发货，我认为也很公道，可以做，但厥后评审发明，我们此刻WMS系统架构是很难支持的，假如要做需要全面重整架构，很大的工程量，因此从头评估该项目，就先暂缓了。