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

我的B端产品经理工作流 | 人人都是产品经理 - 图1

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

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

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

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

我的B端产品经理工作流 | 人人都是产品经理 - 图2

01 我的担忧

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

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

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

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

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

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

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

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

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

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

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

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

我的B端产品经理工作流 | 人人都是产品经理 - 图3

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来做,但是我感觉还是用脑图的形式会好一点。

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

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

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

我的B端产品经理工作流 | 人人都是产品经理 - 图4

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

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协议