编辑导语：产品经理在进行项目跟进以及客户交流时，需要兼顾到多方的利益，和想法；因为是乙方，所以很多需求还是要多加衡量，定好双方权益等；本文作者分享了关于做产品时如何应对客户的问题，我们一起来看一下。
做项目型产品经理好还是 SaaS 型产品经理好？
最早做产品经理是项目制，我觉得对着一个只会让我抄功能的客户，非常憋屈，当时我们很多人的想法是：再也不做乙方！
后来做 SaaS，发现甲方更多了，从 1 个变成了几千个，别说做一个功能，就是页面上改个字段的名称，都要调研 10 多家客户，至少兼顾大部分客户的想法。那时开始怀念做项目，反正客户说啥就是啥了。
现在一手做项目，一手做 SaaS，除了上面的痛苦，更多了一项：什么功能做主线上，什么功能做分支上，能否让定制化功能也沉淀成通用产品？
搞定客户，是一件比做产品设计，搞定老板，搞定同事更头痛的事，而我们大部分人是不擅长的。
有什么良招呢？
01 向下兼容客户思维
我最近一直说：做工业太难了，至少比医疗难一倍；不是业务复杂，也不是系统功能多，最关键的是人员素质差距。
医生和护士受过高等教育，虽然不懂软件，但是沟通起来理解力比较强；客户购买软件后，线上交付就行，客服通过远程培训，系统内置操作手册，操作视频，大部分客户就能用起来了。
但工业线上交付比较难，所以他们的软件首年的实施费和软件费差不多。
去工厂培训了一次，远比我想象的还恶劣；去之前做了一个PPT，结果没用上，看着一屋子的大爷大妈，让他们都把自己的手机拿出来，登上账号；我在屏幕上演示，另一个伙伴在屏幕上指，点这个，再点这个，再点提交就好了。
第二天再去现场，让他们一个个给我们操作一遍，看是否学会了；就有了各种我们想不到的理由：手机没带；没有流量；没电了；手机里没卡……
按理说我们的文化水平比他们高，可以向下兼容思维，当然做起来还是很不容易的；但指望客户改变，还不如我们多花时间了解业务，了解他们的想法。
02 勇敢说 NO
很多公司都信奉：顾客就是上帝。
但不意味着要无条件的答应客户所有的要求；特别是做软件，明确知道自己想要什么的客户很少，他们的想法大多就是今天一个，明天一个，甚至上午和下午的想法就不一样了。
客户说什么我们就做什么会导致2种情况：围着客户团团转，功能做了改，改了又改，交不了期了；客户并不买账，会说：我们又不是专业的，我们只是提想法，你们要出专业的方案。
如果真的做不了就明确的和他们说 “NO”，再一起探讨解决方案；但我们都知道真正做不了的功能不多，很多时候觉得需求不合理，或者实现起来性价比太低，这该怎么办呢？
03 要做也不爽快答应
有时客户会说：又要麻烦你们开发改了，他们又要跳起来了。
你会怎么回复？
我以前会说：不麻烦，我们改下就好了。很明显这样一来，会给客户一种我们做起来很简单的错觉，就像改改原型那么简单，时间长了，就会觉得理所当然了。
虽然我们给出了专业建议，很多客户还是会坚持自己的想法，毕竟他们才是使用方，我们更多考虑的是软件复杂性，他们会考虑实用性，但往往操作越简单，实现越复杂。
我就会和客户明确说明：功能做细做好和快不可兼得，如果你坚持要这样实现，我们也是可以的；但时间还要等我们评估下，不能答应你下个版本就上。
做项目型产品更容易发生这种扯皮的现象，比如说标书里写：登录积分，客户会说是做这个功能，但我们之前沟通时理解的是提供积分接口。
前期在标书里写清是最好的，但如果客户真的要加功能，小功能我们一般就带着做掉了。
但要明确告诉他：这个功能花费了多少人天，折合多少费用，我们希望长期合作，这次就不收取了，但是加其他功能的话要加费用的。
04 定好双方权责
我们虽然是乙方，但我们希望达成的是：合作把产品做好；而不是我们处于弱的一方，去迁就。
可以在项目启动前列一个清单，列上关键节点，双方需要提供的东西；对方一定要指定统一负责人来对接，涉及调研、硬件设备、网络之类的，要在指定时间点前提供给乙方。
最关键的点，要有一个需求最终确认时间点，确认后如果再要改，改动大的放在二期。
05 总结
做软件也是服务行业，但我们要的不是海底捞式的保姆服务，我们就是专业的技术团队，来帮助客户解决问题，是顾问的角色。
只有双方互相尊重，互相理解，才可能把项目做好。
#专栏作家#
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
