作为一个B端产品经理，笔者将结合自己的工作实践和认知，与大家分享一下自己的B端产品经理的工作流以及每一个流程中具体的思考点和注意点，希望能提供一个真正实用的工作流程，给与大家启发和思考。

看过一些总结B端产品经理工作流程的方法论或指南，总体来说步骤差距不大，但大部分会比较空，告诉步骤点到为止，缺少真正的实用性和启发。笔者作为一个B端产品经理，结合自己的工作实践和认知，与大家分享一下自己的B端产品经理的工作流以及每一个流程中具体的思考点和注意点，希望能提供一个真正实用的工作流程，给与大家启发和思考。

作为一个转行的产品经理，最初看了很多介绍产品经理工作流程的文章及书籍，为了帮助自己能尽快上手，但发小大部分都是介绍的很简单，只给了步骤或者大体方法，自己在实践过程中照做了，但是该踩的坑一个都没少，通过2年产品的工作经历以及自己的工作内容及行业性质，总结了自己的工作流，特别是每个步骤中需要的思考点，特别适用于B端产品经理。

我的整体工作流程：

看起来步骤会比较多，如果是大项目，基本每一步都会需要，小项目或优化类，根据实际需要做删减即可。其实整体工作流程和很多作者总结的工作流大同小异，如下图是另外一位作者写总结的B端工作流，也给了我一些启发，大家也可以去阅读一下。

摘自：人人都是产品经理文章《我的B端产品工作流》

那下面重点为大家详细介绍，在我的每一个工作流步骤中，需要注意的点以及思考方向，这些内容也是自己在一次次项目过程及项目复盘中总结出来的，希望给大家在实际工作中有一定启发。

01 收集需求

在业务型公司中，大部分业务提出需求其实会相对比较片面，很多没有详细思考就提出，或者仅解决一个临时问题，因此在对业务提出的需求沟通中，产品经理需要了解清楚需求本质，引导业务思考。主要需要收集以下信息，以下内容可以作为【产品需求收集表】来要求业务提交需求时填写，同时也是帮助业务自己对需求进行思考。

• 需求类型：优化，bug，新功能等。
• 优先级：需求的紧急程度。
• 功能使用频率：这里也是之前自己遇到了坑，业务提出一个功能优化需求，做好上线以后，发现业务基本就不使用这个功能，导致上线后没有实际意义。因此在需求收集阶段，特别是针对某功能优化，一定要清楚业务对这个功能的使用频率。
• 需求背景或原因
• 需求目的/解决什么痛点/实现什么效益
• 需求详情：对需求的详细描述。

在收集需求阶段，若能了解到以上内容，说明该需求是业务仔细思考过的，同时也帮助自己后面对该需求合理性的判断。

02 思考需求合理性

这一点在做产品初期没有意识到这个问题的重要性，导致很容易做着做着就变成了需求输出工具，后来做了很多项目复盘，才意识到业务很多提出的需求不合理，很临时性，会导致系统功能臃肿，因此当收集完业务的需求后，一定要思考需求的合理性，尽量让每个需求做的都有价值。主要思考点可以围绕一下几点：

• 复盘业务提出的需求内容：根据收集到的业务需求，详细了解业务诉求，核对其真实性及是否有逻辑冲突。
• 数据调研：很多需求或项目的提出，在启动之前都需要从现有数据上进行一定程度的分析预估可到达的目标，同时也可看该功能的使用数据情况，考虑其有没有优化价值。
• 需求内容的适用场景：很多业务会提一些特殊场景的优化或者特殊处理逻辑，产品做功能逻辑尽量能统一化，避免特殊逻辑，后期会不好管理，也容易留坑。
• 技术架构的影响：有的需求也许看起来很简单，但其实技术实现非常复杂或者现有架构不支持，若遇到这种拿不准的情况可以先和开发聊一下，简单评估一下，这样对项目的定位也会更清晰。比如我遇到一个场景，业务提出希望订单能合并发货，我认为也很合理，可以做，但后来评审发现，我们现在WMS系统架构是很难支持的，如果要做需要全面重整架构，很大的工程量，因此重新评估该项目，就先暂缓了。
• 是否需要其他系统/部门的支撑：做B端产品，会涉及到大量相互关联的逻辑及流程，比如我做订单系统，会涉及到和商品系统、物流系统、仓储系统的各种对接。因此在该阶段，可以大致思考一下是否需要其他系统支持，若需要可以提前安排沟通，避免后面需要了才临时对接，这也是我自己血的教训。

03 项目初步立项

需求确定没问题，就可以做初步的立项了，大部分公司不会说非常要求这点，比如项目立项报告之类的，主要是产品自己要做对应的工作计划安排，后续更规范的项目安排会在评审通过，确定上线时间后发出，这个也和各公司团队的习惯有关，根据实际情况做调整即可。该阶段主要确定：

• 项目大体背景、目的、优先级、边界、内容
• 大体时间安排：主要是产品设计时间

04 需求调研

B端产品的需求调研相对C端的会简单一些，主要方式为：访谈+竞品。访谈需要提前列出自己希望获取的关键信息，可根据思考需求合理性阶段得出的结果和疑问点归纳得出，让需求调研访谈更具目的性和有效性。

B端竞品相对比较难获取到，我大部分会看一些第三方开发的ERP软件，去试用借鉴一下。

调研这个自己也还在摸索阶段，还有很多空间可以发挥，欢迎大家补充。

05 产品设计

说了这么多终于到产品设计环节了，其实B端产品如果只是说画原型的话，其实很简单，不会花很多时间。主要难点是在于整个产品方案的设计，逻辑的梳理以及各个模块考虑周全。下面是我在整体产品方案涉及中主要会考虑的点，以及会输出的内容，也是自己踩了很多坑总结下来的。

各种图

很多总结的产品经理的工作流程中，会说要需要画用例图，流程图，产品功能结构图，产品信息结构图等等。个人认为，这里没必要一定要按部就班每个都要画，更多输出这些图是帮助你梳理逻辑，想清楚即可，不用太苛求形式。我个人在这部分主要会比较常用到以下几种：

1）流程图

流程图是在B端流程产品设计中，最常用的东西。主要帮助理清楚各种关联逻辑。我常用的流程图主要是以下几种：

• 业务流程图：主要用于帮助理清楚业务的流程，也帮助自己更好的了解业务。
• 系统流程图：系统整体的操作流程。
• 数据流程图：这个一点很多产品容易忽视，大部分做到系统流程就完事了，但是产品想要做的更好，更深入，一定要清楚数据流。同时理清楚数据流，也能更好的帮助你做功能设计，以及考虑的更加全面。

再这个阶段还需要注意一点就是，不要仅限于你做的这个系统或者功能的流程，还需要考虑到其上游及下游的关联性，是否需要上游支持？下游是否有消费使用你产生的数据？是否需要一起联动修改？等等，都需要在产品设计中考虑完善，避免之后发现了才做临时处理。这点也是我之前做项目留下的刻骨铭心的教训，之前做OMS系统，没有考虑到商品系统以及物流仓储系统的关联性，导致上线后出现了很多问题，那个时候再来临时赶工处理。

2）产品信息结构/产品功能结构图

这两个图，我平时用的不多，主要是在大项目中使用到，大项目中主要通过这两个图，可以总结出你系统功能结构以及系统边界，帮助后续做产品功能设计。

需求清单

通过逻辑的梳理，能确定本期项目需要开发的内容及需求内容。需求内容可以明确罗列出来，帮助开发清晰知道需求点，也方便产品直接对着清单，做后面的产品设计，会非常清晰，这也是我最近做项目中总结出来的。注意，这里说的需求内容不是业务提出的需求点，而是产品通过前面总结，所确认出了本期项目的开发需求清单。

画产品原型

基本上通过上面一系列图及需求清单输出后，就可以开始画原型页面了。大部分B端产品，原型不需要高保真，只需要描述清晰，结构清楚即可，不用去苛求于画的很多交互，重要的是逻辑。

产品原型这里就不多说了，可以去收集一些公共的组件，在画的过程中可以提高很多效率。

画完原型后，一般的工作流程中就是要写PRD了，但实际大部分公司基本不太写PRD文档，主要原因是PRD问题太庞大不利于修改维护，而且开发基本不会仔细看，所以大部分方式是直接采用再axure+批注的方式。需要注意的是，这种方式有时原型页面会比较乱，堆砌了太多东西，很多箭头指来指去，一定要注意排版，让其简洁清晰可读性强。

数据处理方案

如果涉及到数据相关的功能，特别是有历史数据需要初始或者处理的，需要在产品设计阶段就要考虑到数据处理方案，该部分可和开发一同讨论确认。如果涉及到大量数据初始，没有处理好的话，会是非常非常大的坑。

上线后监控方案

这部分很多才开始刚做产品同学很少会想到在产品设计中包含该部分，经过很多次项目复盘后发现该部分在产品设计中若能提前想到的话，对后续项目复盘，监控，迭代很有作用。主要目的为：监控上线后功能运转正常；可以看业务的使用情况，便于数据统计；也可提前设计数据埋点，避免后续统计数据时没有对应记录。

一般监控分为两部分：第一种为上线后1-2周的跟踪方案，监控没问题后就可以停止了；第二种就是一些关键的信息或者数据可作为日常定时监控进行。一般监控采用钉钉报警。

这部分其实有很大空间可以聊，这里就简单提一下，主要给大家一定启发，思考更为全面。

06 产品评审

产品方案设计完成后就进入到评审阶段了，一般我会分为两种，第一做完方案后先和业务简单做个评审，确认一下设计的功能及操作流程，能满足业务需求，还有没有什么补充。确认之后再进行开发测试评审即可，评审通过后，确认开发和测试排期。

07 项目正式立项

我现在的团队工作方式会在评审通过后再进行正式的立项，主要通过项目邮件发出，通知到业务方及涉及到的人员。包含内容为：项目背景，目的，需求内容，最重要是开发测试排期时间以及上线时间。

若有风险或者关联性特别多的项目建议上线时间可以往后推预留1-3天，为未知风险做预留准备。

08 产品验收

开发和测试完成后，在正式上线前，一般会预留一天左右的时间做产品验收，这块我主要是看下整体功能以及一些核心逻辑，是否和产品设计一致，若有问题再上线前提前提出和解决。

09 上线通知和培训

项目上线后，需要发送上线通知，一般可通过邮件发送，主要包括上线时间（若有延期说明延期原因），上线安排，操作指南等，若功能比较复杂可安排做操作培训。

10 上线后跟踪

很多产品经理做项目，觉得上线后就完事了，以前我也是这样的，但其实并没有。上线后1-2周是非常关键的时间，这段时间主要关注点为：

• 上线后使用跟进：整体功能是否使用正常，bug反馈，业务运转是否通畅等。之前做需求，上线后就以为完事了，后来发现业务根本就没怎么用，没有推起来。假如上线后1-2周业务没有用起来的话，这个功能其实后面也很难再推起来了，所有上线后一定要推动业务使用，做好项目实施工作。
• 上线后数据及功能监控：这里就是说的对上线后监控方案的跟进，是否完成了预期的目标，把数据拿出来看是最有效的，同时也帮助产品做项目复盘及后期不断的迭代。

到这里，我的B端产品工作流就结束了，也许看起来很复杂，过程很多，但这些其实都是经过各种坑总结出来了。B端产品工作难点并不是产品功能设计，更多的是业务流程及逻辑的思考和对项目的不断复盘改进，才能更好地提升。上面这些点，大家可以看自己的实际工作情况做借鉴，希望能帮助大家在做项目时思考的更为全面。当然还有很多改进和补充的地方，欢迎大家评论一起讨论。

本文由 @youly 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议