定制需求来了，接还是不接？

很多做SaaS的产品经理问我这个问题：客户提的需求超越了产品的边界。我到底要不要做定制开发呢？我要怎么区分这个是定制需求还是通用需求呀？

在半年前，Lisa阿姨会毫不犹豫地回答：TM别给他定制！！你是SaaS啊，又不是定制软件，管他个球！！

但是，这半年，随着我自己的公司做了越来越多的业务，也接触了各行各业的SaaS公司，才发现定制需求根本就是绕不开的门槛，除非你不想干了。

毕竟中国大多数买SaaS软件的公司，尤其客单价比较高的都是相对比较大型的企业，这种情况下因为经营环境的独特性，提定制需求也是十分普遍的事，那作为产品经理，应该如何对待这些需求呢？

接下来Lisa阿姨就帮大家一起捋一捋

1.找准公司的定位

如果甲方提了明确的定制需求，利润又可以，又能第一时间收到钱，其实也是一门不错的生意，但这个钱就不是产品的钱，是“人头钱”。

商业模式：利润 = 项目收费 - 开发成本(人数 × 成本)。

要赚到够项目活下来的钱，只能提高项目收费和极大的压缩成本

在项目收费不变的情况来看，就非常依赖团队的开发效率，也就是软件开发的标准化程度；而往往很多小团队完全谈不上标准化组件，都是打一枪换一波人，这样搞最后都是白辛苦。

其次，项目的需求变动风险也很大。客户方的标准化程度低、增长快的组织变革频繁，因此本身需求稳定性就不高，无限拉长了交付周期。

所以本身公司就是项目制的企业，那产品经理能提供的价值就是尽量在同类客户中找通用标准和流程，提高交付效率；在与客户测沟通需求时，用标准SOP承接，不做口头承诺，以控制定制需求的边界。

最终要发展壮大，没有任何积累是不可能有灵魂的。

2.产品初期做定制的目的

产品经理一定要时常灵魂拷问自己：

我做这个定制开发是为了赚这笔钱，还是为了积累对行业的理解（Know How），再打磨出锋利的产品？

赚钱没错，有的初创公司一年就200多万元营收，突然来了个100万元的单子，做还是不做？如果为了赚钱，当然要做，但如果是为了打磨产品，就应该有取舍。

产品经理一定要对自己的产品边界、产品发展方向要有很清晰的认识。

至少每个Q都要重新梳理一下产品的定位，越具体，目标客户的画像越明确越好。那些明显和产品未来的规划不相符合的项目，能不接就不接（当然公司马上就要死掉的话就另说）。

这里Lisa阿姨推荐大家用“产品画布”“业务流程图”“B端产品调研”3个工具来进行梳理。

不懂取舍的B端产品经理非常容易被客户牵着鼻子走，最后彻底沦为工具人。

3.从项目转型产品

在接定制需求的过程中，一个项目做完了，再做下一个，每个其实都有差别。那第2个、第3个项目是不是都可以融入到第1个项目中，然后组合成一个有竞争力的产品呢？

Lisa阿姨告诉你，很难！！

毕竟这为数不多的客户并不能代表广大的客户群体，从项目转型到做产品时，还是需要重新打磨SaaS产品的。

那应该怎么做才合适呢？

1、定制的需求，从一开始就要界定只做自己边界内的定制。边界外的定制应当去找成熟产品，只做好接口即可；如果没有产品能满足，就尽量找第三方系统集成商来做定制开发。

2、一定要尽早从项目转为做SaaS产品。定制开发的产能是有上限的，如果营收增速已经放缓，定制开发团队人均月产出金额就会下降，项目开发组与销售部门的摩擦会越来越大，这时就要果断地考虑启动产品化。

3、通用SaaS企业的产品其实可以升级自己的开发平台为PaaS。基于PaaS的定制开发是比较容易管理的，也不会影响定制开发部分的维护。

但是PaaS并不是万金油，对于行业SaaS，或产品复杂度不高的通用SaaS产品，真的没有必要做PaaS，可以试试用API接口来完成对接需求。

写在最后

总结一下：

最早期为了让企业生存下去，接定制需求也无可厚非

定制需求的商业模式是人头费：利润 = 项目收费 - 开发成本(人数 × 成本)。

以始为终，梳理产品的定位，那些明显和产品未来的规划不相符合的项目，能不接就不接

不要企图把定制项目汇总成一个通用产品，而是在合适的时间转型为产品。