编辑导语：大家做SaaS产品的工作应该已经有一段时间了，SaaS是一个非常有挑战的产品形态，作者在这段时间踩了很多坑，也练出了一身肌肉。在这个过程中感到最大的挑战就是客户量起来后，对外如何用一套标准产品满足不同行业不同类型客户的花式需求，对内如何高效协调好有限的研发资源，好钢用在刀刃上，去实现每个迭代的产品目标。作者总结了一下个人感悟分享出来，希望对大家有所帮助。

一、产品设计的“完整性原则”

SaaS产品最大的特性就是用一套标准产品去满足不同类型客户的需求，因此在产品设计方面最重要的一个原则就是“完整性原则”，完整性原则就是产品经理在进行需求设计时要完整考虑场景、考虑全部行业全部用户、并且考虑未来迭代的扩展性，一次性把需求设计到位。

这是实际工作当中最容易犯的错误，很容易陷入“就事论事”，单个问题、单个模块、单个客户、单个时间点解决问题的大坑。

举个例子说明一下：比如A客户提出希望解决人员列表中存在的员工重名问题，希望增加工号字段；我们就需要完整考虑重名问题哪些场景还会遇到？除了名字还有其他字段重复时会产生麻烦？最终形成一个完整方案。

再比如B客户提出希望不在组织通讯录内的代理商客户也可以查阅企业的学习资料。这里就要完整考虑外部用户除了代理商还可能有哪些？需求都是同样的吗？除了看学习资料，还需要下载转发吗？需要考试吗？等等。

总之，产品设计需求的时候没有考虑完整，最后不断的修修补补，在整个相关功能上花费的研发工作量，远远超出了一次性完整开发一个功能模块所需要的功能。

二、产品开发的灵活性

不同行业、类型客户间产品使用的主场景差异不大，但是细节功能上的差异非常大，因此SaaS产品功能设计一定要具有普适性和灵活性。可能存在个性化的流程一定要设计灵活的可配置项。为了提升灵活性，产品开发要遵循“乐高化”原则。

前端设计成一个个小组件，新的功能页面只是使用已有组件去拼装，就和搭积木一样；后段采用微服务化，避免过度耦合。对于客户的定制需求模块也要独立代码开发，最后通过接口与现有服务对接起来，不要在现有代码上直接叠加开发。

三、产品需求管理的前置

SaaS售卖模式是“现在的产品+未来的承诺”，客户对于未来产品迭代是有期待的，很多中大型客户签约时会提出自己的个性化需求；产品经理要为销售赋能，引导好客户预期。（这里插一句题外话，销售人员都是“短视”的，考虑的都是眼前的利益，因为屁股决定脑袋，销售团队考核的都是当月销售业绩，没人考核两年以后的，所以销售人员一定要拿下眼前的这个单子）

所以产品团队一定要提前规划好产品的演进方向，将产品发展规划的文档同步到销售团队，这些内容可以作为对于客户的额外承诺，通过这个产品规划可以将客户需求限定在可掌控的范围内，产品团队掌握了需求的主动性，会省去非常多的麻烦。

四、个性化需求的处理

很多个性化需求都发展成了定制化，尤其是面对一些付费能力比较强的大客户，这是一个做SaaS避不开的难题，老板舍不得大单，只能硬着头皮接下来；问题是定制化需求的性价比极低，是对于产研资源的巨大浪费，是获取短期利益，损害产品长远发展的。

对于产品经理来说，需要能将客户的个性化需求引导转化为标准化需求，把单个客户的需求转换成大多数客户的功能，这个是做SARS的产品经理能力当中最为关键的一点，具体怎么做要具体分析。

举个例子说明：学习平台中设定学员学习行为会加“学分”，辅助学习行为（上传学习资料、授课视频等）会增加积分，C客户提出个性化需求：老师授课（属于辅助学习行为）不要加积分，希望改为加学分。

这与平台设定的规则完全违背，不可能为了这单个客户去改其他客户已经适应了的规则，面对这种“宝藏需求”我们进行了深入分析，发现客户是希望学员教师双身份的人能够把学分、积分合并，以便于自己学习好同时也能帮助他人学习的员工在排行榜上能排名更靠前，明白了“提升荣誉感”这个原始诉求我们就可以进行相应的引导设计。

以上是个人的一点感悟，SaaS产品不是简单的B端产品，它的产品形态决定了他所面临的挑战，我们作为产品经理要针对不同的服务模式、不同的客户类型去调整我们的设计思路。

PS：大家可以关注一下产品经理相关的招聘信息。就会发现关于SaaS相关能力要求的产品岗越来越多了，说明这种产品形态越来越普及。企业逐渐接受用租赁而不是一次性买断的方式，尤其是在疫情的背景下，这种低成本又灵活的软件形态更受欢迎，各位产品同学可以沉淀一下相关的能力。

本文由 @Jiahhy 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。