昨天晚上，一个连续创业者找我聊天。他很早就开始在SaaS领域创业，早期的产品也很成功。但是在扩展产品线时，他选择了做跨行业通用平台，这显然是一个对资金要求很高的方向。几年下来，公司的现金流出了问题。目前，他已经重新创业，新的方向选择了行业垂直类SaaS。

宽泛的来说，产品方向选择属于产品策略内容。而我一直认为：产品策略决定了产品的成败。

这里的关键在于，前期的每一个产品决策都会对后续工作产生深远影响。越是早期的决策，影响就越是深远。

因此，作为产品研发最早期的产品策略，在很大程度上决定了产品的命运。

01 什么是产品策略

所谓策略，《孙子兵法·始计篇》说：夫未战而庙算胜者,得算多也。

用大白话来说，就是在打仗前，要全盘考虑夺取胜利所需的方案和资源。

产品策略，是高级产品经理、产品总监的首要职责所在。一个产品负责人，如果在产品临近上线时，仍然拿不出冷启动的方案，这样的负责人大概率是失职的。

当然，本篇文章并无意写成教科书一般的指导手册：全面而又没有争议。

我更希望能够结合自身的实践，对商业化SaaS从0到1过程中的关键点进行反思、总结和提炼，以便抛砖引玉，为后来者铺路。

本篇文章会涉及三个阶段的九个策略：

需要强调的是，三个阶段的工作都需要在产品设计前就进行慎重考虑。虽然计划赶不上变化，但是提前思考会增加我们的反应速度，从而能够更快速的应对变化。

02 规划阶段

规划阶段是整个产品策略中，最具有决定性意义的阶段。在这个阶段，我们需要回答几个问题：

• 我们的客户是谁？
• 我们满足客户什么需求？
• 客户愿意付费吗？
• 为什么客户选择我们？

具体到商业化SaaS，可以从以下几个方面进行思考：

1、机会与威胁

2014年以来的这一波SaaS创业浪潮，主要还是基于移动互联网和微信生态。

比如快消品领域的外勤365，以良好的移动端体验为切入点，甚至能替换康师傅、百事可乐等龙头企业的核心管理软件；微盟则是基于微信生态成功的典范。近几年，随着私域流量的崛起，基于微信体系的获客、SCRM等领域也涌现出众多创业公司。

另外，随着AI、大数据和区块链等技术逐步成熟，未来在这些领域也会出现更多的创业机会。

当然，做SaaS也存在很多坑。

比如今目标、纷享销客等主打办公协同的SaaS厂商，到今天大多都已经转型，就是因为选择的赛道不够细分，被巨头用免费产品挤出了市场。

另外，当面对大企业市场，对标传统软件，SaaS在技术方面并没有明显的‘效率’提升，而标准化SaaS的设计开发难度反而大大增加。因此我们很难看到，在SaaS时代出现像SAP、Oracle那样通吃大部分规模行业的整体解决方案供应商。

有人可能会说Salesforce的市值已经超越了Oracle。但是Salesforce成功的路径，并不是像Oracle一样提供行业全套应用产品。而是通过开放PaaS平台，帮助更细分的解决方案SaaS公司获取客户、提高开发效率。

因此，我相信SaaS领域会长时间存在众多小而美的垂直型企业。这意味着可能都还存在着众多的创业机会。但是，凡事有一利必有一弊。由于市场太细分，SaaS公司收入规模很容易遇到天花板。因此创业者在选择创业领域的时候，可能需要考虑该领域的市场规模，特别是在该领域已经存在SaaS竞争者的情况下。

当然，我个人认为，做SaaS最大的坑还是在于伪需求。伪需求未必就是不存在的需求。也可能是需求的客群与企业当下的客群没有重叠，不适合作为第二条产品线开拓。另外，也有可能是需求的优先级较低，客户不愿意付费，那么这个产品也就不太适合小企业创业。

破除伪需求最直接的办法，就是找到一批种子用户，并且确认他们的付费意愿。

2、做大客户还是小客户

由于SaaS模式避免了服务器、IT团队等固定投入，中小企业往往更容易接受SaaS模式。但是中小企业的付费意愿不强、生命周期较短都是很大的问题，因此SaaS公司很自然的开始寻求向上突破，期望蚕食传统软件的大客户市场。

但是SaaS模式在颠覆传统软件的过程中遇到了麻烦，即标准化的产品很难满足大企业的个性化需求。因此，很多企业重新开发了针对大企业的产品，并且配备了相应的团队和流程。

但是，用SaaS产品替换原有系统，会遇到替换成本过高、个性化需求难以满足等一系列问题，这就导致SaaS产品的推广速度并不理想。结果是，做大企业的中国SaaS公司，目前能实现规模化盈利的还并不多。

关于做大客户还是小客户，我觉得并没有绝对的结论。这更多取决于创始团队的能力和资源。比如，对于行业运营能力较强的创业者，做小客户也是非常不错的选择。

如前所述，SaaS时代很难再出现像SAP、Oracle那样的几乎涵盖所有规模行业的整体解决方案供应商。

未来，除了像Salesforce、钉钉这样的平台型企业，更多的是聚焦于特定功能领域的功能垂直型企业，比如销售易、北森等；或者聚焦于特定行业的行业垂直型企业，比如外勤365，有赞等。

由于不同行业、不同市场环境、不同公司文化都会造就不一样的企业管理风格，功能垂直型SaaS在满足个性化需求方面，会遇到比较大的挑战。因此，功能垂直型SaaS必须早早规划好PaaS平台，并且持续进行投入。

相对来说，行业垂直型SaaS在个性化方面遇到的挑战更小。但是，如果从长远考虑，PaaS能力的建设仍然非常重要。特别是考虑到功能垂直型SaaS和行业垂直型SaaS很可能会竞争同一批客户。

行业垂直型SaaS所面临的问题，则主要是市场规模瓶颈。比如房地产管理软件行业绝对的龙头老大明源云，2019年SaaS销售收入也不过为5.1亿，且已经连续3年亏损。

02 开发阶段

如果有幸寻找到一个合适的产品方向，甚至直接拿下了一个头部企业的项目，接下来的产品开发就变得非常重要。

说到底，SaaS公司最核心的竞争力仍然是产品能力。因此产品开发阶段的策略，也非常关键。

第一，企业软件选型正在从“单纯关注解决方案”，过渡到“关注解决方案，同时也关注产品”的新阶段。

第二，即便通过商务能力拿下订单，项目交付和产品续约的关键，仍然在于产品是否契合客户的需求，以及能否用更高的效率满足客户需求。

第三，如果每个项目都是定制的，那这样的产品策略是失败的。因为高昂的开发成本、漫长的回款周期最终会拖垮SaaS公司。

在SaaS产品开发阶段，我认为有以下三个方面的策略需要重点关注：

1、单点突破

16年我负责订单管理SaaS的时候，曾经和老板讨论过要不要做财务模块。

起因是不少中型企业客户提出，希望我们能够提供财务核算模块。由于和订单管理系统天然集成，一方面方便了财务核算，另一方面也便于财务到业务的追溯。

但是我坚决反对扩展到财务模块。

其一是考虑到财务模块的建设需要巨大的投入，而传统财务软件其实是相当成熟的产品。即便最终替换了传统财务软件，客户获得的新价值也远低于公司的投入，这里的新价值=新软件价值-旧软件价值-替换成本。

其二在于客户选择我们的原因并不是为了方便财务部门的工作，更多是为了实现移动抄单，以及对销售人员的移动化管理。在产品初期，把拳头产品打造得足够好，远远好过对次要功能进行扩展。

产品经理在对产品功能进行规划的时候，也要遵循“先把核心功能做到最好，再根据相关性谨慎扩展”的原则，切忌轻率铺开功能范围。

最糟糕的情况就是：SaaS产品充斥着一大堆欠缺价值的功能。它们除了占用大量资源，也会导致后续的产品迭代和扩展受到不必要的钳制。

2、标准化与PaaS

做商业化SaaS，方向一定是做标准化产品。

并不是说就一定不能做定制化。而是说，定制化模式如果要实现规模化盈利，可能需要配套其他的能力。比如，SaaS软件虽然是亏损出售，但是可以通过给客户提供其他服务进行弥补。

产品的标准化非常依赖于产品经理的架构能力。

架构能力不仅仅是逻辑抽象能力，更是对客户需求的洞察能力，以及对成熟商务套件架构与功能的深入掌握。

成熟的产品经理会站在当下的视角，考虑未来的场景，并给出妥善的“既考虑当下，也考虑未来”的解决方案。

以商品管理为例，有经验的产品经理一定会提前考虑到多单位管理、ERP集成等基本问题。因为未来再临时添加或改造，代价可能会非常高昂，甚至影响到原有客户的业务。毕竟所有客户使用的都是同一套软件。

但是，产品经理的经验和能力也是有限的，指望于产品经理构架出适用于所有规模和所有细分行业的标准化产品，几乎是不可能的。

因此，标准化产品进行适当的版本划分也非常重要。比如，大企业和小企业往往会规划不同的版本，按国家（不同国家可能有不同政策）和企业类型（厂家和经销商的管理方式差异较大）等维度进行版本划分也非常的重要。

即便如此，某些功能仍然是很难“规划”的。比如，营销天然就是一个创新的工作，没有人能够完全预见未来可能出现的促销方案。

这种情况下，产品的PaaS能力就变得非常重要。

即便是在传统软件时代，实施顾问也会尽可能的利用PaaS能力，因为相对于代码开发，PaaS的效率实在是太高了。

就我所知，PaaS能力可以分为几个层次。包括表单、流程、权限、自定义字段和字段属性等。但是好的PaaS必然是能够嵌入自定义SQL的，并且能够和其他标准表单、字段进行联动。

相对于行业垂直型SaaS，功能垂直型SaaS显然更依赖于PaaS平台。这也是销售易和北森很早就开始构建PaaS平台的原因之一。

3、长远规划与分步实施

为了实现标准化，长远的规划是有必要的。但是，只要是“规划”，就必然存在误判风险。特别是处于增长阶段的产品，产品经理永远无法准确预测，未来会出现什么样的客户与需求。

我个人认为，为了节约宝贵的资源，从而加快产品的进化速度，SaaS产品设计要尽可能多做‘加法’，少做‘减法’和‘改法’。

意思就是说，任何一个功能都要尽量确保长期使用，并且和未来的版本完美融合。否则，一旦版本升级，就可能需要对已开发的功能进行大改甚至废除。这无疑会浪费宝贵的研发资源，延缓产品价值的提升。

要实现这一点，除了要求产品经理具备一定的规划能力，也要求产品经理对市场存在敬畏心：即承认自己规划的某些功能，可能在很长一段时间内都不会被使用。因此，每一个计划开发的功能，都需要对应“明确被提出来的需求”。同时，和技术架构师仔细沟通对未来的规划，提前在技术架构上做好准备也非常重要。

但是，某些底层功能，即便我们知道短期内不会用到，仍然是需要提前开发的。这些功能往往贯穿了整个产品流程，如果等到产品比较复杂时再添加，代价就过于高昂了。

比如，批次号管理就是这样的功能。对于需要全流程跟踪批次号的商品，需要在几乎所有入库、出库、库存管理和报表分析环节，记录批次号以及批次状态。

总的来说，在开发阶段，非常考验产品经理对业务的洞察力，以及对产品的架构能力。我以为，甚至可以略为偏激的认为：产品经理决定了SaaS产品的成败。

03 启动阶段

新产品如何启动，也是需要提前进行规划的。当然，启动阶段的工作与规划阶段的工作是密不可分的。比如，如果我们已经明确了“目标客户群体”，那么就很容易接触到第一批种子客户，并利用种子客户对产品进行验证和推广。

具体来说，我认为启动阶段需要规划好以下三方面的工作：

1、冷启动方案

在规划阶段，我们就应该已经明确甚至找到了第一批种子用户。

对于针对大客户的产品，找到一个标杆客户是非常重要的。当然，这里有一个鸡生蛋还是蛋生鸡的问题。即，如果没有相应的产品，就无法赢得大客户的订单；如果没有大客户的订单，也就无法开发出相应的产品。

其实，第一个标杆客户，创始人的人脉资源是非常重要的。另外，大企业的软件系统也可能存在严重的缺陷，这就使得创业公司可以通过一个“单点”功能，拿到大企业的订单。

比如，传统CRM系统在移动端的体验可能是非常糟糕的，SaaS公司在移动端的优势就是切入大企业的一个非常重要的武器。

对于针对小企业的产品，在规划阶段要想办法接触到第一批种子客户，然后通过免费试用等手段，吸引他们使用新产品。

2、需求管理机制

SaaS产品具备很强的互联网基因，因此MPV开发（最小可用功能开发）+快速迭代是SaaS产品常见的策略。

迭代往往需要依据具体的需求，因此建立起需求管理机制和流程就非常的重要。

产品经理需要建立需求提交的渠道，鼓励销售和服务等部门提交客户需求。在初期，产品经理需要亲自联系每一个提出需求的用户，一方面避免误解需求;另一方面也是寻找有潜力的用户，建立起自己的核心用户群体。

除了被动收集需求，产品经理也需要定期外出拜访客户。SaaS产品特别强调操作细节，而操作层面的问题，往往需要到现场才能有切身的体会。

3、与其他部门的协作

产品经理是对产品负责的人，因此凡是影响到产品推广结果的工作，都需要大力支持和参与。

比如，市场部门可能需要简短扼要的产品描述或者成功案例，以便于产品宣传与推广；服务部门可能希望在页面字段上显示字段说明，以减少客户的疑惑，提高服务部门的效率。

产品经理应尽可能考虑到协作部门的工作，尽全力满足他们的需求。

04 总结

产品策略决定了SaaS产品的成败。

我认为，只要确保三个阶段的九个策略都得到成功执行，就很有希望顺利完成SaaS产品的“从0到1”。