今すぐログイン 很多B端产品经理在职业发展中都经历过一个灵魂拷问：做定制项目好，还是做标准SaaS好？早年间做项目制，面对客户“照猫画虎”甚至外行指导内行的需求，大家往往苦不堪言，暗自发誓“绝不做乙方”。可后来转做SaaS，面对成百上千个客户，哪怕只是页面上改个字段名，都得做大量调研和权衡，生怕得罪了某家大客户。这时候，反而开始怀念做项目时的简单粗暴——客户说什么就是什么。
如今，不少产品经理同时兼顾项目交付与SaaS迭代。除了上述的纠结，更让人头疼的是：哪些功能上主线？哪些走分支？定制需求到底能不能沉淀为通用能力？其实，比起搞定老板和同事，搞定客户才是B端产品经理的终极修行。
做B端产品，首先要面对的是“向下兼容”的考验。做工业互联网的人常感慨，工业场景的落地难度比医疗、金融大得多。这倒不是业务逻辑有多复杂，而是用户群体的数字素养差距。医生护士虽然不懂代码，但学习能力强，买个SaaS软件，看看内置手册、听听远程培训就能上手。但工厂一线的情况完全不同。去现场交付时，精心准备的PPT往往毫无用处。面对车间里的大叔大妈，你得手把手教他们掏出手机、登录账号。可到了第二天考核，总有各种理由：手机没电了、没流量了、没带手机，甚至干脆不会操作。这时候你就会明白，所谓的“向下兼容”，绝不是居高临下地教他们怎么用，而是要真正沉入他们的业务场景。花更多时间去理解他们的工作习惯、操作环境甚至认知局限，把系统做得足够贴合实际，才是交付成功的唯一出路。
除了产品落地，日常的需求博弈同样让人头疼。很多公司奉行“客户就是上帝”，但在软件行业，这往往是个陷阱。很少有客户能清晰、准确地描述自己到底想要什么，想法还经常朝令夕改。如果一味盲从，项目要么在无休止的修改中延期，要么最终交付一个“四不像”，客户还会反过来指责你不够专业。因此，产品经理必须敢于说“不”。当然，这不是生硬地拒绝，而是当需求不合理或性价比极低时，清晰地告诉客户：“这个方案行不通，我们来探讨一下替代方案。”
比直接拒绝更常见的，是期望管理。客户有时会客气地说：“又要麻烦你们改一下了，会不会太折腾？”很多新手产品经理为了展现服务态度，会顺口接一句：“没事，不麻烦，我们改一下就行。”这其实是个大忌。这会给客户造成一种错觉，以为软件开发就像改Word文档一样简单。久而久之，他们会把无休止的变更视为理所当然。要知道，操作越简单的功能，背后的系统逻辑往往越复杂。面对这种情况，正确的做法是明确告知成本：“如果您坚持这个方案，我们可以做，但开发周期需要重新评估，可能无法赶上下个版本。”
在项目制产品中，这种博弈往往更加激烈。比如招标文件里写着“登录送积分”，客户以为是做个积分商城，而开发团队理解的是提供个积分接口。遇到这种模糊地带，如果客户非要加功能，作为乙方，我们通常会为了长期合作把小功能免费做了。但前提是，必须清楚地算一笔账：这个功能需要投入多少人力，折算成成本是多少。这次免单是出于情分，但如果后续还要加需求，就必须按合同增加预算。把丑话说在前面，反而能赢得尊重。
归根结底，虽然我们是乙方，但追求的是“合作打造好产品”，而不是毫无底线的弱势迁就。项目启动前，必须拉齐双方的权责。列出一份清晰的清单，明确关键节点、对接人、硬件与网络环境的就绪时间。最核心的是确立“需求最终确认时间点”。一旦签字确认，任何变更都应归入二期需求。这不是推诿，而是对项目负责。
软件行业本质上是服务业，但我们需要的绝不是海底捞那种只提供情绪价值的“保姆式服务”，而是用专业的技术和产品思维，切实帮客户解决业务痛点。只有建立在相互尊重、权责对等基础上的合作，项目才能真正落地生根。
