做项目产品经理，还是做SaaS产品经理更容易？这个问题我纠结了很久。

早几年做项目的时候，碰到那种只让我照搬现有功能的客户，心里确实挺崩溃的。当时团队里不少人都觉得，坚决不做乙方，太憋屈了。

后来转去做SaaS，情况完全不一样了。甲方从一家变成几千家，别说要做一个新功能，就是页面上改个字段名，都得调研十几家客户，考虑大多数人的想法。

那段时间，我居然开始怀念做项目的日子。

现在一手做项目一手做SaaS，痛苦的还不止这些。最让人纠结的是：什么功能该放进主线版本，什么功能只能放在分支？定制功能能不能沉淀成通用产品？



与其绞尽脑汁搞定老板、搞定同事，不如先把客户搞定。这里有几个实用的思路：

向下兼容客户的思维

我最近常说，做工业产品太难了，至少比医疗行业难一倍。倒不是因为业务复杂或者系统功能多，关键是使用者的素质差距太大。

医生护士都是高等学历，虽然不懂软件，但沟通理解能力很强。客户买了软件后，线上交付基本没问题——远程培训、系统中内置操作手册和操作视频，大多数客户都能正常使用。

但工业场景的线上交付就困难得多。他们软件首年的实施费用，几乎和软件费用差不多。

去工厂培训那次，远比我想象的离谱。出发前做了PPT，结果完全没用上。面对一屋子的叔叔阿姨，让他们拿出手机登录账号，我在屏幕上演示，另一个同事在屏幕上指着：这个位置，点这里，然后提交。

第二天去现场，让他们一个一个操作给我们看，检查学会没有。结果各种理由就来了：手机没有流量、手机没电、手机没插卡……

按理说我们的文化水平比他们高，兼容他们的思维应该不是问题。但真正做起来才知道不容易。还是得花更多时间了解他们的业务和真实想法。

勇敢说NO

很多公司把“客户就是上帝”挂在嘴边。但这不意味着要无条件答应客户的所有要求。

尤其是软件领域，很少有客户真正清楚自己想要什么。他们的想法经常变，今天和明天不一样，上午和下午都不一样。

完全按照客户说的做，往往会陷入两种困境：围着客户群转，功能来回改，改来改去交不了期；或者客户不买账，反而说我们不专业——他们只是提想法，专业的方案应该我们来制定。

如果真的做不到，就清楚地告诉他们“NO”，然后一起讨论解决方案。但说实话，真正做不到的功能其实没那么多。

很多情况下，我们只是觉得需求不合理，或者性价比太低。这时候该怎么办？

不要轻易承诺

有时候客户会说：又得麻烦你们开发改造了，又要跳脚了。

你会怎么回复？



我以前会说：不麻烦，我们改。话一出口就后悔了——这会给客户造成错觉，好像我们做起来很简单，就像改个原型一样。久而久之，他们会认为这是理所当然的。

虽然我们给出了专业建议，但很多客户还是会坚持自己的想法。毕竟他们是用户，更关心实用性；而我们更在意软件的复杂性，操作越简单，实现起来往往越复杂。

我的做法是：明确告诉客户，如果坚持要这样做，我们可以做，但时间必须根据我们的评估来定，不能随便承诺下一个版本就能交付。

这种拉扯在项目型产品中特别常见。比如招标文件中写着“登录积分”，客户说要加这个功能，但沟通时我们理解的是提供积分接口。

最好在投标文件阶段就写清楚。但如果客户确实要加功能，通常我们会是小的改动。

不过要跟他说清楚：这个功能需要多少人、多少工作量，相当于多少成本。我们希望长期合作，这次可以免费，但下次再有类似情况，得加钱。

明确双方的权责边界

虽然是乙方，但我们追求的是合作把产品做好，而不是乙方委曲求全。



项目启动前列个清单，把双方需要提供的关键节点都列出来。对方必须指定一个统一的负责人来对接，涉及调研、硬件设备、网络等资源，要在规定时间点前提供给乙方。

最关键的是：需求必须要有最终确认的时间点。确认之后如果还要改，就放到下一阶段再处理。

写在最后

软件也是服务业，但我们追求的不是海底捞那种保姆式服务，而是专业的技术团队帮客户真正解决问题。



只有双方相互尊重、相互理解，项目才能做好。