满足特定人群或者使用者需求，更偏向于个性

一方面迫于营收的压力，接受定制就会有收入；但另一方面，普适性差的功能一旦多了，后续维护成本就高。

首先，从整个业务角度考虑

明确自己是做产品还是项目：

• 【项目】是客户的；
• 【产品】是公司自己的。
• 【项目】满足特定人群或者使用者需求，更偏向于个性化；
• 【产品】满足特定应用场景或者特定行业领域的需求，更加具有兼容性。
• 【项目】侧重于时间驱动，因为时间就是成本，满足交付任务即可；
• 【产品】侧重于功能驱动，更注重体验。
• 【项目】是以客户的需求为驱动，按照客户的需求进行定制开发；
• 【产品】是为了满足市场某一痛点可产生的，对于产品的性能以及快速迭代扩展的要求更高。
• 【项目】型公司可以赚到钱，但赚的是“人头钱”。一般项目公司都是按照工时收费，比如X元/人/天，人/天越多，项目总收入越多。项目越多，需要人越多，人数不够往往需要进行项目排期，公司的总收入也是和人头息息相关。一旦项目太多，人数不够，营收就陷入瓶颈，项目就处于停滞延期状态。
• 【产品】型公司赚的是产品的使用费或其他增值费，一个很小的团队，只要产品足够好，客户足够多，营收往往不可估量，人均创造价值远大于项目型公司。

再从需求本身考虑

SAAS产品客户越多，收到的需求越多，个性化需求也就越多，那么到底要不要接受客户的需求？

首先理解客户提的到底是需求还是方案

• 需求：我饿了
• 方案：我想吃馒头

当客户说的是“我想吃馒头了”一定要继续追问到具体原因，只有知道需求了，才能判断到底要不要实现；

然后判断需求的适用度

• 通用需求：适用于大部分客户，可以做到产品里；
• 假需求：要说服客户放弃；
• 真需求，但通用性很差：个性化需求，其他客户不存在此类需求，要和客户商讨有没有更好的处理方法。

最后从产品设计层面考虑

同样通用型需求，实现方案可以是针对单个客户定制，也可以做成通用型功能。

在考虑的时候，一定尽量往通用型设计方向考虑，我们接定制开发的目的

是为了积累对行业的经验，完善我们的产品适用度。

假如碰到不知道怎么做成通用型产品的时候：

• 不妨想想把我们的SaaS产品转化为平台PasS产品，或加强API能力，避免未来产品升级对定制开发部分的影响。
• 是否可以做出可配置的方案来尽量满足所有人的个性化需求

举个简单的例子，我做思拓云投票的时候，这个一个很简单的在线投票选举SaaS软件，遇到客户提了一个需求：希望用户投票前必须关注他们的公众号，以此来增加公众号的粉丝量。

同时，也提出了解决方案：客户投票账户的ID和他们提供的公众号账号相互绑定，每次用户投票前调用接口去判断用户是否关注他们的公众号。

拿到这个需求，假如说按项目来做，客户提的方案是可行的，将对应账户ID和公众号账号写死在系统里即可。

如果按照产品来看，这种实现方式只适合一个客户，不满足SAAS产品设计的初衷。

那到底要不要做？

做，很明显这是一个通用型需求，加强我们API能力，如果将投票账户ID和公众号绑定功能做成可授权的。每个账号可自己去授权绑定不同的微信公众号，这样即可满足所有客户。