立即登录 关于B端产品经理的工作流程和方法论，网上能看到的系统讨论其实不多。偶尔有一两篇，也常常只盯着某个环节细讲，像盲人摸象，始终缺一张完整的拼图。所以这几年借着实际做项目的体会，我把自己梳理出来的一套东西摊开，跟大家聊聊。
2020年1月，快过年的那几天，我在脉脉上刷到一位同行分享的图，叫《我了解到的B端产品经理的工作流》。当时一看，很多步骤跟我的日常操作高度重合，顺手就点了个赞，存了下来。心里一直惦记着，什么时候把这张图里的知识点掰开揉碎，再掺进自己的理解，好好整理一下。
但人嘛，总是这样。帕金森定律说得一点没错，你要不给一件事定个截止日期，它就会无限期地往后拖，直到把其他所有事的时间都挤占干净。最后能留给它的，也就剩一点可怜的边角料。所以趁着这阵子还有点热情，我赶紧把这个内容弄了出来。
下面这张重绘过的高清版长图，就是梳理后的结果。原作者是谁已经无从考证了，只能说摘自脉脉。如果你对里面提到的工作流感兴趣，直接长按保存就好。
说起来，为什么我对这件事这么在意？因为一开始，我心里是真的慌。
市面上能看到的B端产品方法论，大多很零散。尤其是那些刚入行、项目经验不多的产品新人，很容易被带偏。今天觉得别人说的降龙十八掌有道理，明天又去学乾坤大挪移，后天再捧一本九阴真经，结果练着练着就走火入魔了。问题出在哪儿？就出在“只知道是什么，不知道背后为什么是这样”。
去年上半年，我一直在有意识地调整自己的工作方式，努力让它往模式化、规范化的方向走。说白了，就是希望自己做的每一个决定、每一次推进，背后都能有一套逻辑或者原则做支撑。就像蚂蚁金服的 Ant Design，它能用一套完整的设计原则把 UI 规范讲得明明白白，B端产品同样需要一套能落地的流程，对内约束自己，对外方便协作。
可现实是，市面上关于B端产品的系统性资料少得可怜。要么反复嚼一些很浅的东西，要么缺少实战感和指导性，很难找到那种能贯穿全流程、有深度的内容。这让我在还没完全沉浸到B端领域的那段时间里，充满了担忧。
担心什么呢？担心走弯路，走成野路子。年轻人其实不怕走弯路，怕的是在弯路上一直绕，走到再也回不来的那天才猛然惊醒。担心没有体系，成长太慢。很多时候我们嘴上说讨厌框框架架，觉得把人框死，但如果连基本的框架都没有，怎么去培养一个人？后续又怎么让不同的人做出风格一致的产品？担心没法给自己定位——不清楚自己现在到底处在什么水平，是在浅海裸泳，还是已经被浪打湿了脚？没有比较，就不知道自己几斤几两。更担心的是将来带不了人。这个行业和职业都会延续很久，迟早要面对老人带新人的问题。如果自己连方法、认知都有问题，那带新人不就是带着一起翻车吗？
为这些事焦虑了一阵子之后，我突然明白了一件事：你不可能指望所有的知识都被人嚼碎了、喂到嘴边，还主动推给你。就算真有这种好事，也不一定就能砸到你头上。
想通以后，那段时间我读了很多B端产品相关的书和资料。李宽老师的《B端产品经理的必修课》给了我非常大的帮助，前后翻了好几遍，最后把核心知识消化掉，在 TAPD 的 Wiki 里，我开始动手编辑一份产品经理日常工作规范的内容，到现在还在不断补充。也是在那阵子，我无意中在 MOOC 网上发现了一门讲产品的课程，里面恰好提到了产品工作流的介绍，和我正在做的内容非常相似。这让我更确信，自己摸索出来的这条路，并不是脱轨的野路子，它是有章法的。
既然找不到直接能喂给自己的知识，那就找一个有营养的“大家伙”，自己先嚼一遍，再把它记录下来。将来能不能喂给别人不一定，但至少能给自己做个参照。去年我琢磨这个工作流的时候，心里是什么想法？走过了怎样的心路历程？一年过去了，现在的感受又有什么不同？正是带着这种意识，我开始有意识地记录平日里看到、想到的、跟产品相关的知识和方法。也就是从那时候起，我开始频繁更新博客、写公众号，也开始给“人人都是产品经理”投稿。
这一系列操作下来，收获是实实在在的。我不敢说自己的产品工作流有了什么脱胎换骨的提升，也不敢说对行业有了什么独到见解，更不敢在产品圈里高谈阔论。但有一点很明显——我感觉自己走在路上了，而且好像还是一条快车道。
一开始，我的工作流可能很简单，很多地方反复改过很多次。但没过多久我就发现，自己的工作模式和心态在发生变化。我给自己定下了一套规则和玩法，然后照着这套规则去走，日常的很多需求和项目，就能保持住一致的风格和系统性。这套东西在新人培养上也意外地好用，用它搭起培养框架，每个人出来都是一个模子，不会特别出彩，但也不会特别粗糙，因为基本功和底层基础已经打牢了。剩下的，就靠他们自己去打磨，自己去发力了。
上面铺垫了这么多，算是给自己卖个惨吧。因为很多时候，自学和成长真的就是挺惨的，没人教，挫折多，学不会，成长慢。但回头去看，也发现学习这事儿是有运气的。有时候，运气来了，你偶然学到一些延展出来的知识，可能就帮你打通了任督二脉。
最近流行一句毒鸡汤：“你永远赚不到超出你认知范围的钱，除非你靠运气。但是靠运气赚来的钱，最后往往又会凭实力亏掉。”学习倒不是这样。你不太可能学到超出认知范围的知识，但你是靠运气学到它们的。最坏的结果，也就是用不上，慢慢忘了，对自己没什么损失。反过来说，这些知识说不定会让你触类旁通，推开一扇探索新知识的大门。
我的B端产品之路，就是从这样一个认知范围之外的小知识点开始的，慢慢接触到更广、更全面的东西，然后那些知识又引导我走上了一条快车道。
到现在，我再来谈谈自己对B端产品工作流的一些看法。
首先是项目立项。一般是从0到1的项目才会用到，但说实话，能接触到从0到1的人并不多，所以这一块我没什么特别要补充的。按 PMP 的指导，项目立项报告是启动开工的必要输出，这一步省不了。
需求调研，这是一个老生常谈的话题了，概念很大，但B端和C端都需要做。我常用的方式，是先自己分析，拉出一个框架，准备好一些问题，然后用访谈的方式去收集需求。因为我目前做的业务，需求方基本都是公司内部的其他部门，即使有外部需求，也都能面对面或者微信沟通。至于网上常说的问卷调查、数据分析、行业研究，我基本就是访谈加竞品分析一把梭了。
产品宣讲这个环节，我其实有些不同的看法。按理说，在项目立项的时候，就应该做过产品宣讲了，甚至在立项之前，需求调研、行业分析、竞品分析这些工作就已经开始了。所以把宣讲单独拎出来作为一个环节，我觉得有点多余，或者说是一种负担。
竞品分析，我通常的做法是把它和需求调研组合在一起，形成一套组合拳。也就是边调研需求，边做竞品分析，一起推进。这和我自己的理解与操作顺序是一致的。
画用例图，这是一个很有意思的、带点鄙视链性质的东西。据我观察，大部分开发转行做产品，或者计算机相关专业出身的产品经理，会热衷于用用例图。而其他专业背景的产品经理，可能连 UML 都没听说过，更别说画了。所以鄙视链就成了这样：常用用例图的人，往下看不用的人。但说到底，工具嘛，适合自己团队的协作方式才是最重要的。