在做SaaS标准化产品卖不动时，转向定制化产品，但在做定制化过程中，如果思路和习惯调整不过来，容易导致项目的失败。本文将探讨SaaS产品定制化的思路以及如何玩转定制项目，希望对你有所帮助。

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

原因一方面是因为他能力突出——但更重要的是——他的领导刚被公司辞退了。

被辞退的原因是：原领导刚来，就被拖入定制项目的泥潭，导致没有做出业绩。

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

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

我很理解朋友的困境：他们公司之前是做SaaS的，标准化程度很高，产品团队和部门机制的搭建都是围绕标准产品。

但现在突然接定制项目了，就对团队提出了不一样的要求。

举个例子：SaaS产品经理在设计产品的时候往往会精雕细琢。

毕竟每一个功能都会有很多家企业使用，哪怕一个小失误也会导致很严重的问题。

但定制项目就不一样了。

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

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

更重要的是，标准产品的每一个功能都有大量企业来分摊研发成本，所以值得做好每一个细节。

而定制项目的大部分功能，都只有一家企业使用，加上现在定制项目的价格被压得很低，如果在功能研发上投入太多，那是铁定要亏钱的！

所以，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）”来获取利润的方法。

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

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

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

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

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

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

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

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

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

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

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

03 如何玩转定制项目

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

举个例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

只要建设好合理的机制，SaaS产品经理同样能做好定制项目；反之亦然。