首先我们需要限定一下我们这里要讨论的互联网产品它应该是一个To C的产品，如电商（天猫）、在线旅游（携程）、（支付）支付宝、社交（微信）。其次我们需要明确何为saas化，就是希望通过将这些互联网应用做成一个开箱即用的产品，通过公有云或者私有云的方式提供给第三方企业，使他们从技术中解放出来，专业于自己的业务。
这件个想法是非常好的，也是很有价值的。大型互联网企业的技术庞大复杂，对研发的投入很大，传统企业和初创企业无力承担。对于大多数业务型企业来说，互联网只是一个渠道，一个入口，或者一个工具，并非核心。如果招聘大量产品和技术来自研，投入大，周期长，坑多，研发不确定性大，就算项目成功上线，后面养着这些人维护的成本也是非常高昂的。所以很多传统企业和技术薄弱的企业非常想要这样一个saas化的互联网产品，需求有了。
俗话说没有金刚钻就别揽瓷器活，那什么样的企业能提供这样的saas产品呢？就是那些已经有成熟线上产品的互联网公司，他们有技术，有经验，且经过多年的耕耘，自己所在领域的市场趋于饱和，增长乏力，需要寻找新的增长点。他们都是行业标杆，需求方当然也很乐于和他们合作，把他们看作是救星，合同也很顺利就达成了，皆大欢喜。
理想是丰满的，现实是残酷的，我参与了多个这样的项目，发现实现起来非常困难，原因是多方面的。
首先，这件事情的基础，将一款互联网产品标准化成立么？我们只要想一想，淘宝能成功是因为淘宝复制了ebay么？支付宝能成功是因为支付宝复制了paypal么？京东能成功是因为京东是另一个淘宝么？互联网和传统行业不同，没有地域和用户规模的限制，在任何一个细分市场上，最终会变成寡头垄断，因此一家互联网公司要想成功，必须和别人不同，解决别人没有解决的问题，而不是简单的复制。这就决定了，互联网产品无法标准化，不仅是淘宝和京东需要不同，就是淘宝在不同的时期也需要不同。就在你开发需求A的时候，市场已经变化了，需求B产生了，所以做一款标准化的互联网产品有点刻舟求剑的意思。
因此当我们拿着一个我们认为Ready的产品给到客户的时候，客户会说：“嗯，就是这样差不多，但是我需要这里改下，那里改下，那里再改下，然后我还需要这个功能，那个功能，还有那个App的布局不错，我们也想这样布局…… 既然你们的产品已经差不多了，稍微改改应该就能上线了，我们就定2个月后上线吧。” 销售想想好像确实没多少东西，就答应了。当这一堆需要拿回来，开发一估时，傻眼了，3000个人日，还不包括上线和数据迁移。
时间长点就长点吧，就当这个项目是完善我们的产品，反正后面其他项目来是可以复用的，因为我们做的是产品，现在多投入点，不挣钱，慢慢后面成本就低了，老板是这样想的。至此我们发现，产品没有Ready，根本不存在一个开箱即用的产品可以满足客户的需求，定制开发是不可避免的，而且开发量其实很大。
做项目还是做产品，这是一个问题。 做项目和做产品其实有很大的不同。
其一，互联网产品都是长期迭代的产物，需求是随着市场不断变化的，技术是随着用户量增加不断演进的，10年前的淘宝和现在的淘宝，无论是功能还是技术都发生了翻天覆地的变化。但如果我们现在说是要做一个开箱即用的产品，那我们到底需要支撑多少用户量呢？100万还是1000万还是1亿？日交易量有时多少呢？每天1000单还还是1000万单？从产品的角度看，这只是一个数量不同，但是对技术来说，这完全是不同的架构，完全不同的复杂度，百倍千倍的成本差异。
其二，做产品必然要考虑通用性和扩展性，因为它并非只服务于特定客户，但是当接到客户的需求的时候，产品经理其实很难判断这个需求是通用的还是定制的，这不是光是经验的问题，微信做红包的时候我们认为他是个定制需求，但是当大家发现用它提高活跃度效果不错之后，它就成了社交的标配，变成一个通用需求。所以窘境就是我们要做一个产品，但是没有人知道这个产品最终应该包含哪些功能，于是需求变更，需求冲突时家常便饭，反应到代码上就是各种条件判断和硬编码，这样的产品多做几个客户就完全没法维护了，老手看了想吐，新手根本看不懂，改改就出一堆bug。
其三是开发模式。做项目，定好里程碑，每个迭代做一定的功能，测试上线，没毛病。做产品，由于前面说的，它是一个不可能Ready的产品，只能是随着客户的需求慢慢产品化。当有多个客户时，灾难就来了：每个客户要求的交付时间点是不同的，需求是不同的，并行开发不可避免。在开发层面，肯定需要拉出很多分支来满足不同客户的需求，代码和合并就是一个问题。如果各管各不合并代码，那就不是在做产品而是在做项目了，在客户A分支做的功能客户B无法复用，这就不叫saas化了。如果合并，那不同分支基于的基版本不同，解决合并冲突是个灾难。这最终导致了开发成本非常高，交付质量差。
最后一点是商业地位不同，提供saas的公司从甲方变成了乙方，其客户也从终端消费者变成了saas产品的购买方 这个看似无关紧要的变化其实影响了整个公司的行为模式和决策导向。做甲方，上线的时间节点都是自己说了算，如果一个功能没有Ready，为了用户体验，我可以不上。但是做乙方，上和不上都是客户说了算，项目交付时间点就变得很重要，客户也未必会理解项目delay的原因，对于它来说就是你没有按照合同约定保质标量完成任务。但是做互联网开发的都知道，估时是很难准确的，调整和取舍是经常发生的。
互联网产品saas化确实很难，比做IAAS和PAAS难多了，而这并不是一个技术问题。因此要做saas，一定要选好行业，做做To B还行，To C一定要慎重。