相对于C端来说，目前对于B端产品经理的工作流程、整体方法论的讨论还在少数，即使有也都是针对某一个细化部分进行展开，缺少从整体上去总结。于是笔者作为一个B端产品经理，就结合工作实践与认知，与大家分享一下B端产品经理工作流是怎么样的？

2020年1月份快过年的时候，我在脉脉上看到一个产品分享了一张图，内容为《我领悟出的B端产品经理工作流》，其中有些内容与我实际所做的有很多相似之处，所以我点了个赞、收藏了一波。事后一直想着能有机会对这个图中的知识点进行拆解，同时也加上一下自己的理解在里面。

根据帕金森定律，如果我们不给自己设定一个Deadline，那么做一件事的时间就会无限地占用掉别的事情的时间，以至于到最后我们只会留一点点时间来做这件事。

所以，趁着有点热情和动力在，赶紧补完这篇内容。

下面的长图是我重新梳理并重置的高清图版本，具体的作者不详，所以也不知道原图是谁做的，就只能说摘自脉脉了。如果你对里面提到的工作流感兴趣，可以直接长按保存长图到本地。

01 我的担忧

上面提到我是在脉脉上看到的这张图，其实对B端的产品来说关于工作流，方法论的文章比较少，尤其是经历项目不多或者是体会不深的初级产品同学，感觉别人说的工作流和方法论都对，都挺不错的。

结果自己来做的时候，毫无章法，今天是用降龙十八掌，明天是乾坤大挪移，后天就九阴真经走火入魔了。

究其原因，核心点还是因为知其然而不知其所以然。

去年上半年我一直在努力调整自己的工作方式，尽量走一种模式化，规范化的路子，这样可以确保我做的东西都是有一个体系或者是原则在里面的。

例如蚂蚁金服的Ant Design里面就有很大的篇幅去阐述关于这套UI的设计原则。

B端产品也一样，需要一套行之有效的工作流，一方面约束自己，一方面协同他人。

但是市面上关于B端产品这一块的资料太少了，或者说有很多资料都是反反复复将一些浅层的东西，缺乏实战性、指导性，同时还能兼顾一些全流程体系的知识。

这意味着，当我在B端这一块沉浸的时间不够的时候，我是充满担忧的，担忧的原因有：

• 担忧走弯路，变成野路子。因为年轻人不怕走弯路，就怕一直走弯路到回不了头的时候才醒悟；
• 担忧不成体系，成长太慢。很多时候我们都说讨厌框架，因为框架培养出来的人都千篇一律的，但是很多时候往往如果没有框架，那么可能培养都会成问题，更不用谈后续的千篇一律了；
• 担忧定位不了自己，不知道自己现在水平如何，是在浅海里裸泳呢？还是在波涛中弄潮？没有对比，就不知道自己是几斤几两；
• 担忧无法赋能他人，毕竟行业待久了，职业干久了，总是会面临老人带新人的问题，如果自己的理解和方式方法都有问题，到时候带新人，培养新人的时候不就翻车了么。

担忧了一段时间，发现好像这个事情就是没得解，因为不是所有的知识都是有人嚼碎，加料，再主动推送给你，即使有这样的知识，你也未必就能一击即中。

所以那段时间，我翻阅了大量的跟B端产品有关系的书籍和相关资料，其中李宽老师的《B端产品经理必修课》给了我很大的帮助，我还中途翻阅了好几遍，最后消化了一下核心的知识后，我开始在TAPD的WIKI中编辑产品经理日常工作规范，这个WIKI内容至今还在不断地完善补充中。

同时我也无意中在慕课网中找到了一个产品相关的课程，其中有提到关于产品工作流介绍，其中的内容与我正在做的十分相似。因此更加令我坚信，我自己所走的这条路，悟出的门道并不是与市场脱轨或者很“野生”，没有章法的。

02 走在路上

既然找不到那种嚼碎了就能直接喂给自己的知识，那就干脆找个有营养的大家伙先啃一下，然后自己嚼碎并记录下来。以后能不能投喂别人不知道，但是起码可以做一个参照。

去年的我是如何看待这个工作流程的？我当时的思路和心路历程是怎么样的？而一年过去了，当下的我，又是怎么样的一种感受？

感悟了这个道理之后，我就开始记录一些日常所见和所感悟的产品相关的知识和方法论。也就是从那个时候开始，我会频繁地更新博客，更新公众号，投稿《人人都是产品经理》，这一系列操作下来之后，收益颇丰。

不能说我的产品工作流有什么很特别的提升，对行业的认知有什么独特的见解，更不能说自己对产品这一行有什么高谈阔论。

但是，很明显地感受就是我感觉自己上道了，而且还是个快车道。

我制定的工作流一开始可能很简陋甚至有些东西我也是改来改去，多次打脸。可是，不久之后我就发现我的工作模式和心态变化了，我为自己制定了规则和玩法，也遵从这样的规则和玩法，这让我对日常工作的很多需求和项目都能保持一贯的风格和体系。

这种风格和体系还在培养新人的时候能显现出奇效，以此为基准搭建培养的框架。

大家都是一个模子出来的人，不会特别优秀，但是也不会特别粗糙，因为基础功和一些底层地基已经打牢固。剩下的就是，靠后天自己的打磨，自个儿成全自个儿。

03 我「看」B端产品工作流

上面铺垫了很多，算是给自己卖了一个惨。因为很多时候，自我学习和成长确实挺惨的，感觉很惨可能是因为自己没人教，受挫太多，总是学不会，成长的太慢。

但是回头看，又会发现，学习也有运气成分在里面的。有时候凭借运气，偶然间你就学到了某些拓展的知识，而这些可能就帮助你打通了任督二脉。

最近很火的一句毒鸡汤，叫做：

你永远赚不到超出你认知范围外的钱，除非你的运气很好，靠运气赚到了这些钱。但是，靠运气赚到的钱，最后往往也会凭实力亏掉。

但是，学习不是这样的，你学不会超出你认知范围外的知识，但是你靠运气学到了这些知识，最坏的结果就是你可能用不上就忘记了，但是对你自己却没有什么亏损。而往积极一点想，也许你学到的知识让你触类旁通还拓展了更多的知识，由此开启了你探索求知的大门。

而我的B端产品之路，也是从一个简单地认知之外的知识，然后慢慢地接触到了更广、更全面的知识，从而开启了我探索求知的大门，最后这些知识引领我走向了产品的快车道。

好的，现在就针对上面提到的B端产品经理工作流，来谈一下我自己对B端产品工作流的见解和看法。

1. 项目立项

项目立项一般来说都是从0到1的时候用的上的，但是往往很多时候大家能接触从0到1的情况并不多，所以这一块我也没啥特别要补充的。但是根据PMP的指导，项目立项报告应该算是启动开工的必要输出文件，所以这一块不能省。

2. 需求调研

这个似乎是老生常谈的一个话题了，需求调研也是一个蛮大的概念，但是显然无论是B端还是C端的产品，都需要进行需求调研。

而我常用的需求调研方法，一般是自己先分析然后给出一个框架，给出一些问题，然后采用访谈式收集需求。

因为目前我所做的业务，需求方基本上都是公司的其他部门，即使有非内部的需求，也可以当面沟通或者微信沟通。

至于网上常提到的，问卷调查、数据分析、行业调研等用的很少，基本上是靠访谈+竞品分析一把梭搞定的。

3. 产品宣讲

这个地方我有点不同的意见，按理说项目立项的时候其实就已经需要对产品进行宣讲了，甚至在项目立项前，就应该开始需求进行调研，行业分析，竞品分析等工作，所以这个点放在这里我觉得有点多余或者累赘了。

4. 竞品分析

刚刚提到第3点是多余的，所以我一般就是第2点和第4点一套组合拳，也就是需求调研+竞品分析一把梭。这个和我的理解是一致的，操作流程的顺序也是相当的。

5. 画用例图

用例图是一个存在鄙视链的东西，据我观察，大多数开发转行产品，或者是计算机相关专业的产品，会比较热衷于用这个东西；而非计算机相关专业的产品，也许UML都没有听过，更不用谈画用例图了。

所以，鄙视链是这样是：常用用例图的>知道用例图但是不怎么画的>不知道用例图更不会画的。

我会画用例图，但是画的不熟悉，画的很少，所以我应该是站在鄙视链中间的那一层。

而我自己的看法则是，工具只是手段，从结果来看，只要能表达清楚相关的信息，那其实都可以接受。UML这么多年的发展，自然有它的道理，但是未来如果被时代抛弃，也不必惊讶，毕竟谁也不能独领风骚数百年。

6. 画系统流程图

关于流程图的一个顿悟我之前发了一条朋友圈，主要想表达的意思就是，如果是初版流程图，建议用笔和纸，最好是用铅笔，还可以擦除。因为直接用Visio或者Axure来画的话，很容易受到软件本身的操作因素而干扰，例如对齐方式，文字大小，元素大小，以及配色等等。

对于我来说，我至今还没有找到什么好的Visio配色，画10次流程图可能有6~7次都在纠结配色和样式之类的操作因素，所以我很赞同画流程图的第一版，用纸和笔。

流程图对评审或者讲解产品有很大的帮助，因为可以让一个局外人迅速用上帝视角来俯瞰流程，把握产品的脉络或者大纲，然后对流程图加以部分用户故事，迅速就可以拉近产品、项目与让“新人”之间的距离。

当然，对于流程图来说，我一般会画两个，一个是业务流程图，一个是系统（交互）流程图。业务流程图侧重点在业务如何形成闭环，走完流程；而系统（交互）流程图，则侧重在系统或者各个模块如何交互，形成关系脉络。

7. 列功能清单

这一步我也会做，但是我把这一步称之为绘制产品功能结构图，一般是用Mindmanager来实现的，当然我也见过有人用Excel来做，但是我感觉还是用脑图的形式会好一点。

功能结构图和信息结构图又是一对剪不断理还乱的基佬关系，网上也有很多大佬对此进行了一大堆的剖析，最后还是没有谁说服谁。

之前我也因为这两个东西头疼了蛮久，因为真的是越想越觉得绕口，这里我直接搬出我认可的结论，来自《人人都是产品经理》的两篇文章：

• 功能结构图、信息结构图、结构图，你还傻傻分不清吗？（上）
• 功能结构图、信息结构图、结构图，你还傻傻分不清吗？（下）

感兴趣的朋友自己去搜索一下这两篇文章，而我想要表达的结论是这样是：

所以，我一般会先绘制产品功能结构图，然后再绘制产品信息结构图，而这两篇内容合到一起就是我最终需要的产品结构图，它也就是产品原型的简化表达。

8. 产品架构设计

对于B端产品来说，前后台页面存在的情况比较少，至于用什么载体，那绝大多数都是Web了。所以这个地方的架构设计和我平时用的工作流有出入，这一块的排序我也是觉得有一定的问题的。

9. 画信息结构图

刚刚在第7点提到了，我会先画完产品功能结构图，然后再画产品信息结构图，最后将两者合并在一起，就得到了产品结构图，也有人称之产品架构图。

10. 画原型

这个就不展开说了，因为涉及到大一点需求，有页面增加的或者调整的，基本上都要涉及到原型的绘制，而产品绘制原型就跟人吃饭喝水一样的平常，没啥特别的心得或者见解。前面都已经得到了产品结构图，再绘制原型，就是对一个抽象数据进行实体化的一个过程了。

11. 原型评审

这一块同上，也基本上是产品必做且常见的环节。需要注意的就是不要贸然开会，最好是准备充分再来召开评审会，否则很容易导致会议时间延长，或者是会议室被打成筛子，尴尬收场。

12. 写PRD

PRD我现在基本上不写纯文字版的了，基本上都是Axure+批注+思维导图+TAPD的方式来替代传统的PRD。

主要原因有以下几点：

• Word版本的PRD写起来又臭又长，而还不容易修改，更重要的是基本上开发不会看；
• 敏捷开发往往一个功能涉及多个迭代，而一个功能会从MVP到豪华跑车，其中会经历很久的时间，一份文档要描述清楚有点勉强，可能最开始是几页，到最后就几百页的小说一样了，维护和查看都很别扭；
• PRD维护成本高，编写时间长，不如面对面沟通来的效率快，而且目前走敏捷开发模式的团队居多；

当然，作为一个产品如果不写文档记录点什么，那肯定是偷懒和不负责任的表现。所以，针对这一块我的处理方式是这样的：

一般的需求都是用TAPD管理，涉及到比较大的功能和模块，会在Axure里面写上对应的逻辑和规则等；同时为了方便查阅和后续的培训等，我会按菜单或者页面，用WIKI来分别记录，例如我一直在维护的一个WIKI叫做WMS业务逻辑和规则，如果平时发现对之前设计的逻辑不记得或者模糊，那么看一下这个就能回忆起来为什么要这样做了。

13. 产品验收

产品验收环节是我做的不太到位的，用敏捷的方式来看，这个验收叫做迭代评审会议。PO带上开发测试等，然后给一众相关方讲解演示产品的新功能，然后有疑问的或者未解决的功能在最后讨论环节提出，最后决定是继续修补完成还是放在下一个迭代中完成。

对于这个环节，要结合公司和具体的业务场景来看，有些公司的业务或者系统适合这样的演示、评审，而有些又不是很适合。

但是我的建议是，如果可以，还是尽量进行这样的环节，因为再华丽、再酷炫的产品，最后还是要落地来解决实际问题，而还没落地的时候就知道这个产品不行了，那为啥还要因为沉没成本而一直执拗地坚持下去呢。早发现，早治疗。

14. 写操作手册

这一块算是B端产品的特色了，因为新功能上线，往往是因为解决了某些已知的问题或者是新出现的业务，而这个功能肯定是大家没用过，所以培训就很重要了。平时我有很大一部分时间就花在这里，因为海外仓库的培训还有时差，地域，语言等因素的困扰，并不是洒洒水写点先这个，再这个就完事的。

操作手册这一块可以考虑用一些便捷的工具来提高效率，缩短时间。例如用腾讯文档的协作功能，几个人在线共同维护一份手册；也可以考虑用一些视频截取的方式来替代传统的截图、标注，再文字说明的方式……

15. 数据分析

数据分析往往是后续迭代的动力来源之一，因为是骡子是马还是要拉出来遛一下才知道。上线之后，根据之前定好的指标进行验收，或者可以用数据埋点的方式查看效果是否达成。这一步也有很大的局限性，往往C端产品用的居多，B端产品要看具体业务来定，但是不管怎么样，产品发布上线了，并不是终点，往往是新一轮迭代的开始。

04 我的B端工作流速览

上面提到了我「看」B端工作流，其中有很多流程和我实际工作中的流程是吻合的，但是也有一些我会有不同意见或者不同的流程。于是这里我放一下我的日常工作流，做一个简单的速览。

1. 项目立项；
2. 需求调研&竞品分析；
3. 画用例图或业务分析图；
4. 产品主体框架评审与讨论，确认大框架没问题；
5. 绘制业务流程图和系统数据交互图；
6. 梳理产品功能结构图，确认功能项与产品边界；
7. 梳理产品信息结构图，确定细节与主体信息；
8. 画出原型图，做好相关批注和逻辑说明；
9. 开始评(si)审(bi) → 评审一次后修改与调整 → 继续评审 → 继续修改 → 看开发测试是否已清楚，若清楚则开始进入开发；
10. TAPD跟进需求，这一步可前可后，但是最终版肯定是评审完后再维护完成；
11. 跟进开发内容，可以协助解决困惑点，同时参与部分测试与验收；
12. 制定版本上线计划，召开相关的评审会议（验收会议），同时给出上线计划，并顺带找时间写好产品说明（操作）手册；
13. 产品上线，完成收尾工作，记录版本发布日志等；
14. 跟进上线结果，访谈用户，查看相应问题是否解决，是否完成指标等。

以上大概就是我作为一个B端产品，日常工作的流程速览内容了。基本上大一点的需求我都是按照这样的流程来走的，其中有几个点是我迭代过多次然后沉淀下来的，当然有些内容也会随着业务发展或者我个人能力的提升而优化，在此仅做一个抛砖引玉的作用罢了。

05 最后

这篇文章写了好长， 应该算是我写过最长最久的一篇文章了，甚至没有之一。

写这篇文章的初衷很简单，就是我在脉脉上看到了一个人分享的工作流竟然和我的很像，而我之前竟然很少看到类似的B端产品方面的内容，这让我感觉找到了知音一样。很多时候，产品聚集在一起可能谈的更多的是一些思维方式，或者某个问题怎么解决，亦或者是某本书怎么样的，很少会很具象地聊工作流的问题。

所以，我也想趁此机会，记录一下我的工作流，正不正确无所谓，关键是能给人一些启发或者帮助就好了。

上述内容，请大家辩证性对待，谢谢。

#专栏作家#

vitamin，微信公众号：皮酱叨逼叨；个人博客：只言片语 – 记录产品工作及思考的点滴；人人都是产品经理专栏作家。

中级产品经理，一年开发经验+两年产品经验。主导过在线教育类产品，目前是跨境电商供应链仓储物流产品一枚，欢迎勾搭，一同学习。

题图来自Unsplash，基于CC0协议