本文深入探讨了定制项目对产品总监的挑战和影响，分析了SaaS产品经理在面对定制化需求时的困境和应对策略，引导读者理解定制化项目的战略价值，希望对你在产品管理道路上有所启发和帮助。

最近一个粉丝被“意外之喜”砸中：公司突然给他涨薪了30%，并升职成为产品部负责人。

而原因更是离谱：原领导刚被公司辞退了，不得已，只能让他顶上来。

其实原领导也是挺冤的，才入职没几个月，就被拖入定制项目的泥潭，整天都在处理项目的一堆烂事，导致没有做出成绩。

无独有偶，最近几位产品总监朋友也在向我诉苦。

公司的标准化产品卖不动了，为了维持公司运转，接了几个定制项目，结果把自己陷进去了，经常加班到深夜11点。

其中一个朋友因为受不了，已经离职走人了，CEO怎么劝都没用。而另一个朋友说自己也快了。

不由得感叹：定制项目真的是产品总监绞肉机！

大家可能会奇怪，定制项目存在这么多年了，为啥这些产品总监就受不了呢？

核心原因在于：这些朋友之前都是做SaaS的，产品标准化程度高，产品设计都是精雕细琢，强调做100分的精品。

但定制项目就不一样了。

反正只给一家企业使用，要考虑的点简化了很多。

而且只要不是大问题，修复起来都很简单，根本没有精雕细琢的必要。

所以，SaaS产品经理们在做定制项目的时候，如果思路和习惯调整不过来，就必然导致项目严重亏损。

而产品总监又不能眼睁睁看着项目失败，只能亲自投入进去，结果往往项目没做好，自己也搞崩溃了。

01 定制化是大势所趋

从B端软件诞生的那一天起，项目定制就是一个绕不开的话题。

我记得2007年左右，一个法国的Oracle顾问来我们项目拜访，他全程都在给客户CEO强调“一定要用标准功能，尽量不要二次开发”。

后来我才了解到，在欧美，B端软件定制化也是一个让IT公司“胆战心惊”的话题。

其实，Oracle系统的标准化已经做得不错了，无奈企业的个性化需求实在太多，结果仍然会有20%的定制功能。

而这20%的定制，则会产生80%的成本。

其实，相对中国企业来说，欧美企业对标准化功能的接受程度还是非常高的。这里面可能有两个方面的原因。

一是欧美企业员工对IT系统的熟悉度很高，面对复杂的操作，他们往往也能轻松应对。

当然了，这可能也和欧美企业重视员工培训有一定关系。

二是欧美国家的定制开发成本很高，毕竟那边不流行996，员工薪酬福利也很好。

相比之下，在中国，IT码农都已经被列为农民工了。

即便如此，欧美B端软件公司也不得不面对如何满足个性化需求的难题。

他们的应对方法和我们没什么不同：早期全代码定制，后期低代码定制。

比如，Salesforce早期做家得宝的CRM系统，根本不是通用的CRM系统，而是家装行业APP。

这种情况下，Salesforce直接把研发人员派驻到客户现场进行开发，这和纯定制项目没啥区别。

到后期，Salesforce的低代码平台逐步成熟，这些定制化需求就改用低代码来完成了。

还有一个例子，世界知名HR SaaS软件Workday在很长一段时间都是不支持定制开发的。

但是在2020年，Workday也正式推出了低代码平台：Extend。

由此可见，定制化是大势所趋。

特别是在中国，随着经济环境的变化，接受标准产品的中小企业的IT支出不断减少。

而大企业的个性化需求很多，项目定制更加难以避免。

因此，对我们来说，不是要不要定制的问题，而是如何定制的问题。

02 纯定制没有未来

我曾经说过：接定制项目找死，不接定制项目等死。

这句话多少有玩笑成分，但确实也说出了很多软件公司的无奈。

对于一直做定制项目的公司还好，反正已经适应了“卖人头”的模式，也早就掌握了如何通过所谓“高效运营（Ya Zha）”盈利的方法。

但是对于一直做标准产品的公司来说，如果没有在团队和机制上做好调整，接纯定制项目90%都是赔本买卖。

产品星球曾经邀请了一家头部SaaS公司高级产品总监来讲课，他分享了一个自己的亲身经历。

曾经他们为了树立标杆客户，接下了一个纯定制项目。

虽然项目金额很高，但也几乎投入公司所有研发资源。

关键是，项目交付结果并不理想，亏损得厉害。

后来他们对于纯定制项目就非常谨慎了。

这家头部SaaS公司的情况，绝对不是个例。

其实，即便是成熟的“纯定制”公司，项目利润也是低得可怜。

毕竟“纯定制”就是卖人头，这种商业模式几乎没有门槛，创业公司根本没有议价能力。

再加上现在很多纯定制项目都是层层分包，落到创业公司身上时只剩下骨头，不亏钱就算不错了。

所以，纯定制没有未来，不过是苟延残喘。

03 定制项目的战略价值

对于标准产品公司来说，虽然纯定制赚不到钱，但也有其战略意义。

举个例子：

某知名SaaS公司COO曾经在产品星球分享：他们最早是做办公协同SaaS的，但是因为大厂的入局，不得已放弃了这个方向。

在好几年的时间里，都找不到新的产品方向，以至于公司的融资都被烧光了。

后来他们接了一个纯定制项目，虽然金额有好几百万，不过并没有赚到钱。

但是，通过这个项目，他们发现这种定制项目的底层逻辑并不复杂，用无代码平台完全能够满足。

现在，这家SaaS公司已经浴火重生，成为中国知名的无代码平台公司。

也就是说，虽然定制项目本身不赚钱，但却是了解客户需求、探索新产品线的好机会。

特别是在未来，行业型SaaS将会成为中国SaaS的主要方向。

围绕着行业客户不断开拓新产品线，也将成为SaaS公司增长的主要方式。

在这种背景下，通过为行业客户定制软件，从而找到标准化产品的机会，是一种重要的产品策略。

那么，如果定制项目有其存在的必要，我们该如何利用其长处，并规避其短处呢？

我个人认为，关键是要把“标准产品团队”和“定制项目团队”做区隔。

比如，服务于标准产品的产品经理和研发团队，就按照固定频率迭代的模式推进工作，不受定制项目的影响。

而服务于定制项目的产品经理和研发团队，则应该汇报给项目经理，并受项目经理的管理。

很多人会担心“两套班子”会不会导致人力浪费。

其实，真正的浪费是低效的协同，以及由此导致的项目延期、客户拒绝付款。

另外，团队和机制区隔开，并不妨碍人才的相互流动。