对B端产品经理来说，日常工作中的流程一般是什么呢？工作的时候又要注意哪些要点，避开哪些坑呢？笔者结合自己的实践经验为大家分享以上问题的答案。

经过了几个月的产品实习，感慨万千，十分想将自己的经验，或者说是经历分享给大家，一来想和广大产品新人共同进步，二来也希望能够从产品前辈处得到一些批评指正。

我进行的是面向B端的中台产品实习生，所以需要在熟悉公司业务的基础上，考虑产品实现的逻辑，产品的用户也是公司内部人员。所以我的经验分享也主要是从B端产品的角度来进行，当然我相信和C端产品也会有共通之处，比如在沟通、紧急事件处理等方面，是属于在日后各类工作中可以进行复用的经历。

文章将按照产品经理进行工作的大致流程进行叙述，架构如下：

一、需求挖掘与分析

二、产品方案的思考与撰写

三、产品方案评审

四、跟进开发进度直至验收上线

五、用户操作手册撰写

六、数据指标分析

七、复盘

八、其他Tips

关键词：需求辨别

B端产品的需求大多数直接来自于业务方，少部分可能是产品经理自主挖掘，尤其涉及到整体逻辑的重构或是一个全新的项目开展，往往是产品提出的需求。C端产品的需求基本上都要产品经理自主去挖掘，借助问卷调查、用户评论、数据埋点分析、竞品分析等方法。但无论是C端还是B端产品在遇到各类需求时，都需要具备需求辨别能力。良好的需求辨别能力能够让你迅速分辨出哪些是该做的需求，哪些是没必要的需求；哪些需求优先级更高，必须尽快实现，哪些需求可以暂放，后续慢慢实现等等。

在拿到一个需求时，至少要进行如下几方面思考：

需求的场景，为什么提出这样的需求，解决什么问题？

有多少用户有这样的需求，是否值得实现？

实现后能带来的什么样的收益？比如用户使用次数增多、人效提高等，并不仅仅指金钱收益。

如何实现这一需求，如何既能满足需求又能简化实现方式与过程？

这一需求是否对其他模块造成影响，影响的评估？

这一需求的优先级，实现的紧迫性？

在整个需求分析过程中，我们都要多角度思考，既要站在用户角度看问题，也要站在研发角度看问题，更要站在产品角度看问题。

要学会跳出来看问题，不能被用户提出的需求受限，我们要考虑一个需求优化的外延性和其他可能性，要比用户考虑的更前一步，不能只看眼前优化的点，要考虑前后变动，不同业务、产品之间的关联，无论是系统和APP都要具有一定的灵活性与柔性，才能更好的支撑后续的优化与改进。

产品经理要摒弃一些想当然的想法，比如不能用户希望实现的功能就一定实现，必须考虑必要性（合理性）、可行性、收益；比如不能开发说不能实现就不去尝试，尤其对于不太懂技术的产品来说，千万不要抱有这样的想法，无论是否真的能实现，我们都要提出自己的看法，进行质疑与沟通，不要害怕说错话被嘲笑，永远不说不表达，永远也不会有成长。

另外我们还需要将所有的需求进行梳理，借助表格的形式，生成需求池，对需求进行分类、描述优化内容、优先级判断、目前的实现状态记录等等。

借助需求池，我们能大致知道一个产品在迭代过程中优化了哪些需求，还有哪些需求没有实现，哪些需要我们尽快实现。

关于优先级的确认：

B端的需求优先级不单单是由产品经理来决定的，而是要根据当前的项目饱和状态、具体使用时间等和业务方共同确认。

一般来说会影响当前使用、线上bug、时间紧急的需求必然优先级会高一些，而单纯的没有影响使用并且只涉及到少部分人的需求，优先级可能会低一些，但是还是要根据具体情况灵活判断。

如果有些需求临近使用，优先级是可以自动提升的，这个也是需要相关的产品经理自己注意这些时间节点，不能等到用户提醒才想起这些需求，然后导致紧急开发上线或是只能再次搁置。

我们也可以借助时间管理中的四象限法则：重要且紧急、重要不紧急、紧急不重要、不紧急不重要，来对需求进行大致的分类，并确定优先级。

关于竞品分析：

做竞品分析是属于需求挖掘的一种，通过与竞品的对比，优势继续发扬，短板进行补足，互相竞争才有长足发展。