您当前的位置:首页 >> 资讯 >>  行业资讯

SaaS从0到1,产品策略决定成败(二)


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产品的成败。

04
启动阶段 

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

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

1、冷启动方案

在规划阶段,我们就应该已经明确甚至找到了第一批种子用户。
对于针对大客户的产品,找到一个标杆客户是非常重要的。当然,这里有一个鸡生蛋还是蛋生鸡的问题。即,如果没有相应的产品,就无法赢得大客户的订单;如果没有大客户的订单,也就无法开发出相应的产品。
其实,第一个标杆客户,创始人的人脉资源是非常重要的。另外,大企业的软件系统也可能存在严重的缺陷,这就使得创业公司可以通过一个“单点”功能,拿到大企业的订单。
比如,传统CRM系统在移动端的体验可能是非常糟糕的,SaaS公司在移动端的优势就是切入大企业的一个非常重要的武器。
对于针对小企业的产品,在规划阶段要想办法接触到第一批种子客户,然后通过免费试用等手段,吸引他们使用新产品。

2、需求管理机制

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

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

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

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

3、与其他部门的协作

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

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

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

05
总结  

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

山东动脉智能科技股份有限公司    版权所有   鲁ICP备18044412号  电话:4008-0537-07