坦诚说，我刚开始做 B 端产品的时候，也有一种很强的幻觉。
我以为把需求想清楚。
把流程画明白。
把页面设计对。
再把 PRD 写扎实，事情就能往前推。
后来我才发现，不是这么回事。
很多 B 端产品做不动，不是因为你方案不够好。
也不是因为研发不配合。
更不是因为用户太难伺候。
真正卡住你的，往往是另一层东西：
- 谁有权拍板。
- 谁承担代价。
- 谁拿到好处。
- 谁嘴上支持，心里却不想动。
你看。
这已经不是单纯的产品问题了。
这是组织问题。
再说直白一点：
这就是政治。
很多人一听“政治”这两个字就紧张。
觉得是不是在说办公室斗争、站队、权谋。
不是。
我这里说的政治，不是阴谋。
是组织里非常真实的一套运行逻辑：
- 资源怎么分。
- 责任怎么落。
- 利益怎么变。
- 决策到底由谁说了算。
如果你做了 3 年 B 端产品，还在把工作理解成“收需求、出方案、推进上线”，你会越来越痛苦。
因为你会发现：
明明需求有价值。
明明流程也顺。
明明方案大家都说好。
可就是推不动。
为什么？
因为你以为自己在做产品。
其实你一直在组织博弈里做产品。
B 端产品最残酷的地方，是“用户”和“买单的人”往往不是一个人
这是很多人刚做 B 端时，最容易忽略的一层。
做 C 端的时候，逻辑相对简单一点。
谁用，谁感受。
谁感受强，谁就会决定留不留。
但 B 端不一样。
B 端产品里，常常至少有 3 类人：
- 真正天天在用的人
- 为结果负责的人
- 最后拍板买单的人
这 3 类人，经常不是同一个人。
于是问题就来了。
一线使用者想要的是顺手。
管理者想要的是可控。
老板想要的是 ROI。
IT 或采购想要的是风险低、集成稳、别惹麻烦。
你如果只从“用户体验”去理解 B 端，很容易掉进一个坑：
你做了一个一线用户很喜欢的东西。
但管理层根本不愿意推。
或者你做了一个老板觉得很有价值的方向。
但一线根本不愿意用。
这就是为什么很多 B 端产品经理做久了会发现：
你天天在做的，不只是功能取舍。
更是在做不同角色之间的利益平衡。
这就是政治的第一层。
不是谁压谁。
而是你必须先承认：
同一个需求，在不同角色眼里，根本不是同一件事。
很多“需求”，本质上根本不是产品需求，而是组织冲突的投影
这是我做 B 端之后最大的一个认知升级。
很多你表面上接到的需求，其实根本不是需求。
它是组织里的矛盾，被翻译成了一个产品问题。
比如这种场景你一定见过：
- 销售说：“客户强烈要求这个功能，不做就签不下来。”
- 交付说：“这个流程太复杂了，实施成本太高。”
- 运营说：“能不能加个权限开关，让我们灵活一点。”
- 管理层说：“为什么这个数据大家口径都不一致？”
如果你只站在产品视角看，很容易觉得这些都是功能点。
但你往深里拆，会发现很多根本不是。
它们背后对应的，常常是这些东西：
- 部门之间责任边界不清
- 指标归属混乱
- 管理口径不统一
- 一线流程和管理流程天然冲突
- 总部和区域、平台和业务线之间目标不一致
你加一个字段，问题没解决。
你做一个开关，问题也没解决。
你甚至上线一个新模块，可能只是把原来的组织矛盾包装得更复杂了。
这就是 B 端最折磨人的地方。
表面上，你在处理产品需求。
实际上，你在处理的是组织关系。
“很多 B 端需求之所以永远做不完，不是因为产品能力不够。
而是因为你一直在拿产品手段，硬接组织问题。”
这句话我建议你真的记一下。
因为它能解释很多你以前想不通的“为什么明明做了，问题还在”。
所以 B 端产品经理最重要的能力，根本不是画流程图
而是看清“谁在推动，谁在阻拦，谁在承担代价”
这才是 B 端产品经理真正的基本功。
很多人把 B 端产品经理理解成：
这些都对。
但都只是表层。
真正决定你能不能把事推下去的，是你有没有看清这 3 件事：
1. 谁真的想推动这件事
不是嘴上说支持的人。
而是真正会为这件事持续投入资源、持续追结果的人。
很多项目一开始看起来群情激奋。
真推进几周，你会发现真正上心的人就那么一两个。
你如果连真正的推动者都没找准，这个项目大概率会在中途失速。
2. 谁会被这件事改变利益结构
这是很多新手 PM 最容易忽略的地方。
一个新系统上线，一个流程被改，一条权限链路被重新定义。
你以为是在优化效率。
别人可能感受到的是：
- 我的空间变小了
- 我的解释权没了
- 我的灰度处理能力被拿掉了
- 以后出问题更容易算到我头上
你不理解这些隐性代价，就会觉得“为什么大家都不支持一个明明更高效的方案”。
因为效率从来不是组织里唯一的衡量标准。
很多时候，风险、控制权、责任归属，比效率更重要。
3. 谁会在项目推进里承担最大的实施代价
这点也特别现实。
很多 B 端方案逻辑上很好。
但真正落地的时候，代价全压在一线。
培训成本。
切换成本。
对账成本。
出错成本。
最后一线自然就抗拒。
不是因为他们落后。
而是因为他们在替一个“看起来正确”的方案承担最具体的麻烦。
如果你不把这个账算进去，你的产品逻辑再漂亮，也很难真落地。
我后来做 B 端产品，第一反应已经不是“这个功能怎么做”
而是先问 4 个问题
这是我后来给自己养成的习惯。
每次接到一个 B 端需求，我不再先问：
这个页面怎么设计。
这个流程怎么配置。
这个字段怎么定义。
我会先问 4 个问题。
1. 这件事表面上是谁提的，背后真正想推动的人是谁？
很多需求挂着某个部门的名义提出来。
但真正想推进的人，未必是那个部门。
有时候是老板在压。
有时候是另一个业务方在借力。
有时候只是某个中层在争资源。
你不搞清楚真实推动者是谁，后面你都不知道项目动力来自哪。
2. 这件事真正改变的，是什么权力和责任关系？
这个问题特别关键。
很多系统改造，表面上是在提升效率。
底层上是在重写规则。
谁可以看什么。
谁可以批什么。
谁能跳过流程。
谁必须留痕。
这本质上都是权力和责任的重新分配。
如果你只把它理解成产品功能，后面一定会吃亏。
3. 谁会因为这件事最痛？
不是谁受益最大。
而是谁在落地时最痛。
这个角色如果你不提前安顿好，项目一定卡。
很多 B 端项目最后死掉，不是死在价值不够大。
是死在有人觉得“这个方案让我太麻烦了”。
4. 如果不用产品手段，这个问题有没有可能本来就该靠管理解决？
这是我现在特别常问自己的一句。
因为很多 B 端产品最后都在给管理问题擦屁股。
口径不统一。
流程没定清。
责任边界不明。
组织协同失灵。
这些问题，不是都该靠产品系统来兜底。
你非要用系统去接，结果通常是产品越来越重，组织问题却一点没少。
为什么很多 B 端产品经理越做越累？
因为他一直在用“做产品”的方式，逃避“看组织”
这是我后来想明白的一句狠话。
很多 B 端产品经理越做越累，不是因为事情真的比 C 端多那么多。
而是因为他始终不愿意承认：
自己面对的很多难题，本质上不是产品问题。
承认这一点很难。
因为一旦承认了，你就会发现：
有些事不是你优化个流程就能解决。
有些事不是你把文档写得更细就能推进。
有些事甚至不是你产品能力再强一点就能搞定。
你必须开始读懂人。
读懂角色。
读懂部门之间的微妙关系。
读懂“为什么大家嘴上都说好，心里却不想动”。
很多产品经理不是不会做产品。
是不会看组织。
而在 B 端里，不会看组织，基本就等于不会做产品。
这不是悲观，这是 B 端产品真正的专业主义
我知道很多人会对“做政治”这句话不舒服。
觉得好像把产品工作讲脏了。
其实恰恰相反。
真正把 B 端产品做明白的人，都会慢慢接受一个事实：
组织博弈不是产品工作的污染。
它就是 B 端产品工作的组成部分。
你如果只会谈用户体验、流程优化、页面交互。
不会谈责任关系、决策路径、组织阻力、利益再分配。
你在 B 端里就一定会到处撞墙。
不是因为你不努力。
而是因为你只看到了冰山上面的那一层。
所以别再把“政治”理解成办公室宫斗了。
我这里说的政治，是一种更成熟的现实感：
你终于知道，一个 B 端产品能不能成，不只取决于功能做得好不好。
还取决于它放进组织之后，会碰到什么样的力量。
最后说一句
做了 3 年 B 端产品，我越来越觉得：
你以为自己天天在做需求、画流程、推项目。
其实你真正天天在做的，是另一件事：
在组织关系里，为一个产品找到能活下去的路径。
这条路径里，当然有产品能力。
但也一定有利益、责任、资源、节奏、话语权。
这就是为什么 B 端产品很难。
也为什么它一旦做明白，会让你对产品这件事有完全不一样的理解。
“B 端产品的本质，不是把流程搬进系统。
而是把组织里的博弈，翻译成一套还能运转的产品规则。”
如果你现在也在做 B 端产品，而且经常有一种感觉：
“明明方案没问题，怎么就是推不动。”
你下次可以先别急着改方案。
先问一句：
我现在面对的，到底是产品问题，还是组织问题？
这个问题一旦问对，你后面很多动作都会不一样。
发表于 3 天前
|
查看: 7|
回复: 0
