产品开发有两种方式：
- 项目－产品－平台；
- 平台－产品－项目。
两种方式各有个的特点，国内企业大多数都是从项目开始，逐渐积累摸索开始做产品，经历了几次的反复与阵痛后，逐渐发展成为平台。这种方式的特点是从项目中来，产品比较贴近项目，贴近特定用户的需求。缺点是产品往往缺少平台级别的整体构架，缺少广泛的适用性，在演化过程中往往要经历几次反复。
第二种方式从平台出发，其适用性就要广泛了很多，反复过程也会相对平稳，整体开发成本及失败的风险都会相对小一些。但是相对而言对于平台人员的能力、企业的技术积累等要求就要高了许多。这种方式往往是大部分有实力的公司采用的一种形式。
公司发展战略上明确提出要开发平台级产品。但是现阶段，公司的产品开发应该还是比较贴近前一种方式。我们现有的产品更加的贴近特定需求，相对而言就适用的广泛性上就会有所欠缺。当前我们在产品项目的协调与融合上面临的很多问题的根源是来自于此。项目需求的多样化，而产品更加贴近特定需求，缺少灵活的结构。为了满足当前项目需求，只能对原有代码进行入侵式的修改，项目需求逐渐侵食产品原有为特定需求而设计的构架，造成产品质量下降。而产品质量的下降使得实现新的项目需求变得更加困难。相信这也是公司领导提出“希望建立一种产品与项目融合协作机制”的原因之一。
其实不管是产品还是项目都存在着这样一个事实－－开始是相当重要的，是以后良好发展的根基；是形成良性循环的根基。什么问题开始时纠正的成本是最低的，随着项目、产品的发展这个成本将2倍，3倍甚至5倍10倍的提高。现在我们面临着这样一个困难的局面：产品我们有了，但是项目需求的多样性是现在产品难以满足的。怎么办？在现在的构架基础上修改，只能满足一时之需，或者连这一时之需也难以满足。而且随着项目需求对现在的产品代码的入侵，产品将越来越难以维护，越来越难以往里添加新的功能；而项目的风险也随着时间的推移越来越大。我们已经进入了一个恶性循环的开始，这是可以预见的。然而，完全抛弃现有的东西，对当前产品，开发人员的影响又是巨大的。对于公司也是难以接受的。怎么办？我们已经陷入了一种两难的境地。
基于一般的认识，多数组织在这个时候都会惯性的采取一种“鸵鸟政策”或者说是“冰冻政策”。可预见的还未成为事实，况且不是每一个人的预见都是这样。现在能用就这样用着，等慢慢的问题暴露出来了，无法继续了，大家都已经看到了，这时，已经成为事实，我们实际上已经没有什么选择了，组织也只能选择接受。这样作的明显好处是对于组织中人员触动是最小的，而且最后往往也是没有人需要来承担这个责任。唯一的缺点是组织在经济上，项目上，进而是品牌上受到一定量的损失。
另一种方式，完全抛弃现有的东西，这对于当前的产品、开发人员的影响甚大。而且对于组织之前的一些工作也是一种否定，组织也是难以接受的。
那么有没有第三种方法呢？
让我们换个角度来看待这个问题：实际上基于组织现在实际采取的产品开发方式（即从项目－产品－平台），那么实际上这种反复是必然要经历的。只不过现在随着公司规模的扩大，人才的引进，我们人为的加快了这种反复。并且我们现在也有能力来加快这种反复，在反复的迭代过程中使产品快速成熟起来。很多公司在产品的开发过程中实际上都是这么做的：在一个版本即将发布时，下一个版本的规划和开发实际上早已开始。这一版本发现的问题，收集的新的需求，按照一定的方式加入下一版本，以保证产品对于市场的及时反馈与跟进。
现在，项目需求的多样性，使的当前产品难以满足，侵入式的修改到底能维系多久也是个疑问。或许这是我们启动平台产品新版本开发的一个时机－－安排新平台的产品经理，新的设计人员，组建新的开发队伍，依据当前问题重新设计构架，适当重用已有代码。当前版本，由当前开发人员继续开发，维护，以期能满足一定的项目需求。这样，当当前产品无法适应之时，我们的新版产品也能够尽快的跟进，以尽量弥补可能的影响，将可能的风险与损失控制在一定范围。
