起点学院课程

我的B端产品经理工作流

40 评论 1.5万 浏览 253 收藏 25 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

相对于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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 例如我一直在维护的一个WIKI叫做WMS业务逻辑和规则
    ——————————————————————
    真想借鉴一下你的这个wiki/(ㄒoㄒ)/~~

    回复
    1. 这个其实更多的内部逻辑的一些备忘,每家公司的业务都不一样,所以你借鉴也不是很能解决你的问题。做WMS核心点还是要抓住一些基础的核心点,例如拣货,复核,库位管理,库存等,其他的慢慢地扩散迭代就好了,如果有需要的话可以加好友沟通嘛。具体可以看一下公众号的联系方式,这里好像会屏蔽关键词。

      回复
  2. 大写的六六六!五年开发,现在要干开发+产品的活儿,从0开始构建WMS系统(跨境电商),明天去沟通需求

    回复
  3. 首先赞楼主的总结,很详尽,可用性也很强,下面说一点自己的看法哈。

    B端产品或后台产品,从字面上分内工作是对靠前的产品和产品支持到位;

    从过程上讲,可以从对业务效率这个角度拎起再发散,
    包括需求调研过程中对前台业务的场景的还原、效率提升点的分析,评审过程中对该项目对效率提升价值的预期(最好可量化),产品架构分析中对核心流程与分支流程的定位,项目需求细分的轻重缓急;设计过程中,丰富后台弹药库(支撑逻辑中,中间件、独立功能等可复用部分)可能性的思考;
    开发过程中对项目管理理论的落地、风险的管理;测试或上线后,对于效率提升增量的总结等。

    每个细分过程其实都有很多可分析总结的,不过大部分B端/后台产品在企业内行使着支撑角色,方法论在圈子里露出的也少。

    而且不如C端/前端产品那么引人注意,后台产品的价值更需要产品同学自驱去梳理包装。

    回复
    1. 同意你的观点,里面有很多点都可以发散,否则产品兜来兜去也就那么点东西,大家早就看腻了。B端的方法论确实太少了,大家都没有可交流和可发散的机会和环境。

      回复
  4. 从18年底开始接触产品开发以来,都是B端的产品,
    你的经历和思考和我简直一模一样,担忧走成野路子,担忧成长太慢,担忧没有同行可以借鉴,
    也在一步步的探索之中,令我感到惭愧的是你可以把自己的想法和行为记录下来逐步修正,而我都是一直在脑子里徘徊,
    这篇文章对于刚入门产品,特别是B端产品的同学们很有借鉴作用,和PMP 以及工作实践结合起来,可以总结出适合自己的方法论和规范流程,
    以后有机会希望可以多交流

    回复
    1. 😀 我好像回复什么都有违禁词

      回复
    2. hhhh 我猜是SNS

      回复
  5. 写的特别好,受教了

    回复
  6. B端周期往往更长,所以流程来说整体更接近瀑布模式,而在调研和评审中会接入不同程度环来实现小范围修正。流程落实是会有差别,但是总体的思想还是根据现有的人力、物力、时间等方面,在加法堆砌的需求上做出初期目标,用减法来做MVP版本。个人认为理想的流程不是本身多完善,而是参与的每个角色都能物尽其用又不会感觉特别难受

    回复
    1. 同意,核心点确实不是流程多完善,而是每个流程和参与的角色都能物尽其用,到位。

      回复
  7. 典型常规产品经理的工作模式,但差不多不很正常?

    回复
    1. 嗯,差不多是正常的,但是也有差很多的,所以每个人的需求和关注点的会不一样,所以才需要沟通交流嘛

      回复
  8. 1.项目立项
    2.竞品分析
    3.业务调研,一般使用用例图获取功能性需求
    4.整理成流程图
    5.明确产品形态与需求列表
    6.绘制原型
    7.原型评审
    8.UI设计 开发 测试
    9.发布
    不断穿插各种新需求与需求变更

    回复
    1. 很相似哦

      回复
    2. 666

      回复
  9. 您梳理的产品研发流程实际上企业erp的实施流程类似,还是对B端产品孵化有很深的理解,B端产品是一个重流程、偏业务的工具。我是做大型erp项目管理出身,转产品经理3年,个人感觉B端产品更重要的是一种业务与软件工具的结合能力,产品经理需要理解业务,更要理解工具与业务相辅相成的关系,在这基础上把握好产品的范围,最终为B端业务赋能;

    回复
    1. 对的对的,其实哪怕都是说B端,也会有很多人接触的东西不一样,所以我这块只是我个人的所见所得。但是我认同您说的,业务和软件工具结合,其实就是开发一套工具来解决业务,提升效能。

      回复
    2. 我的思维模式更偏应用一些,更多考虑的是产品的实际应用成功和价值输出,对于实现过程我觉得你分析的没问题。但是现实中接触产品经理多了之后,发现很多人其实不清楚B端产品的定位,都纠结于功能的实现,被业务牵着走,变成需求运输机,做的产品只能叫功能集合;

      回复
    3. 说的太对了,做久了,在一个圈子里就会容易变成需求运输机,感觉每天把需求转为实际可以开发的内容就是产品的全部了,这个当然是很片面的。但是我也觉得这个状态是一个过程,每个人都应该从刚入门到需求处理机,运输机这个过程成长,然后到了一定的程度之后,再考虑产品的价值,经济,市场的局势,商业的应用等。否则上来就因为一个按钮大谈用户转化,商业逻辑什么的,显得也很轻浮。

      回复
    4. 666

      回复
  10. 同行

    回复
  11. 项目立项更多的是得到上级的支持,产品宣讲更多的是让关联同事了解吧

    回复
    1. 是的,往往很多时候要做什么项目基本都是上级提出的,立项更多的是有点政治意味,为自己的项目争取资源和确认地位;而产品宣讲一方面是让相关方来参与产品的开发生命周期,另外一方面也为了让更多的同事了解你在做什么,这个项目的存在等,也可以争取资源。

      回复
  12. 画图建议还是用工具,复杂的图,老是修改,添加,再纸上根本没得效率,更不用说拿着和别人讨论讲解。

    回复
    1. 这个地方我没有阐述清楚,我的意思是初稿用纸和笔,最后成品肯定想用工具,我一般最后用visio定稿。所以这个地方可能给你带来误解了。

      回复
  13. 非常清晰!!!!!受益了

    回复
    1. 受教了

      回复
    2. 666

      回复
  14. 产品宣讲,应该是团队内部的宣讲,用来传递一些信息内容,便于团队对项目的理解,有些项目是分为不同子团队来实现的,视具体情况而定

    回复
  15. 写的很不错,有一个清晰工作流,就不会太拖延,不然感觉每一步没有边界~

    回复
    1. 是的,有流程制度就会有约束力

      回复
  16. good

    回复
    1. 感谢支持。

      回复
  17. 1.需求调研,竞品分析(一般没有,toG)
    2.编写立项报告 PPT 预算表,评审
    3.绘制流程图 信息框架图
    4.绘制原型
    5.原型评审
    6.UI设计 开发 测试
    7.编写标案 报价
    8.发布
    9.投标
    10.中标 了解本地化需求
    11.再循环

    回复
    1. 😉 很多流程都会有相似性,你这个也很棒。

      回复
    2. 这个相对来说,从流程这块比你那合理,立项之前先要理顺需求

      回复
    3. 也有道理,各个公司和环境不一样,按我这边接触到的,我们的立项都是因为业务驱动或者市场行为驱动,可以简单理解为,这个项目必须做,而调研可以前也可以后,我接触到的比较多的都是后的。而且立项这个事情,绝大多数人遇到的都少,毕竟从0开始做一款产品的机会还是少。

      回复
    4. 没有需求,就没办法去估算工作量,也没法去估算费用,如果只是大概的估算,很有可能会导致项目延期。这里面还有很多东西,比如需求的优先级,迭代计划,什么时候能上线那些功能。

      回复
    5. 66

      回复