前期的每一个产品决策，都会对后续工作产生深远影响。越是早期的决策，影响就越是深远。昨天晚上，一个连续创业者找我聊天。他很早就开始在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：小企业向左、大企业向右》。
3、功能垂直型还是行业垂直型
如前所述，SaaS时代很难再出现像SAP、Oracle那样的几乎涵盖所有规模行业的整体解决方案供应商。
未来，除了像Salesforce、钉钉这样的平台型企业，更多的是聚焦于特定功能领域的功能垂直型企业，比如销售易、北森等；或者聚焦于特定行业的行业垂直型企业，比如外勤365，有赞等。
由于不同行业、不同市场环境、不同公司文化都会造就不一样的企业管理风格，功能垂直型SaaS在满足个性化需求方面，会遇到比较大的挑战。因此，功能垂直型SaaS必须早早规划好PaaS平台，并且持续进行投入。
相对来说，行业垂直型SaaS在个性化方面遇到的挑战更小。但是，如果从长远考虑，PaaS能力的建设仍然非常重要。特别是考虑到功能垂直型SaaS和行业垂直型SaaS很可能会竞争同一批客户。
行业垂直型SaaS所面临的问题，则主要是市场规模瓶颈。比如房地产管理软件行业绝对的龙头老大明源云，2019年SaaS销售收入也不过为5.1亿，且已经连续3年亏损。
关于做功能垂直型还是行业垂直型的详尽分析，包括两个方向所面临的挑战和机会，大家可以点击阅读我的文章《中国SaaS：横着走还是竖着走》。
03、开发阶段
如果有幸寻找到一个合适的产品方向，甚至直接拿下了一个头部企业的项目，接下来的产品开发就变得非常重要。
说到底，SaaS公司最核心的竞争力仍然是产品能力。因此产品开发阶段的策略，也非常关键。
第一，企业软件选型正在从“单纯关注解决方案”，过渡到“关注解决方案，同时也关注产品”的新阶段。
第二，即便通过商务能力拿下订单，项目交付和产品续约的关键，仍然在于产品是否契合客户的需求，以及能否用更高的效率满足客户需求。
第三，如果每个项目都是定制的，那这样的产品策略是失败的。因为高昂的开发成本、漫长的回款周期最终会拖垮SaaS公司。
在SaaS产品开发阶段，我认为有以下三个方面的策略需要重点关注：
1、单点突破
16年我负责订单管理SaaS的时候，曾经和老板讨论过要不要做财务模块。
起因是不少中型企业客户提出，希望我们能够提供财务核算模块。由于和订单管理系统天然集成，一方面方便了财务核算，另一方面也便于财务到业务的追溯。
但是我坚决反对扩展到财务模块。
其一是考虑到财务模块的建设需要巨大的投入，而传统财务软件其实是相当成熟的产品。即便最终替换了传统财务软件，客户获得的新价值也远低于公司的投入，这里的新价值=新软件价值-旧软件价值-替换成本。
其二在于客户选择我们的原因并不是为了方便财务部门的工作，更多是为了实现移动抄单，以及对销售人员的移动化管理。在产品初期，把拳头产品打造得足够好，远远好过对次要功能进行扩展。
产品经理在对产品功能进行规划的时候，也要遵循“先把核心功能做到最好，再根据相关性谨慎扩展”的原则，切忌轻率铺开功能范围。
最糟糕的情况就是：SaaS产品充斥着一大堆欠缺价值的功能。它们除了占用大量资源，也会导致后续的产品迭代和扩展受到不必要的钳制。
2、标准化与PaaS
做商业化SaaS，方向一定是做标准化产品。
并不是说就一定不能做定制化。而是说，定制化模式如果要实现规模化盈利，可能需要配套其他的能力。比如，SaaS软件虽然是亏损出售，但是可以通过给客户提供其他服务进行弥补。
产品的标准化非常依赖于产品经理的架构能力。
架构能力不仅仅是逻辑抽象能力，更是对客户需求的洞察能力，以及对成熟商务套件架构与功能的深入掌握。
成熟的产品经理会站在当下的视角，考虑未来的场景，并给出妥善的“既考虑当下，也考虑未来”的解决方案。
以商品管理为例，有经验的产品经理一定会提前考虑到多单位管理、ERP集成等基本问题。因为未来再临时添加或改造，代价可能会非常高昂，甚至影响到原有客户的业务。毕竟所有客户使用的都是同一套软件。
但是，产品经理的经验和能力也是有限的，指望于产品经理构架出适用于所有规模和所有细分行业的标准化产品，几乎是不可能的。
因此，标准化产品进行适当的版本划分也非常重要。比如，大企业和小企业往往会规划不同的版本，按国家（不同国家可能有不同政策）和企业类型（厂家和经销商的管理方式差异较大）等维度进行版本划分也非常的重要。
即便如此，某些功能仍然是很难“规划”的。比如，营销天然就是一个创新的工作，没有人能够完全预见未来可能出现的促销方案。
这种情况下，产品的PaaS能力就变得非常重要。
即便是在传统软件时代，实施顾问也会尽可能的利用PaaS能力，因为相对于代码开发，PaaS的效率实在是太高了。
就我所知，PaaS能力可以分为几个层次。包括表单、流程、权限、自定义字段和字段属性等。但是好的PaaS必然是能够嵌入自定义SQL的，并且能够和其他标准表单、字段进行联动。
相对于行业垂直型SaaS，功能垂直型SaaS显然更依赖于PaaS平台。这也是销售易和北森很早就开始构建PaaS平台的原因之一。
关于如何培养架构能力，可以点击阅读我的文章《如何提升B端产品架构能力》。
3、长远规划与分步实施
为了实现标准化，长远的规划是有必要的。但是，只要是“规划”，就必然存在误判风险。特别是处于增长阶段的产品，产品经理永远无法准确预测，未来会出现什么样的客户与需求。
我个人认为，为了节约宝贵的资源，从而加快产品的进化速度，SaaS产品设计要尽可能多做‘加法’，少做‘减法’和‘改法’。
意思就是说，任何一个功能都要尽量确保长期使用，并且和未来的版本完美融合。否则，一旦版本升级，就可能需要对已开发的功能进行大改甚至废除。这无疑会浪费宝贵的研发资源，延缓产品价值的提升。
要实现这一点，除了要求产品经理具备一定的规划能力，也要求产品经理对市场存在敬畏心：即承认自己规划的某些功能，可能在很长一段时间内都不会被使用。因此，每一个计划开发的功能，都需要对应“明确被提出来的需求”。同时，和技术架构师仔细沟通对未来的规划，提前在技术架构上做好准备也非常重要。
但是，某些底层功能，即便我们知道短期内不会用到，仍然是需要提前开发的。这些功能往往贯穿了整个产品流程，如果等到产品比较复杂时再添加，代价就过于高昂了。
比如，批次号管理就是这样的功能。对于需要全流程跟踪批次号的商品，需要在几乎所有入库、出库、库存管理和报表分析环节，记录批次号以及批次状态。
总的来说，在开发阶段，非常考验产品经理对业务的洞察力，以及对产品的架构能力。我以为，甚至可以略为偏激的认为：产品经理决定了SaaS产品的成败。
关于成熟B端产品经理的观点，可以点击阅读我的文章《成熟的B端产品经理，都有这个能力》。
04 启动阶段
新产品如何启动，也是需要提前进行规划的。当然，启动阶段的工作与规划阶段的工作是密不可分的。比如，如果我们已经明确了“目标客户群体”，那么就很容易接触到第一批种子客户，并利用种子客户对产品进行验证和推广。
具体来说，我认为启动阶段需要规划好以下三方面的工作：
1、冷启动方案
在规划阶段，我们就应该已经明确甚至找到了第一批种子用户。
对于针对大客户的产品，找到一个标杆客户是非常重要的。当然，这里有一个鸡生蛋还是蛋生鸡的问题。即，如果没有相应的产品，就无法赢得大客户的订单；如果没有大客户的订单，也就无法开发出相应的产品。
其实，第一个标杆客户，创始人的人脉资源是非常重要的。另外，大企业的软件系统也可能存在严重的缺陷，这就使得创业公司可以通过一个“单点”功能，拿到大企业的订单。
比如，传统CRM系统在移动端的体验可能是非常糟糕的，SaaS公司在移动端的优势就是切入大企业的一个非常重要的武器。
对于针对小企业的产品，在规划阶段要想办法接触到第一批种子客户，然后通过免费试用等手段，吸引他们使用新产品。
2、需求管理机制
SaaS产品具备很强的互联网基因，因此MPV开发（最小可用功能开发）+快速迭代是SaaS产品常见的策略。
迭代往往需要依据具体的需求，因此建立起需求管理机制和流程就非常的重要。
产品经理需要建立需求提交的渠道，鼓励销售和服务等部门提交客户需求。在初期，产品经理需要亲自联系每一个提出需求的用户，一方面避免误解需求;另一方面也是寻找有潜力的用户，建立起自己的核心用户群体。
除了被动收集需求，产品经理也需要定期外出拜访客户。SaaS产品特别强调操作细节，而操作层面的问题，往往需要到现场才能有切身的体会。
3、与其他部门的协作
产品经理是对产品负责的人，因此凡是影响到产品推广结果的工作，都需要大力支持和参与。
比如，市场部门可能需要简短扼要的产品描述或者成功案例，以便于产品宣传与推广；服务部门可能希望在页面字段上显示字段说明，以减少客户的疑惑，提高服务部门的效率。
产品经理应尽可能考虑到协作部门的工作，尽全力满足他们的需求。
05 总结
产品策略决定了SaaS产品的成败。
我认为，只要确保三个阶段的九个策略都得到成功执行，就很有希望顺利完成SaaS产品的“从0到1”。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>这两天，互联网运营圈炸了。不是因为微信宕机了，也不是突然发布了什么政策，而是突然之间，微信开始对第三方社群管理工具 wetool 封杀。
大量的小号被封杀，基于小号和社群建立起来的粉丝用户体系，一朝回到解放前。
微信这番操作，也是告诉大家，没有私域流量，只能按照我的路子来。要么公众号，要么企业微信。
今天早上和业务团队聊了一下，感觉企业微信还是任重而道远，由于企业微信的能力开放有限，想大规模的玩起来，还需要一点时间积累。
现在，在企业微信能力开放之前，最好的粉丝载体，还是要回到微信公众号。
但微信公众号的限制，也是非常严格的，完全无法通过阅读情况，判断用户的喜好和特定，那产品经理该如何提供策略工具，为搭建公众号下的用户分层体系呢？
1、用户分层的意义
公司做公众号，最终目的还是商业化。
要么直接流量变现，要么转化到自己的 App 上。但无论怎么样，都绕不开一个动作：用户分层。
以母婴行业为例，要建立用户分层，如“普通读者” ——>“0-3 岁的妈妈” – >“付费粉丝” – >“会员粉丝” – > “KOL”，才能建立起来公众号运营策略。
只有了解到粉丝的构成和特征，才能给符合商业推广的粉丝，推送做到商业转化最大化，尽量减少打扰其他非相关粉丝，取关率也会降低。
接下来，我们就讲一下，通过标签的方式，如何对公众号粉进行分层，绘制出粉丝画像，最终实现商业化。
2、基于微信策略的用户分层
那在微信公众号体系下，如何做到用户分层呢？
微信的规则非常严格，无法通过哪些人读了什么类型的文章，来做用户分层，那只有通过产品+运营策略，通过标签的形式，为用户进行分层。
除了群发文章，我们还有 2 种情况下，可以和粉丝进行互动：粉丝关注公众号、粉丝与公众号互动。
新粉丝关注
新关注粉丝有以下特征：
- 通过朋友圈文章、朋友介绍、运营活动等渠道关注公众号，对公众号认可度较高，希望能快速获取一些有效信息
- 给予符合需求的信息，取关率会降低
- 新关注 48 小时内，微信支持多次消息触达，并且不占用推送次数。
怎么做？我们做了一个「给 url 绑定标签功能」
我们可以提前设置关注欢迎语，并在欢迎语的话术上，添加不同的绑定标签的链接。
当用户关注公众号成为粉丝时，自动给粉丝发送欢迎语，当点击其中某个链接时，就打上对应的标签。
优美语句
以母婴行业为例，我们在公众号设置欢迎语如下：
为了更好的为您提供更专业的育儿知识，已经整理的育儿知识，欢迎了解哦！
备孕怀孕︱宝宝 0～1 岁︱宝宝 1 岁以上 | 搜索问题
作为见面礼，我们还为你准备以下新人福利，点击下方蓝字即可领取：
🎁价值 100 元新人礼包免费领
🔥好课 9.9 元，仅限新人 ！
点击底部菜单栏，发现更多精彩↓↓↓
当用户点击引导语中链接，我们快速的了解给用户打上相应的标签，如「备孕怀孕」。
活跃粉丝运营
粉丝开始和公众号互动，微信又给我们提供了另外一种能力：
关注 48 小时内，可以多次给粉丝发送消息，并且不占用推送次数。
基于这个能力，我们做了「活跃粉丝多次触达功能」。
如果粉丝被打上标签「备孕怀孕」标签，再次与我们产生互动时，我们会再自动回复一条消息，当粉丝再次点击，进一步完善用户的标签。
举例
当粉丝被打上「备孕怀孕」标签，再次发欢迎语：
我们还为你准备了 6 个超实用的免费工具
产检提醒 | 产检解读 | 能不能吃 | 待产清单 | 疫苗助手 | 生长曲线，体验戳此>
结合新关注粉丝的特点，这套流程下来，可以快速的完成用户分层，对后续精细化运营提供数据支持。
总结
通过「关注欢迎语」和「多次触达」的方式，我们逐步建立起粉丝的画像。虽然多次触达没有限制发送条数，但过多会让粉丝取关或拉黑你，得不偿失。
当商业项目再次推广，也不需要全部粉丝推送，只需要选择需要推送的粉丝即可。
目前流量增长放缓，新客户获取成本变高。以前那种粗放式运营已经成为过去，只有通过精细化运营和自动化运营，真正满足用户的需求，才能有效的转化。
3、基于行为的用户分层
除了直接在公众号上卖流量广告，我们还要做转化。
于是我们做了「粉丝行为标签」，打通公众号与业务系统，通过公众号，来提升业务的转化效果。
业务上是用微信登录，我们通过 unionID，把业务的用户和公众号粉丝关联起来，当粉丝在业务上有特定行为，会给粉丝打上对应的标签，并同步到公众号上。
粉丝行为标签存在一定的效期，所以我们要及时触达，于是我们提供了两个服务：
- 自动化运营工具。给不同行为标签粉丝，推送不同的内容。
- 标签自动化更新。制定行为标签自动更新机制，保证信息的有效性。
举例
用户最近一直在查看某个类型的课程，那我们给用户打上这个类型课的标签。
运营通过「自动化运营」工具，制定 SOP（Standard Operating Procedure） ，按照制定的规则，群发给粉丝不同的内容，引导粉丝付费转化。
在MVP阶段，转化率提升了 30%，效果显著。
自动化运营，会在一定程度上影响粉丝收到推送文章。
所以要设置一定的限制机制，如 3 天只能收到一条转化推文。还有设置数据观测指标，如「取关率」、「转化率」等，帮助运营同学，尽可能合理的设置 SOP 流程。
4、总结
我们在做类似 SCRM 偏运营类的系统时，除了关注业务本身，也需要了解一些运营知识，至少懂一些运营理念。
破圈，是最近的热词，要拓宽自己的能力边界，才能走到更快更远。
作者：南南，微信公众号：司马特小分队，多年 B 端产品经验，带领团队搭建公司内部系统，专注于 CRM 和微信体系的运营系统搭建。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>