我的B端产品经理工作流

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

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

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

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

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

01 我的担忧

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

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

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

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

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

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

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

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

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

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

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

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

02 走在路上

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

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

X了这个道理之后,我就开始记录一些曰常所见和所X的产品相关的知识和方fǎ论。也就是从那个时候开始,我会频繁地更新博客,更新X号,投稿《人人都是产品经理》,这一系列cāo作下来之后,收益颇丰。

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

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

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

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

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

03 我「看」B端产品工作liú

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

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

最近很火的一句dú基汤,叫做:

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

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

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

好的,现在就zhēn对上面提到的B端产品经理工作liú,来谈一下我自己对B端产品工作liú的见解和看fǎ。

1. 项目立项

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

2. 需qiú调研

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

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

因为目前我所做的X,需qiú方基本上都是X的其他部门,即使有非内部的需qiú,也可以当面沟通或者微信沟通。

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

3. 产品宣讲

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

4. 竞品分析

刚刚提到第X是多余的,所以我一般就是第2点和第4点一套组合拳,也就是需qiú调研+竞品分析一把梭。这个和我的理解是一致的,cāo作liú程的顺序也是相当的。

5. 画用例图

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

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

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

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

6. 画系统liú程图

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

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

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

当然,对于liú程图来说,我一般会画两个,一个是Xliú程图,一个是系统(交互)liú程图。Xliú程图侧重点在X如何形成闭环,走完liú程;而系统(交互)liú程图,则侧重在系统或者各个模块如何交互,形成关系脉络。

7. 列功能清单

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

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

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

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

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

8. 产品架构设计

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

9. 画信息结构图

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

10. 画原型

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

11. 原型评审

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

12. 写PRD

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

主要原因有以下几点:

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

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

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

13. 产品验收

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

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

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

14. 写cāo作手册

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

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

15. 数据分析

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

04 我的B端工作liú速览

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

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

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

05 最后

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

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

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

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

#专栏作家#

vitamin,微信X号:皮酱叨bī叨;个人博客:只言片语 – 记录产品工作及思考的点滴;人人都是产品经理专栏作家。

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 我的B端产品经理工作流 https://www.xiongfawang.com/3233.html

常见问题

相关文章

我的B端产品经理工作流-海报

分享本文封面