To B产品经理的光环背后，暗藏着组织政治的角力场。当完美的技术方案遇上微妙的权力博弈，真正的挑战才刚开始。本文通过真实案例揭示To B产品设计中那些不可言说的政治法则，教你如何在利益再分配与权力平衡中寻找产品落地的生存空间。
我刚入行To B产品时，以为自己的工作就是用技术解决业务问题。我会认真画流程图，设计用户界面，计算ROI回报率——这些是工程思维，是确定性世界的法则。
直到我在一个客户现场看到这样一幕：一个技术完美、能够每年节省300万成本的系统，因为“会影响采购部的审批权限”被搁置了。
那一刻我明白：在To B领域，最好的技术方案常常输给最微妙的权力关系。
每个To B产品经理都应该学会的第一个政治学原理是：在一个组织中，“价值”不是客观存在的，而是由权力定义的。
这听起来残酷，但这是现实。
我曾参与过一个制造企业MES系统的项目。从工程学角度看，最合理的方案是打通从接单到交付的全流程数据。但当我们提出方案时：
而支持这个方案的只有一个人——老板。
最后的结果是：我们只上线了老板最关心的生产进度看板，数据打通只做到“足够老板看到他想看的”程度。
这就是政治学的现实：产品的功能边界，不取决于技术上能做到什么，而取决于组织内允许你做什么。
工程师看系统架构图，政治家看组织架构图。优秀的To B产品经理两者都要看，但后者更重要。
每个客户组织都是一张独特的“权力拓扑图”：
在有些企业，采购部是实际上的“小国务院”，任何系统都要过他们这一关；在另一些企业，IT部门可能只是后勤支持，而业务部门才是话事人。
我学到的经验是：进入客户现场第一件事，不是问“你们的业务流程是什么”，而是观察“你们公司的决策是怎么做出的”。
曾经有一个金融客户，我们按照标准的项目流程推进：调研需求、出方案、评审。但在第三次评审时，一位一直沉默的副总裁提出了一个看似无关紧要的修改意见，整个方案被推翻重来。
后来才知道：这位副总裁是CEO的大学同学，也是实际上的“二把手”。
政治学洞察：永远要找到那个“不在组织架构图上的关键人物”。
每个新系统的引入，都是一次组织内部利益的重新分配。明白这一点，你就明白了为什么有的项目阻力重重。
我总结了一个“To B产品利益再分配模型”：
一个真实的案例：我们为一家零售企业做库存管理系统，技术上可以做到自动补货预警。但采购经理强烈反对，理由是“机器没有经验”。
真正的原因是：自动补货系统会让他失去“紧急调货”这个展示能力的机会，也会让他与供应商的关系价值贬值。
最终，我们设计了一个“半自动”系统：系统给出建议，但最终决定权还在采购经理手里。技术上我们让步了，但政治上我们赢了——系统成功上线。
既然To B产品是政治实体，那么它的设计就必须有政治智慧。
同样的功能，不同的说法，效果天差地别：
不要试图一次性改变所有事情。政治改革家都懂这个道理：
第一阶段：只做数据可视化（不改变任何流程）
第二阶段：增加预警提示（开始影响行为）
第三阶段：推荐优化方案（引导决策）
第四阶段：自动执行（最终目标）
每一步都让相关方有适应的时间，让反对者有台阶可下。
好的政治不是零和博弈，而是创造性地找到共赢点：
即使实际上某方利益受损，也要在其他方面给予补偿。
做了十年To B产品，我发现最优秀的产品经理都有一些共同特质：
我现在的产品文档里，除了常规的需求描述和原型图，多了一个“利益相关方分析”板块：
这看起来不像产品文档，更像政治备忘录。
但这就是现代To B产品经理的生存现实：我们既是工程师，又是政治家；既要懂代码逻辑，又要懂人性逻辑；既要追求技术最优解，又要接受政治可行解。
最终，那些存活下来并真正产生价值的产品，往往不是技术最先进的，而是最懂得如何在组织政治中寻找生存空间的。
当你下次设计一个To B产品功能时，不妨问自己两个问题：
在这两个问题之间找到平衡点，才是To B产品经理的真正功力。
本文由 @Alex的荒诞产品观 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。