导读：过去几年，我们走上了SaaS平台化之路，从一家项目型软件公司，逐步转向产品型公司，
事实上，做产品的难度，要数倍于做项目，产品化的难度随着我们平台租户数的增加而递增，
好的一面是，系统通过搭积木的方式提高了复用能力，降低了开发门槛，并在诸多客户打磨下趋于稳定，
隐忧在于，顶层规划的缺失，粗放型管理，正在推高维护成本，客单价和交付质量的降低，正在侵蚀利润。
一、这几年的转型历程，我有几个观察
1、客单价在走低
大多数项目签单额在10万以下，这部分客户没那么挑剔，有得用就用着，项目是微利，但贵在量大。
少部分项目签单额在20万上下，客户需求比较独特，喜欢试错，改模式，变需求，大概率是亏的。
极少数项目签单额在30万以上，客户需求相对通用，能完善产品，项目利润较多，但售后服务跟不上。
2、项目利润在失控
甲方要求越来越高，软件开发，涉及诸多环节的管理，我们在质量和风险把控上，短板尤为明显，
导致我们的市场口碑崩塌，客户越做越少，在甲方面前话语权也很低，需求不收费，动一下嘴就改了，
吃哑巴亏是常有的事，项目稍有不慎，就赔钱甚至烂尾，到最后闹得不欢而散，严重打击了团队士气。
3、项目经理的价值被分散
项目经理，大部分是我们用数十数百个客户的项目磨炼出来的，但随着客户越来越多，压力也在与日俱增
压力大了，动作就变形，各种问题冒头，问题处理不过来，就会拖，就会消极应对，各种投诉也随之而来
1个项目经理，保守约等于（0.2个客服 + 0.2个业务 + 0.2个实施 + 0.2个测试 + 0.2个管理）* N个项目
他们最大的痛点，在于突发性，临时性的工作较多，这些事情的紧急程度高，往往会打乱既有的工作部署。
我认为，让1个项目经理 =（0.5个客服 + 0.5个管理）* N个项目，更有利于专注客户服务和项目交付工作。
至于释放出来的测试和实施培训工作，统一给测试人员，这有利于让测试真正对上线的结果负责。
售前工作，通过我们的售卖体系赋能，常用话术和演示资料，有利于业务人员加快了解系统细节，熟悉产品。
二、如何才能做好软件的产品化？谈谈我的看法
1、全公司要达成一个共识
软件产品并不是单纯的软件系统，它需要一整套的体系来支撑，包括咱们的售卖体系，服务体系，研发体系。
2、产品的售卖体系
我们要从产品中，从客户的访谈中，提炼出100个以上的卖点，这是给公司后续做标准化销售sop使用的
我们还需要利用这100个卖点制作宣传手册，文案，短视频，长视频，这些统统称之为销售话术。
你要知道如何说服客户，为什么要买你的产品，如果你不会做，不会提炼产品的卖点，你就只能靠运气。
另外，我们的销售通路，靠业务找客户，效率太低了，可以考虑互联网获客，以及渠道商合作，打开通道。
3、产品的市场定位和推广策略
我们倒是不必去做专业的市场调研，做ab方案的测试，那是大公司的坑，小公司经不起折腾。
我们沉淀了很多客户，很容易了解客户痛点，不需要闭门造车，所以很重要的一点，不要为了创新而创新，
要基于项目积累，做一个最小的mvp，找2~3家以往的客户做访谈和调研，再结合竞品动向，做出正确判断。
4、关于服务体系
产品卖出去了，如何做好服务工作同样至关重要。
毕竟，我们的软件越做越复杂，这里边的学习教育成本是很高的。
比如，操作手册不完善，话术不完善，问题处理跟不上？
项目一上线，各种预料外的问题接踵而至，这些是前期偷工减料造成的，前期对各种复杂情况选择性忽视，
问题出现后，在项目经理这里解决，还是要到开发哪里解决，中间流转不畅，责任模糊，团队协作能力差。
这些机制没有准备好，产品卖出一个，客户就跑一个，留下来的也是怨声载道，随时想跑，更别提老带新。
我们可以尝试，把内部群化零为整，把售后事项集中一个群管理，但群里只做通知，事情是以工单来管理。
5、关于产品研发体系
做项目的时候，哪里管什么概要设计，详细设计，产品设计，就算有这些文档也是为了应付甲方的验收？
做产品，必须有全程的需求文档，设计文档，技术文档，需求，技术，测试的评审，代码走查，一样不能少，
尤其是关键业务算法的设计稿，必须要有底，要实时更新，不然时间一长，加上人员流动，维护成本翻倍。
三、展望未来
目前我们已经在加速完善研发体系和售卖体系，服务体系也将引入新的机制。
我们的SaaS产品，目前应该有60%左右的复用性，这对于公司来说是至关重要的。
有了这60%，项目就变成了标准产品，加定制开发，标准产品这一部分的成本可以趋近于0。
即便是定制开发的利润点较低，项目的风险也在可控范围，这是我能想到的公司生存的最佳模式之一。
一旦把这个运作模式，运作链条打通，产品线呢？就会越来越丰富。公司呢？慢慢的也就转型成功了。
转型之路，道阻且长，能走多远，我们每个人都至关重要，穷则思变，变则通，通则灵，与大家共勉。