产品经理与甲方博弈：那些没人教你的实战心法

做产品经理这些年，我越来越体会到，最大的挑战从来不是画原型、写需求文档，而是如何与形形色色的客户周旋。乙方身份天然带来的被动感，让许多产品人在客户面前丧失了专业话语权，最终沦为“传声筒”——客户说什么就做什么，改来改去还不讨好。

如果你也在经历这种困境，或许该重新审视一下自己的定位和方法。

项目制与SaaS：两种不同的苦

入行之初，我做的是项目制产品。客户需求简单直接：要我做什么，我就做什么。当时心里经常犯嘀咕：这不就是复制粘贴功能吗？这样的产品经理，做起来有什么技术含量？

后来转做SaaS，才发现以前的苦算不了什么。SaaS模式下，一个产品面对的是成百上千个客户。哪怕只是页面字段名称的调整，都需要调研十几家客户，确保大多数人不反感。需求来源从“一个人”变成“一千个人”，每一个功能改动都可能是众口难调。

那时候反而开始怀念做项目的日子——至少客户说一是一，不用在几十个声音里找最大公约数。

现在一手做项目一手做SaaS，痛苦翻倍的同时，多了一个更棘手的问题：哪些功能该沉淀为主线产品，哪些该作为定制分支？定制功能做多了，如何避免重复造轮子？

答案只有一个：与其绞尽脑汁去向老板和同事争取资源，不如先把客户搞定。

向下兼容客户思维

行业内常说“工业产品比医疗产品难做一倍”，我一直不太服气。后来亲自去工厂跑了一趟，才明白难度不在业务复杂度，而在于使用者的素质差异。

医疗行业的医生、护士至少是高等教育背景。他们可能不懂软件，但沟通理解能力在线。软件交付后，一份操作手册加几个培训视频，大多数人能自己搞定。

工业场景完全不同。

去工厂前，我精心准备了一份PPT，计划现场培训两小时。到了现场才发现，完全用不上。

一间屋子里站着的，是连智能手机都不太熟练的叔叔阿姨。让他们拿出手机登录账号，我在屏幕上演示，同事在旁边用教鞭指着操作位置——就这样，第二天让他们独立操作，仍然状况百出：手机没电了、没装SIM卡、没流量、忘记账号。

说句心里话，我们的文化水平确实比他们高，但这不意味着我们可以轻松“兼容”他们的思维。真正的兼容，是花时间理解他们的工作场景、他们的困难、他们真正需要什么，而不是居高临下地去“培训”他们。

这一点上，很多产品经理（包括曾经的我）都犯了同一个错误：用互联网人的思维去揣测传统行业用户的需求。

勇敢说“不”

很多公司奉行“客户就是上帝”的信条。但在软件行业，无条件满足客户是最危险的陷阱。

一个残酷的真相是：大多数客户并不清楚自己真正想要什么。他们的需求经常变化——今天说的和明天说的可能完全相反，上午和下午的想法都能不一样。

如果你选择“客户说什么就做什么”，结局通常有两种：要么被功能变更拖死，项目永远无法交付；要么客户反过来吐槽：“你们太不专业了，我们提想法，你们应该给出专业的解决方案。”

所以，当需求明显不合理或性价比极低时，直接说“不”，然后一起讨论替代方案。这不是在推卸责任，恰恰是专业价值的体现。

当然，“不”要说得有技巧。

不要轻易承诺

有些客户特别喜欢说：“这个功能又要麻烦你们开发了，又要跳票了吧？”

早年我会回复：“不麻烦，我们改。”

后来发现，这样说只会给自己挖坑。客户会觉得修改很简单，不过是动动鼠标的事。时间一长，他们会把所有需求都当成“顺手的调整”，而当你说需要时间评估时，反而会被认为是在推诿。

正确的做法是：把开发成本透明化。

你可以告诉客户：“如果你坚持要做，我们可以做，但需要先评估开发周期，不能马上承诺交付时间。”这本质上是在设置预期边界。

这种拉锯在项目制产品中尤其常见。比如招标书里写的是“登录积分”，沟通时双方理解的是“提供积分接口”，但客户验收时可能要的是完整的积分商城功能。

我的经验是：能在招标阶段写清楚的，绝不留在实施阶段扯皮。如果客户中途增加功能，可以做，但要明确告知需要多少人天、对应多少成本。长期合作的前提下，一两个小功能可以免费，但频繁变更就必须重新核算成本。

权责要对等

乙方不等于弱势方。项目启动前，一定要列出清单，明确双方各自的职责和交付节点。

对方必须指定统一的对接负责人，涉及需求调研、硬件设备、网络环境等资源，必须在约定时间内提供给乙方。最重要的是：需求确认要有明确的时间节点。一旦确认后再有变更，调整到下一阶段处理。



这种做法不是推卸责任，而是保护双方。模糊的权责划分，最后伤害的是项目本身。

写在最后

软件本质是服务业，但这种服务应该是专业导向的，而不是海底捞式的保姆服务。

客户需要的不是一个唯唯诺诺的执行者，而是一个能真正解决问题、把控方向的合作伙伴。双方相互尊重、相互理解，项目才能顺畅推进。

产品经理的价值，不在于让客户满意，而在于让客户的产品成功。这两者之间，隔着专业二字。