定制项目:产品总监绞肉机

1 评论 1962 浏览 1 收藏 10 分钟

本文深入探讨了定制项目对产品总监的挑战和影响,分析了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公司增长的主要方式。

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

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

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

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

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

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

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

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

本文由人人都是产品经理作者【ToB老人家】,微信公众号:【ToB老人家】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 讲的挺实际的,居然没人看吗?

    来自福建 回复