B端产品经理和C端产品经理有什么区别？一个C端转B端两年的踩坑记录
去年三月我从一家做社区团购的公司离职，跳到一家做供应链SaaS的公司，团队规模不大，产研加起来三十来号人。面试的时候我说了一句“产品方法论是通用的”，现在回想，这大概是我过去三年说过最蠢的话。
入职第二周，我照C端的老习惯，在需求评审会上提了个优化：把下单按钮放大一点，颜色换成品牌橙。会议室安静了大概三秒，然后我们的实施顾问老周开口了——这个按钮，客户那边有1800个一线操作员，其中1200个人用的是键盘快捷键，他们根本不点这个按钮，他们按F9。
那天散会之后我在工位上坐了很久。不是受打击，是突然意识到，我脑子里那套“用户—场景—痛点”的东西，放到B端可能只值三成。
下面写的都是我自己撞过的墙，不代表什么行业规律，你要是正打算从C端转B端，可以当个参考。
一、错误的成本，最后是谁在付
C端产品做错一个决策，代价你自己扛。DAU掉几个点，A/B实验里那5%的负向，大不了回滚，用户骂两句第二天照用。你的错误边界基本等于你自己的KPI边界。
B端不是。我们有个客户是做生鲜供应链的，年营收四十多亿，用我们的系统跑采购审批。有一次我们顺手把一个金额字段的小数位从2位改成了0位——真的是顺手，看起来无关紧要，因为那个字段在页面上几乎不显示。结果客户月底对账，应付账款差了37万。
这个错误最后是我们两个研发、一个实施、一个客户成功，加上客户方三个人，花了一周时间写脚本回补数据。那一周里我没睡好过。
所以B端PM做决策的标准，很多时候不是“哪个更好用”，而是“哪个更不容易让客户的业务停摆”。这两种标准经常打架，而且后者通常赢。
二、需求到底从哪来
C端做需求，你手里有一堆工具：埋点、漏斗、NPS、用户访谈、A/B测试。数据会告诉你真相，哪怕用户嘴上说喜欢A，行为上全在点B，你信数据就行。
B端不一样。我统计过我们去年一年进入需求池的条目，大概470条。其中真正在3个以上客户身上同时出现的，只有60多条，不到13%。剩下的全是单客户定制诉求。
而这470条里，来源大致是三块：客户直接提的（往往带着“你们不做我们就考虑换供应商”的语气）、销售答应的（往往没跟你商量）、还有就是竞品有这个功能（客户通常只说半句，剩下半句靠你猜）。
这60多条通用需求里，最后有将近一半是靠配置解决的，不是靠开发。前提是你的系统一开始就留了足够的配置项。这一点我踩过坑：我们最早的组织架构只设计了5层，后来有个客户跟我说他们有17层——集团、区域、大区、城市、片区、门店……一路套下来。我们改了两版才撑住。
（写到这里发现自己前面说“C端方法论作废”太绝对了，其实是需要重装一套判断标准，不是全扔。）
我的看法是：B端PM的核心产出不是功能，是抽象层次和配置能力。 你能不能把客户的差异变成参数、把客户的共性变成数据结构，这件事比画原型重要得多。
三、我基本不画高保真原型了
做C端那会儿，一个页面我能磨两天，间距对到8px，交互状态切图切到开发者想打我。
现在我的PRD里，八成内容是表格和流程图：字段定义表、状态机、权限矩阵。原型就是Axure快速拉的低保真，把布局层级说清楚就完了。
原因很实际：B端的复杂点从来不在界面上，在数据流转和权限。一个审批流，“驳回之后能不能重新提交”这一个问题，就有七八种产品设计，每一种背后站着不同的客户诉求。你画得再好看，逻辑错了照样推翻重做。
四、迭代节奏完全是两个世界
C端是双周迭代，灰度10%，看数据，好就往上放量，不好就回滚，一晚上就能见到结果。
B端是季度大版本。而且版本发出去不等于客户会用——客户的升级窗口得看他们IT部门的排期。我们到现在还有客户在用两年前的版本，问就是运维说“不敢升”。
版本兼容也是一笔烂账。我们每个大版本都要维护至少三个历史版本的兼容逻辑，这块工作量大概占研发资源的15%左右，C端过来的PM基本不会把这个算进排期。
五、什么人适合转，什么人别转
我不太认同“人人都能做B端”这种说法。如果你下面几条能对上，转过去会比较顺：
- 能忍受一个需求从提出到上线走4个月
- 对业务流程的兴趣大过对用户心理的兴趣
- 愿意花时间读客户的行业资料，比如会计准则到底怎么规定的
- 不排斥跟实施、售前、客户成功这些人混在一起，他们才是你真正的信息源
反过来说，如果你最爽的时刻，是看到自己设计的交互让用户“哇”了一声，那还是待在C端吧。B端很少有这种时刻。
最后说点别的
写这些不是想说B端比C端高级，也不是反过来。这两条路对人的要求确实不一样：C端更像是在跟人的注意力做博弈，B端更像是在跟一个行业既有的秩序做适配。
转过来快两年，我现在开需求评审会前还是会紧张，但紧张的东西变了。以前怕被问“这个判断的数据支撑在哪”，现在怕被问“客户A和客户B的诉求直接冲突了，你选谁”。
后面这个问题，我到现在也没有标准答案。