一方面迫于营收的压力，接受定制就会有收入；但另一方面，普适性差的功能一旦多了，后续维护成本就高。
首先，从整个业务角度考虑
明确自己是做产品还是项目：
- 【项目】是客户的；
- 【产品】是公司自己的。
- 【项目】满足特定人群或者使用者需求，更偏向于个性化；
- 【产品】满足特定应用场景或者特定行业领域的需求，更加具有兼容性。
- 【项目】侧重于时间驱动，因为时间就是成本，满足交付任务即可；
- 【产品】侧重于功能驱动，更注重体验。
- 【项目】是以客户的需求为驱动，按照客户的需求进行定制开发；
- 【产品】是为了满足市场某一痛点可产生的，对于产品的性能以及快速迭代扩展的要求更高。
- 【项目】型公司可以赚到钱，但赚的是“人头钱”。一般项目公司都是按照工时收费，比如X元/人/天，人/天越多，项目总收入越多。项目越多，需要人越多，人数不够往往需要进行项目排期，公司的总收入也是和人头息息相关。一旦项目太多，人数不够，营收就陷入瓶颈，项目就处于停滞延期状态。
- 【产品】型公司赚的是产品的使用费或其他增值费，一个很小的团队，只要产品足够好，客户足够多，营收往往不可估量，人均创造价值远大于项目型公司。
再从需求本身考虑
SAAS产品客户越多，收到的需求越多，个性化需求也就越多，那么到底要不要接受客户的需求？
首先理解客户提的到底是需求还是方案
- 需求：我饿了
- 方案：我想吃馒头
当客户说的是“我想吃馒头了”一定要继续追问到具体原因，只有知道需求了，才能判断到底要不要实现；
然后判断需求的适用度
- 通用需求：适用于大部分客户，可以做到产品里；
- 假需求：要说服客户放弃；
- 真需求，但通用性很差：个性化需求，其他客户不存在此类需求，要和客户商讨有没有更好的处理方法。
最后从产品设计层面考虑
同样通用型需求，实现方案可以是针对单个客户定制，也可以做成通用型功能。
在考虑的时候，一定尽量往通用型设计方向考虑，我们接定制开发的目的
是为了积累对行业的经验，完善我们的产品适用度。
假如碰到不知道怎么做成通用型产品的时候：
- 不妨想想把我们的SaaS产品转化为平台PasS产品，或加强API能力，避免未来产品升级对定制开发部分的影响。
- 是否可以做出可配置的方案来尽量满足所有人的个性化需求
举个简单的例子，我做思拓云投票的时候，这个一个很简单的在线投票选举SaaS软件，遇到客户提了一个需求：希望用户投票前必须关注他们的公众号，以此来增加公众号的粉丝量。
同时，也提出了解决方案：客户投票账户的ID和他们提供的公众号账号相互绑定，每次用户投票前调用接口去判断用户是否关注他们的公众号。
拿到这个需求，假如说按项目来做，客户提的方案是可行的，将对应账户ID和公众号账号写死在系统里即可。
如果按照产品来看，这种实现方式只适合一个客户，不满足SAAS产品设计的初衷。
那到底要不要做？
做，很明显这是一个通用型需求，加强我们API能力，如果将投票账户ID和公众号绑定功能做成可授权的。每个账号可自己去授权绑定不同的微信公众号，这样即可满足所有客户。
那么从项目转型到产品需要注意什么？
- 加强API能力，即便定制，也要只做边界内的定制，边界外找成熟产品，没有就找第三方系统集成商做（某大佬建议）。
- 合适的时机，定制开发的比例越高，越要尽早转型做产品开发，很多项目性公司都是产品开发出来后，几年不更新产品，一直在项目中根据客户提的需求改产品功能，复用性极差。到后期就是堆人头，边际效应递减，人均产值下降，而且项目开发组与销售部门摩擦越来越大，几千万营收就出现瓶颈。
- 产品和项目不是相互独立的，是相辅相成的关系，产品的开发是可以通过一个个项目去完成。通过项目不断迭代开发，推进产品版本的更新。要注意的是尽量做通用型需求，产品设计也要考虑普适性。