个人总结B端产品工作流

背景：在工作之余的时候，照例学习一些产品经理相关的内容，突然看到一个图片，内容是《我领悟出的B端产品经理工作流》，其中有一些内容我还是比较认可的。所以基于这个图，和我这两年来的工作经验，我也想分享一下个人的B端产品工作流，也是对个人两年时间的思考和总结。

我的担忧

上面就是我提高在 脉脉 中看到的这个图，其实对于B端产品来说，涉及工作流或者是方法论的内容实在是太少，尤其是经历过项目不多和体会不深的初级产品经理来说，感觉别人说的都是对的。然后按照别人说的方法来，毫无逻辑可言，有时候自己都说服不了自己，并且不能形成自己的体系，只能沿用别人的方法，却不一定是适合自己的。究其原因还是没有理解透自己的岗位以及自己的职责。

工作的第一年，我经历了特别多的项目，而且很多项目都是从0-1的，并且接触到了很多企业用户，了解到他们的第一手信息，丰富了经验却没有丰富思维，做了很多造轮子的事，所以从今年开始我有意识的调整自己的工作状态。简化工作流程，养成“讲规矩”的好习惯，对所有需要做的工作首先确定规范。这样就可以保证我做的内容都是有一个自己的体系和原则在里面的。例如蚂蚁金服的Ant Design里面就有很大的篇幅去阐述他们的关于这套UI的理解和设计原则。B端产品也是一样，需要有一套行之有效的工作流，一方面约束自己，一方面快速协同他人。

但是市面上关于B端产品的内容太少了，或者说很多资料都是反反复复讲那一个点，而且都是比较浅显的内容，没有给人眼前一亮的感觉，缺乏了指导性，同时也缺少了全流程体系的内容。这意味着，在B端产品行业大部分人都是比较迷茫的，且没有方向的。包括我自己，也是比较焦虑和担忧的：

• 担忧走弯路，因为现在关于B端产品的内容比较少，而且相关有能力的产品经理也很少，所有很多时候都是需要靠自己摸索，但是需要摸索的时间很长，B端产品需要慢慢的熬，获取丰富的失败经验，才有可能走出一条自己的路。
• 担忧不成体系，很多时候我们都讨厌框架，因为一个框架中培养的人都是千篇一律的，但是如果没有框架，那么就没有标准化的东西，培养都可能成为问题。
• 担忧自我定位：很多时候我们都不知道自己的水平如何，不清楚自己能起多大的能量，更不了解这个工作经历，应该达到什么技能。
• 担忧为他人赋能：工作久了必然会出现老代新的情况，如果自己的理解和处理问题的方式都有问题，将无法为他人提供良好的成长环境，会出现严重错误。

担忧了一段时间发现，这些事情必须要通过时间的累计，不同程度的去失败，最终走出一条属于自己的路。因为就算有人可以把知识掰断了，揉碎了，主动送到你嘴里，你也不知道这是由什么东西做的。即便知道是什么做的，你也不可能做的出来。

走在路上

既然找不到别人掰开送到嘴里就知道的秘方，索性就自己尝试着如何做出属于自己的“美食”，并且把它记录下来。看能不能给别人做个参考，当作“菜谱”。并且也可以不断的审视自己，不停的修正。

感悟到了这个道理后，我开始记录一些日常对产品的感悟以及别人写的很好的文章。也就是从这个时候开始，我频繁的更新博客。

不能说对我的工作和业务有什么特别的提升，对行业的认知有什么独特的见解，更不能说自己对产品有什么高谈阔论。只能说对自己的提升非常巨大，会主动了解产品相关内容，进行总结。不会像以前一样看完即逝，并且会提取别人的内容，揉碎了，把它总结成自己的体系。

我制定的一系列方法一开始可能不是很完整和正确，也是会经常改来改去。但是，不久后我会发现整个工作模式和心态都发生了变化。我为自己制定了一套属于自己的规则，并且也努力遵守这种规则，让他形成一套属于自己的风格，让工作中的很多需求和项目都是保持住相同的体系。

我认为的B端产品工作流

上面铺垫很多，也是说一些内心深处的话。因为很多时候都是对自己的反思，批评和自我批评是最能快速进步的一种方式。工作时太繁忙，休息是太放松，所以不能完整的审视自己。需要通过这种机会来进行自我学习和进步。

好了，现在开始聊聊我上面看到的脉脉中B端产品经理的工作流，并且提出一些个人的见解和分析。

项目立项

项目立项一般来说都是从0到1的时候才用的上，但是很多项目都是从0到n的，遇到这种情况并不多，我第一年工作的时候一年做了7个从0开始的项目，真的太痛苦了，这一块没什么需要额外补充的，主要是需要写项目立项报告，好好思考下为什么要做这个项目，以及自己在这个项目中的定位和完成的目标。

需求调研

做产品基本上和需求挂钩了，但是需求调研是产品开发之前的准备工作，主要是为了帮助自己可能更好的理解自己要做的产品，梳理大致的需求内容，确定产品的主体结构。我自己对产品调研，一般是先分析好产品的主要功能，一般主要功能就是产品的一条主线轴，其他的功能都是围绕着这个主线轴来进行扩充的，如果发现有脱离主线轴的大需求，建议重开一条产品线。梳理出来后，开始进行调研，一般采用访谈的方式进行需求收集，因为做的都是B端的产品，需求方基本上都是其他部门或者是其他公司相关部门，所以最好的方式是面谈，就算其他公司的相关部门，也应该尽量去了解他们的实际业务场景。也可以电话沟通或者调查问卷以及市场行业报告等，一般比较少。

产品宣讲

这里我认为就有一点问题，应该来说在项目立项的时候就应该对产品进行宣讲了，让所有人理解产品才对这个项目有部分的了解，甚至在立项的时候就应该把需求调研、行业分析、竞品分析的工作一次或者两次做完，讲解的时候充分展示自己的想法，并且获取同事们的其他意见。

竞品分析

竞品分析一般和需求调研一起进行的，主要是需要了解竞争对手，了解整个行业，最主要的是需要挑好竞争对手，要配合市场现状、用户需求、功能模块、产品发展四个维度去比对和分析。分析其他产品的短板和优势，总结优势。

画用例图

画用例图最主要的就是你能理解所有的功能模型和流程，然后通过分解确定UML的主体，围绕着这个主体来画，新手最怕的就是想要广而全的画法。确定一种角色试着走通，超过这个角色的粒度就不需要描述，可以通过另外一个图来描述。

画系统流程图

流程图最主要的功能是帮助自己以及开发人员清晰的了解整个项目的流程，以及这个功能在流程中的数据流转情况，可以迅速的帮助别人了解整个功能的宏观情况，把握产品的脉络或者大纲。迅速拉近产品、项目以及“新人”之间的距离。

一般来说，我会画业务流程图和系统流程图。业务流程图主要的作用是说明这个功能在业务中如何实现闭关，走完流程。而系统流程图，则是侧重于描述系统或者各个模块中如何交互，形成关系脉络。而系统流程图也可以用泳道图来描述。

列功能清单

这一步我一般是通过思维导图来处理，一般称之为“产品功能结构图”，主要的功能帮助自己更清楚的理解产品，以防止自己在做完一个功能后在另外一个模块中又做了同样的功能，或者两个功能本来需要有数据流转结果忘记。对于自己梳理整个产品非常有帮助，可以做到功能的统一和逻辑的统一。

产品架构设计

对于B端来说，前后台的页面情况比较少，一般来说都是通过web新式展现，我也做过app和小程序，app因为需要手动更新，所以新功能需求不能很好的传达到整个公司，用户需要频繁的进行功能升级，影响了用户体验。小程序的话，如果是功能单一的产品，可以使用，但是一旦有复杂的功能和逻辑和数据量大的话运行就不是很好。

画信息结构图

功能结构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。功能模块可以根据具体情况分得大一点或小一点，分解得最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。（百度定义）用通俗的话来说， 功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图表。 一般和7一起搭配完成，功能清单列好了就可以直接分析功能粒度了。

画原型图

画原型图是产品的基础技能，只不过有时候根据日常工作需求会有不一样的方式来画，比如有手绘然后直接给设计师画出高保真原型图（这种流程一般用于敏捷开发，不推荐）。或者是产品画低保真原型图，然后过完评审后，UI出高保真图。亦或者是产品直接画出高保证图和交互逻辑。这三种模式比较常见，而且使用的工具也不尽相同。如果低保真的画比较推荐axure、xiaopiu、墨刀之类的产品原型工具。如果是画高保真的原型图可以使用figma，这种工具有个好处就是UI做出来后前开发就直接直接使用，包括其中的css、img文件等，省去了找像素、抠图等时间。

原型评审

原型评审主要作用就是把各个部门的人员拉过来，一起讨论你设计的产品需求有没有问题，通过他们不同的生产环境来分析产品的漏洞、可行性。一般需要产品人员自己对所有的问题提前了解，把各种需求情况统统考虑，准备充分后再开原型评审，这样就不会浪费大家的时间。

写PRD

prd实现的方式比较多，一般通过word来实现，但是就有一个问题，有时候开发纯看prd文档会有一种看不懂的感觉，因为没有其他方式进行说明，文字形式主观意识不强烈。那么就可以通过在原型图上面标注的方式，画流程图辅助说明的方式。多种方式结合起来，让开发可以最快时间理解，自己最快时间查找。

产品验收

产品验收在敏捷开发中叫做“迭代评审会议”，PO带上开发测试等，进行讲解演示产品的新功能，然后有疑问或者为解决的功能在最后讨论环节中提出，然后决定该功能的优先级。

一般这个环节根据公司的情况和业务场景来看，有些公司的业务或者系统适合这样的演示、评审，而有些又不是很适合。但是我的建议是，如果可以，还是尽量进行这样的环节，因为再华丽、再酷炫的产品，最后还是要落地来解决实际问题，而还没落地的时候就知道这个产品不行了，那为啥还要因为沉没成本而一直执拗地坚持下去呢。早发现，早治疗。

写操作手册

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

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

数据分析

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

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