最近发现产品设计中需要填的坑实在太多了。

当产品负责人也有一段时间了,最近发现困扰我的一个问题就是产品的基础设计实在是太令人难受了,一方面早期很多产品功能的设计可能都是“想一出是一出”,一方面满足了老板的想法,但是在具体实践与设计过程中真的是一言难尽。这就导致了一个很无奈的问题,我们现在做的很多事情都是在给以往的错误买单。而由于这种以往的错误实在是太多了,而错误出现大多又都是在 19至 20 年底出现,产品文档中缺少必要性的论证与背景信息进行进一步的分析,这就导致“与其说是优化,还不如说是站在产品最起初的远原点,把所有需要考虑的问题从头再考虑一遍”。

总而言之,最近这种乱七八糟的事情,越来越多了。刚好想到之前吴昊老师《SaaS 创业路线图》中有一些相关的论述,摘抄在本文之中。

一、产品打磨的原则与分工

我们先讲讲产品调研阶段的原则。

我刚开始做 Sass 领域研究时,见的初创公司比较多。有一段时间连续见了几个在产品调研阶段的公司。其中大部分部犯了同样的错误。有了产品方向后,产品经理的市场调研很简略,在办公室里用工程师的“完美主义 +系统运辑”思想来主导研发工作。

虽然这不算闭门造车,但显然“闭门”的时间远远大于在一线与客户交流的时间。结果呢?几个月后产品做出来了,招募 2~3 个营销人员,他们拿着产品见客户,发现完全没有切中客户痛点。客户反馈说:“你们根本不懂我们的业务!”此时,产品和营销人员都垂头丧气。

还有一种美其名日“大范围调查”的错误。几个实习生做了上百家客户的调研,调研报告就像说“人人都有两条胳臂、两条腿一样”,根本没有抓到重点和差异。和个人消费者不同,企业客户因为组织和业务复杂,大多数描述不清自己的需求。大家都听说过这个玩笑:“客户说要让马车更快, 实际上应该给他发明一辆汽车。”

我曾经在得到 App 上把梁宁老师的《产品思维30 讲》仔细听了 2 遍, 2018 年还专门跑到上海听她在“MiNi 创业营,的授课。她的建议是,toC 产品“打痛点、打爽点或打痒点〞都行,但 toB 产品只能打痛点。C 端需求比较感性,B 端需求非常理性,别想拿“未来"的东西忽悠“现在”就投的钱!

此外,toB 与 toC 相比,还有一个很大的区别:容户需求一致性较差。 换句话说,即使在一个行业里,各个企业间的业务和组织差异也很大。也许一个创意点子在创始人头脑里很完美,但一到市场上,必然面对南北生界、城市差界、规便装界,甚至门店位置差异等问题。不同客户的需求有很大偏差,找到共性需求成为很大的难题。

正确的产品打磨方式应该是什么样的?我建议用以下调研框架来解决产品打磨的问题。

(1)任何行业的市场都需要被细分,要做广度抽样调研,弄清楚目标客户有哪些主要属性,每一类客户的数量、需求的紧迫性及购买力。

(2)选择 3~4 个细分市场的头部产品,在这个特定范围内进行调研,才有机会找到共性需求。创始人、产品经理、营销合伙人最好一起參与调研,分别把握产品价值、产品体验和产品卖点。如果创始人能三者养顾的话,效率会更高。

(3)不要想一次性地就把功能做完整,新产品应该胜在“锋利”而非“完整”。这也是 MVP 应有之意。

尽快出“原型”、尽快见客户、尽快根据客户的反馈进行调整,就是“产品打磨”阶段的原则。在实际运作中,还有组织协同的问题。产品经理、研发老大、营销老大,大家通过与客户接触和系统思考,对不同的选择有不同的想法,最后应该听谁的?

首先,我建议让大家充分表达意见。但创始人要分清楚哪些是关键问题,值得反复探讨,哪些是非关键问题,必须设置一个关闭的时间。时间一到,创始人立即拍板关闭讨这。老板和拍板是同一个“板”字啊,不要花费太多时间做“闭门”讨论。

在大公司里孵化新项目还面临一个尴尬局面。一些大公司设立了新项目创业团队,但这些团队由于自身业务特点。 在薪资、工作方式、激励方法上与老团队的需求完全不同。我认为大公司老饭一定要给内部解化的创业团队独立的资源。在人事和管理制度、办公区域,甚至在公司架构上,要让创业团队有独立的空间,否则新项目创业团队根本没机会生存。

一个真实场景:新项目的很多决策需要上公司管理例会,老负责人是公司元老,掌握公司主要营收,一遇到争执就说“你们新项目的人就是我养的”。这时,多数新项目的负责人不敢再据理力争了。中欧商学院的龚焱教授讲创新方法,他提到 MVP 方法论也有“短板”的问题:可能放弃了需要长期投入但具有更大发展的机会。所以也要辩证地看 MVP,其关键就是创始人的判断。有时侯,即使创始人错了,也应该听他的。毕竟团队就是因为他和这个创意聚到一起的。换句话说,没决断力的人,做不好创始人。

二、该不该做定制开发

“产品打磨”阶段的 SaaS 团队经常遇到一个问题:客户的基本情况特合目标客户画像,但他们提出的需求却超越了初定的需求边界。那么,要不要做定制开发?

我曾经是“定制开发”的极端反对者。但随着接触更多的 SaaS 公司, 我看到中国本地 SaaS 创业的一些特殊情况。前面章节我说到,Saas 产品最适合“橄榄型”的目标市场。但这不意味着头部较重的市场就不能做 SaaS。 2019 年,请我做顾问的一家企业就是在这样一个市场上。该行业为万亿级市场,但全国总共就 1000 个左右的企业客户,前 100 名的头都客户更是规模庞大。这些客户需要一类 SFA 产品,多家 SaaS 公司都在提供。竞争结果是怎样的呢?排在前面的两家 SaaS 公司都是定制化比例非常高的(超过 70%),而那些坚持做产品化交付的公司则远远被甩在后面。

背后的原因其实也容易理解,大客户都有个性化需求。而一群创业公司,即便创始人的背景也是来自行业里的头部企业,但真要作为乙方搞清楚如何服务这么大规模的甲方企业,需要长时间的积累。上来就做产品,难度肯定很大。

我现在的态度是,在创业早期盼段,定制开发可以做,但目的不同结果就不同。接下来讲讲背后的原因,顺便也讲讲上面这个故事的结局。

1.  明确自己做产品,还是做项目

做项目的公司在中国可以生存,也可以赚到钱,但赚的是“人头钱”。 这个项目,需要 x 人月,每人月费用 y,收入就是 z=xy。

这里有几个问题。

首先,从项目机制上来说,z 取决于 x 和 y 有多大。其中,y(人月费用)各家差不多,可以讨论的范围不大;x 取决于项目需求和解决方案。甲方希望 x 越小越好,乙方却希望越大越好,最后大家“讨价还价”。加上竞争者参与,灰色成本,最终项目金额不小,但可预期毛利却不高。

其次,需求变动风险偏大。许多企业行业标准化程度低、增长快的组织变革频繁,因此本身需求稳定性就不高。

最后,项目型公司发展的可持续性不好。公司没有核心竞争力,技术和销售人才成长后,很容易发现“反正客户我熟,自己单干挣得更多”。所以民营项目型公司很难做大。如果打算只做一个能生存下来的公司,项目型没问题。但做 Saas 产品, 关键在积累。

2. 初期可以做定制开发,但是要明确目的

定制开发是为了赚这笔钱,还是为了积累对行业的理解(Know How),再打磨出锋利的产品?赚钱没错,有的初创公司一年就 100 多万元营收,突然来了个 200 万元的单子,做还是不做?如果为了赚钱,不仅要做,而且要设法做大,做成 300 万元、400 万元。传统软件公司的售前顾问就专业干这个活儿。

如果为了打磨产品,就应该有取舍。创始人和产品部门对自己的产品边界、产品发展方向要有很清晰的认识。对于 100 万元的单子,也要分辨哪些是对未来有用的,哪些是要放弃的。否则,就会被客户牵着鼻子走,自己的产品思路得不到贯彻。

3. 从项目转型产品的时机和方法

在定制开发的路上,一个项目做完了,再做下一个,每个都有差别。难道第 2 个项目中的改进,真的都可以放回第 1 个项目中?很难。如果要照着第 2 个客户的需求改,第 1 个客户也可能不接受。所以最终上手有一大堆不同的项目,每个项目有 80% 相似度,但又各不相同的代码。这些代码如何变成产品?

我觉得,即便是为了做产品的定制开发,写出来的代码将来能放到产品代码库的比例也很低。

为了理解行业业务而做的定制开发,最终也只能把这些理解沉淀到需求文档、方案文档和核心团队的脑子里。转型做新产品时,还是需要重新任命产品经理,由创始团队带着产品经理打磨真正的 SaaS 产品。

那么,从项目到产品有什么要注意的呢?

(1)即便定制,也只做自己边界内的定制。边界外的定制应当去成熟产品,只做好接口即可:如果没有产品能满足,就尽量找第三方系统成商(System Integrator)定制开发。

(2)要在合适的时机出现时,尽早转为产品。定制开发的产能是上限的,即便增加人手也未必能扭转“边际效益递减”的趋势。如果营收增速已经放缓,定制开发团队人均月产出金额也会下降,项目开发组与销售部门的摩擦会越来越大,这时就要考患启动产品开发了。定制开发比例越高的公司越要早些考虑转型产品开发,否则几千万元营收就是难以突破的瓶颈。

(3)CTO 能驾驭的版本数量有限,具体上限与产品复杂度、客户需求差异度有关。为每个定制开发客户提供的软件都是一个独立的版本。每个独立版本未来都有客户需求升级、Bug 修改、环境参数变化造成的软件维护等成本。

(4)通用 SaaS 企业可以升级自己的开发平台为 PaaS。如果 PaaS 能力成熟了,基于 PaaS 的 20% 比例的定制开发是比较容易管理的。将来 PaaS 版本升级,不会影响定制开发部分的维护。这样至少主产品的版本只有一个。

对于行业 SaaS,或产品复杂度不高的通用 SaaS 产品,做 PaaS 的必要性很低,可以考虑加强 API 能力(开放平台),避免未来主产品升级对定制开发部分的影响。

三、从定制项目到产品的组织转型

定制开发组织转型产品开发组织,是一个管理问题,其中最重要的是人的转型。我认为项目开发团队与产品开发团队的人才能力模型是不同的。 所以可以想象,从定制项目到产品的组织转型也是一个非常艰难的过程。

如果是 1~2 年的定制项目开发人员转型产品开发可能没问题。如果是已经做了 3 年以上的定制开发,其团队已扩张到上百人,转型难度就很大了。公司就得招募一批擅长做产品的产品经理和开发工程师。

但我认为,原有“老人”毕竟对行业和产品功能很了解,根据个人特长,无论是专做售前技术支持、客户成功经理(CSM)、产品经理,还是继续做开发工程师,都是非常棒的人选。

我认为对大部分研发岗位来说,技术不是难题,难题往往是对业务的理解能力。所以转型企业应该为这些人才精心设计一条好的转型之路。

四、国内公司对 SaaS 公司的关键共识

1. 共识一:toB 产品不应该免费

前文说过,客户企业采购一个产品,除了采购成本,还有决策成本和培训使用成本,对企业来说并不存在“免费的产品”。即便 SaaS 公司免去了客户的“采购成本",并不能加快客户侧系统上线的速度,即便是从“增加用户数量”的角度考虑也意义不大。

当然,模仿 Dropbox 从 C 端网络效应(病毒传播)到 B 端低成本成交的方式是可以考虑的。但那也是对C(个人)免费,对B(企业)不免费。

具体来说,无论是哪个阶段的 SaaS 公司,都不应该将主版本免费给客户使用。哪怕是“免费30 天,之后再收费”的模式都没有意义。

试用期为 1 周到几周的体验版是可以获得客户线索的好办法,但试用时长也一定要严格控制。通过塑造紧迫感,避免试用者拖拖拉拉,加大服务成本、降低试用专注度。

在实践中,我发现很多创业公司还是会在初期销售選到困难时就退缩为“赠送给客户先用、再用别的方式收取费用”。这个对于企业信息系统这样的高启用成本产品来说,这种做法并不成立。没有“老板已经花了钱" 的压力,谁会去真心推动修改内部业务及管理流程,组织操作培训及考核, 监督各个部门的日常使用,甚至要制定使用系统的奖惩规则。

To B 产品不能免费,这是 SaaS 领域通过几年时间,耗费几亿元形成的第一个共识。

2. 共识二:关于定制开发的选择

“定制大单来了,接还是不接?”—很多 Saas 创始人都和我聊过这个令人纠结的话题。我深深理解,面对“定制 or 挂掉”的问题时,创业者也没有其他选择。

但如果还有别的选择,SaaS 圈内对这个问题是有深刻共识的。我常说,一旦产品版本发生分又,永远不能回头。业内已经有不少公司己经在此事上栽了跟头,为什么?客户新需来没完没了、研发资源被分散、CEO 及产品经负责人的精力被分散。

应对方法有几个:用可配置方式将通用需求放到下一个版本中,先帮客户上线基础功能,尽早完成 API 开放平台:PaaS(需要3年以上长期投入)。更重要的是,CEO 和产品负责人一定要明确自己的产品方向,对偏离方向的单点客户需求要慎重、再慎重地抉择。

3. 共识三:在市场部下设立 SDR 团队

我看到不少以市场线索为客户主要来源的 SaaS 公司都在近一两年开始启动 SDR 团队。这个团队的任务是对市场线索选行分类分级,然后按照预定规则分发给合适的销售团队。

至于以清洗线索为主要任务的 SDR 团队应该放在销售部门还是市场部门。目前的共识是 SDR 与其上游(即市场部)的协作及考核关系更紧密, 应该放在市场部。有一部分 SaaS 公司把 SDR 团队放在销售部门,我建议应该做调整。

4. 共识四:重视构建销售团队开拓能力

在国内,有一大半的 SaaS 公司非常依赖市场线索,也就是说成交客户来自市场线索的比例超过 80%。但市场做得再好,市场线索数量质量的天花板始终在那里。

我认为,创业公司营销体系构建的过程中,要考虑好市场线素和销售自开拓的平衡。市场是长期投入,销售是临门一脚,两者的平衡是 CEO 必须考虑清楚的。 通过与众多 CEO 或销售 VP 交流,凡是成交客户中市场线素比过高的(大于 80%)公司都越来越重视销售团队自开拓能力的培养。这也是图内大部分人的共识。

5. 共识五:CSM 是续费率的责任主体

不少 SaaS 公司还在由销售代表来负责续费,会产生不少问题。我见到的大部分 SaaS 公司都是能达成共识的:CSM 应该背负续费率 KPl。这样公司的总体续费率才有保障。

6. 共识六:工具 SaaS 做小微企业难以有毛利

由于小微企业(指人员规模在50 人以下的企业)支付意愿低、支付能力弱、对管理提高效率的诉求低,工具型 SaaS 公司很难用这些企业支付的首次费用覆盖市场、销售团队的成本。

加上这个群体的企业由于自身经营不善的自然死亡率高,续费情况也很不好。我问过一些 SaaS 公司,得知目标客户中有一部分小微企业,这部分的客户(数量)续费率往往低于 70%,甚至低于 40%。我也看过其中几家 SaaS 公司做的客户流失原因调查,排名前三的原因是:企业没用起来(管理诉求低)、业务转型不再需要(客户业务不稳定)、公司倒闭(客户公司不稳定)。真正被竞品抢走客户的概率非常低。

当然这里有两种情况是例外的。

  • SaaS 公司先销售工具 SasS,而后能转化为商业 SaaS。例如,客户购买有赞微商城基础版,除了 6800 元/年的软件服务年费,也会对交易流水收手续费。这样即便小微客户流失率高,也能沉淀下高价值客户;
  • 基于先发品牌优势,获客成本极低。一些培训行业的产品有这个特点, 由于早起品牌低成本传福,大量客户主动找上门,在官网完成试用注册, 销售团队通过电话就能快速签单。

当然,第二种情况有很大的历史偶然性,第一种情况更有可能成妙复制。

7. 共识七:尽量不收多年单

原本我认为“不向客户一次收取多年服务费”应该是 SaaS 圈的共识。但在与众多 CEO 的交流中,我发现还是有些特殊情况。

  • 现金流紧张,不收多年单公司得关门;
  • 客户企业自然淘汰率高,客单价又很低;
  • 市场竞争激烈,希望通过多年单锁定客户,占住市场。

上面说的 3 种特殊情况,其中第 1 种事关生死没得选择。但在这样的情况下,公司只是在熬时间。如果不做突破性创新,还是难以生存下来。 将来公司关门时,由于欠下客户很多服务时长还未提供,创始人的个人品牌会严重受损。

第 2 种情况,从商业伦理上也说不过去。大量尝试新业务的客户本来不需要 3 年的服务,硬塞一个过去,客户也不傻。这样名不正言不顺的费用,长此以往将影响品牌形象。我建议重新设计价格结构。例如,首次上线时按实施费用的名义收取费用、保住成本:之后通过切咬易流水等方式达到对大客户收更多费用、对小客户收较少费用的目的。这样材能名正言顺、合情合理地获得市场的认可。

第 3 种情况,收多年服务费增加了成交难度。同时,收多年服务费的公司后面的服务大多跟不上,产品改进也容易脱离市场需求。仅靠一纸合同,而不是优质的产品和服务,很难“锁定”客户。

我看到绝大部分公司收多年单,已经“骑虎难下”:上一年已经开始允许直销团队和代理商一次收 3 年或 5 年服务费,如果今年突然停止,公司销售业绩大概率会被腰斩,销售代表和代理商的收入都会大受影响,销售体系将会面临崩意的危险。

我的建议是"逐步收紧”:今年规定最多收 3 年单,明年收紧为 2 年单, 后年开始只允许最多一次收 18 个月的服务费。

我还是坚持 SaaS 公司不应该收多年单,因为 SaaS 的本质是续费。这是 2014 年以来的头部 SaaS 公司走了很长鸾路才达成的共识,希望后来者警醒。

8. 小结

本节主要目的是给后来者参考,同时也是对每个 SaaS 公司的警醒。 在实际公司运作中,週到困难就想换一条路径,这也是人的正常思考方式。我想在这里提醒,这七个坑是前人花高品代价踩过的,如果觉得自己情况特殊还是要踩,也请先多考虑几遍。