聊聊B端产品设计和SaaS PM生存之道

写在这篇文章的前面,我先交代几件项目上最近发生的事:
1)我所负责的一个微信CRM的项目,刚刚撬了竞争对手的一个标杆客户,对方已经签了一年的合同,但依然在合同期还有9个月的时候选择了我们,我们称为事件A
2)我们的一个客户,在密集试用了我们的产品两个月后,最终还是没有购买,我们称为事件B

聊聊B端产品设计和SaaS PM生存之道

这两件事给了我们信心,也给了我们打击,我们事后总结反省了下,大概总结下来如下认知,本文将着重探讨:

  1. SaaS 或 to B的PM和传统软件PM有何区别?
  2. to B产品经理生存的根本技能或者素养是什么?
  3. to B产品经理一般应该关注哪些指标?
  4. 我们如何评判SaaS产品经理的工作成效?
  5. to B产品经理的成长迭代之道

接下来SaaS产品可以预见的趋势是怎样的?

在任何SaaS公司的早期,产品就是公司本身, 没有那么多虚头八脑的东西,公司创始人是谁、融了多少钱都和客户没什么关系,客户就只认产品是否能解决他们的问题,以及代价是否在可接受的范围之内。

所以SaaS产品经理某种程度上就是家公司的CEO,这个角色是如此的重要,他们不仅要懂业务逻辑,还要知道客户痛点,更要紧的是,他们需要持续关注客户体验,从事件A来看,SaaS的产品评估周期已经从一次性评估变成持续性评估,以前可能是一年评估一次,现在基本都是一个月,一周,甚至一天一次,我们要时刻清楚产品是否真正解决了客户的问题,否则他们可能随时跑路。

这件事情对我们的获客策略调整也提供了非常大的参考意义,我们甚至将“使用过xx竞品的潜在客户”视为一个特定的用户画像,我们发现了竞品一个或多个无法解决的问题。我们甚至针对性的产出了几篇文章,很多客户都是在搜相关竞品关键词的时候,看到了我们的替代性分析文章,这个技巧很“贱”但却很有效,我们成功的截胡了相当一部分本来冲着某些特定竞品的人来试试我们的产品,转化效果相当不错。

01.SaaS 或 to B的产品经理和传统软件PM有何区别?

考虑到留存续费的因素,一个非常直观的区别就是,SaaS产品的迭代速度和交付体验是远远高于传统软件产品的,传统软件的买断模式意味着厂商没有足够多的动力去迭代产品,而客户也没有足够多的动力去更新产品(因为升级体验太差,还说不定需要额外收费,据说很多大型ERP厂商的主要利润就是靠这个模式)。

我常常和初次接触我们的客户提到,一个月之前你来看我们的产品,和现在的比起来简直天差地别,如果你现在拒绝我们的产品,不要紧,但一个月之后我们再来看一次,你会心动的。所以你现在大可以不做购买决定,我们先用一个月看看,此时客户往往并不会拒绝给我们一个持续一个月的考察窗口期,我们就可以非常从容的培育客户意向了。

02.to B产品经理生存的根本技能或者职业素养是什么?

在一家早期的SaaS公司中,产品一般都会出奇的“烂”,烂可能体现在功能的缺失上,也可能体现在体验的缺失上。功能缺意味着满足不了客户需求,体验缺意味着很难满足客户需求。

拿我们鲸奇SCRM为例,我们有个“自动通过好友自动发招呼语”的功能,但比较奇葩的是,因为前端开发资源的限制,这个功能里招呼语的配置是无法在前台进行的,需要客户把话术发给我们,我们运营人员去后台配。这是一个非常吃力不讨好的体验,一方面客户在试用的时候非常容易错过这个功能,从而引起困惑;而我们也要搭上运营人力,从而引起摩擦。

从开头提到的事件B来看,客户之所以在试用了我们产品3个月之后还能抛弃我们,显然在于我们的产品在他们实际业务的过程中没有产生太大的作用和依赖性,这其实并不稀奇。稀奇的是,我们竟然花了2个月都没有发现和解决问题!

所以我们现在逼迫产品经理必须在客户试用的前两周之内充当全职客户成功人员,包括而不限于客户的产品培训、需求调试和交付。

我们认为,以一个业务人员的标准去要求to B的产品经理是不过分的,甚至是必要的。

甚至有几次,我都让销售和商务人员刻意回避了客户的远程培训会议,而让产品经理全程跟进。我需要让他们清楚,他们设计出来的产品,在客户那边能拿到怎样的反馈。这很有趣,因为这个安排的最终结果要么是我们的产品经理疯了,要么是客户疯了(当然他们一起疯也是有可能的)。

培训会议结束后,我能明显的感觉到我们产品经理的脸上有些挂不住了。而在接下来的几天内,她都是第一个出现在公司,又是最后一个离开的。

03.to B产品经理一般应该关注哪些指标?

至少在SaaS产品的早期,客户的留存率(retention)、客户的生命周期价值(LTV)甚至公司月度性重复收入(MRR)都是不值得关注的,一方面是因为这些数据前期无法准确计算,一方面我们有更重要的东西需要去看。

首先就是产品的使用率(Overall platform usage)。

产品的使用率包含两个方面,第一是客户使用产品的频率如何,是否持续每天使用。要知道,作为一款微信CRM产品,我们的客户一旦停止录入客户联系资料时,就意味着我们的产品失去了价值和生命力。

其次是客户到底使用了哪些功能。每天我都会让产品负责人拉一张这样的表*(彩蛋1),里面详细列出了哪些客户在使用哪些具体功能:

聊聊B端产品设计和SaaS PM生存之道

产品使用率分析表,使用某BI工具自助配置,详情参见文末彩蛋

我们意外的发现,作为一款微信自动化+CRM+销售监测产品,我们绝大多数的客户竟然只使用了自动化功能,而忽略了CRM这个我们看来比较核心的场景。这要么说明我们的CRM上手极难(实际上所有CRM上手都不简单,因为前期没有客户数据录入的情况下,价值体现不够明显),要么说明这个功能对客户价值不大。但无论如何,这张表都会让人心慌。尤其是那位产品经理。

其次,是特定功能的接受度(Feature-specific adoption),这个东西似乎很少见,原因在于,我们发现,无论我们推出多少功能,客户都基本只使用其中的某40%,比如有的客户就只使用自动化却从不用客户分层和商机看板*(彩蛋2),也有的只用朋友圈和群发却不用自动化….这是很有趣的现象,因为他们对于功能的使用似乎断层了,也就是完全没有接受。

所以我们评判to B产品经理(早中期)工作成败的关键标准就是上述两个,而这两个标准要求PM必须充分的了解客户的需求和产品使用情况,因此他们频繁的和客户沟通也就不足为奇了。

04.to B产品经理的成长迭代之道

你看,SaaS的产品经理绝对不是一个轻松好活,相反它门槛极高,对于商业模式不够洞察、或者业务经验较少的PM往往很难独当一面。

05.接下来SaaS产品我们看到的趋势是怎样的?

就我们的实践和观察而言,我们大致看到两个主要趋势。

1)中台机会。

当前有很多SaaS产品尝试走平台路线,这个太难做了,机会很少。

我们更想做一个中台,甚至我们觉得中台这个词都有点大,我们更多的是想做一个 single-point service (单点服务,或单点解决方案),在大型平台里充当垂直领域的解决方案,比如我们发现企业微信的生态里就有很多新零售行业的标杆客户需要各项能力满足,CRM便是其中非常典型的一项,所以我们最近在频繁的寻找新零售行业做标准化和定制化的探索。

另外,我们也发现很多教育或者知识付费类的客户*(彩蛋3),也经常使用小鹅通做活动和课程交付,为此我们针对这样的平台也提供了API对接,直接将客户信息导入到微信CRM中,做进一步的客户画像和分层营销管理。

这些场景其实都不大,我们充当某个客户“外部中台”的特定服务能力,这是我们对未来Martech领域的一个认定趋势:做中台,而不是平台。

2)社交机会。

钉钉虽然拥有众多的SaaS应用生态,但还是没有切到商务沟通场景,而更多的是一个内部沟通工具,这在我们看来是很危险的一个迹象(和微信及企业微信相比)。商务沟通场景主要还是在微信生态中进行,甚至以后还可能在头条系中进行(比如抖音/快手)。我们认为这些社交产品的商务类型沟通是一个非常值得关注的趋势,实际上我们的鲸奇SCRM目前就完全基于微信沟通做后续的CRM和自动化延展。其中的S,也就是Social,也将会逐步拓展到其他社交软件生态中。

巧的是,国外知名客服SaaS的高级产品经理Ramin Shokrizadeh 在最近的采访中也提到了这一点,她是这么说的:

聊聊B端产品设计和SaaS PM生存之道

北美的Facebook Messanger一定会向Slack发起冲击,而亚洲的Line 和 微信其实早就已经开始承载各类商务沟通。而另外一个insight就是,由于这些平台都有一定的自动化能力(bot),所以如何通过标准化的话术SOP(也就是她提到的copywriting,文案能力),去适时的触达客户,孵化线索意向,就是一个非常值得探索的问题,这个话题我们在上一篇文章中讨论过,有兴趣的朋友可以移步阅读。

春阳兄,微信公众号:SaaS聚义堂(ID:saasjyt),SaaS老司机春阳日常操作笔杆子的地方,文章更新的慢,但保证篇篇精品,各位看官请不要嫌弃。

业界动态

权限管理平台的产品设计思路

2019-10-16 15:56:06

业界动态

新版本上线前期,产品经理要做那几点事?

2019-10-16 16:17:32

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索