吴晓波:SaaS产品经理应该具备哪些能力?|想来精选

去年,吴晓波在演讲中说:“我将2020年称为中国企业服务元年。” 确实,因为疫情,2020企业协同服务进入了大众的视野,钉钉、飞书、企业微信等产品一飞冲天,同时也推动了整个SaaS行业的快速发展. 例如,一些依赖钉钉的 SaaS 公司在 2020 年的收入增长了两倍多。

中国SaaS行业这几年确实开始飞速发展,工业互联网概念的兴起也有功劳。作为一名SaaS产品经理,我有幸见证了这个行业这几年的快速变化,也看到了想进入这个行业的同行们的一些困惑——SaaS产品经理应该具备哪些能力?今天我想谈谈我对这个问题的看法。

无论是B端还是C端,产品经理都是肩负起对产品进行规划和管理,创造用户价值和商业价值的责任人。我觉得一个好的产品经理应该能够在宏观层面深入行业,洞察大势;微观上,他不应该傲慢不浮躁,把每一个PRD都写好,把每一个原型都画好。因此,我认为产品经理的能力模型可以抽象为“认知-判断-执行”。

其中,“认知能力”决定了产品经理的能力上限,“判断能力”代表认知深度和专业性,“执行能力”是产品经理的基本能力。

一、认知1.认知SaaS

SaaS是Software-as-a-Service的缩写,意思是软件即服务,即通过网络提供软件服务。目前SaaS产品主要分为三类:行业SaaS、功能SaaS和通用SaaS。

SaaS公司向客户提供产品和服务的交付方式主要有以下三种:

由此可见,SaaS的行业经验门槛比较高,对产品经理提出了非常高的要求。具体到工作上,产品经理不仅需要对整个行业有一定的了解,还需要对自己产品的垂直领域有深入的了解。

1)SaaS 的商业模式有哪些?

SaaS的商业模式是通过大规模服务客户来摊销公司的运营成本,从而获得收入。

其收入公式=(SaaS客户单价*客户数量)-公司运营成本。因为 SaaS 不是一次性支付,而是订阅续费模式,如果要始终保证自己的收入,核心指标就是租户的续费率。

目前我发现国内一些公司基于SaaS模式有一些新的商业模式。主要有两大类:

2)为什么这些年来SaaS如此受追捧?

如果你对国外互联网有很好的了解,不难发现国外顶级互联网公司大部分都是to B,比如微软、IBM等;而国内互联网巨头企业仍以C.

随着移动互联网下半场接近尾声,C端已经成为一片红海,但国内的工业互联网依然拥有巨大的蓝海市场。此外,去年疫情的加速和国家的倡导,催生了大量的to B公司。我们可以看到,越来越多的toC公司正在布局B端,比如BAT、今日头条等。

目前B端服务IaaS、PaaS、SaaS模式中,SaaS是最接近客户的模式;同时,SaaS模式本身自然有两个优势:

SaaS公司在足够高的续订率的基础上拥有稳定的客户群和稳定的现金流;随着SaaS产品的打磨,产品的标准化能力越来越强,同时产品的规模能力也越来越强。访问的边际成本也越来越低。公司毛利率可逐年提高。

SaaS商业模式不仅拥有稳定的客户群,而且毛利率逐年上升;同时,与传统行业相结合,爆发出工业互联网还有巨大的想象空间,这也是近年来SaaS受到资本热捧的原因。

3)什么样的市场适合SaaS模式?

如果我们选择创业公司或者公司转型SaaS,在抛开外部市场竞争的情况下,一定要考虑自己想进入的赛道,市场规模能否覆盖公司的运营成本。其中,市场规模=客户付费能力*客户付费意愿*客户数量。

那么什么样的市场适合SaaS进入呢?

橄榄市场:

橄榄市场最适合SaaS模式,即头部客户少,客户数量一般,腰部客户多,长尾客户少。

国内龙头企业普遍存在数据私有化和服务定制化需求。太多的SaaS公司很容易陷入“项目制”的陷阱,走上和软件实施公司一样的“不归路”。

但行业的尾部客户处于“生死边缘”,生存时间短(中国企业平均生存时间为2.5年),支付意愿和支付能力差,拥有很高的死亡率。同时,他们还需要针对新的长尾客户,不断投入获客和营销成本,投入产出低。因此,腰部客户是SaaS最理想的客户群体。

这里需要特别注意的一点是,在当前国内竞争激烈的营商环境下,中小企业的支付意愿极低,每一分钱都要花在最前沿。所以,如果一个SaaS产品不是中小企业刚需(一般来说,越接近花钱或盈利的业务,​​“刚需”的程度就越高),那么SaaS企业就很难以这种市场规模获利,这就是为什么市场上有很多。SaaS公司“掌声不响”的根本原因。

客户单价高的市场:

在一些马太效应严重的行业,或者一些GMV超过万亿的行业,SaaS也有机会。

让我们回到这个公式:市场规模=客户支付能力*客户支付意愿*客户数量。如果客户数量一般,但客户的支付能力和支付意愿极高,则有足够的盈利空间。据我所知,市场上有几家类似的SaaS公司比较红火。

但我认为在这个市场上,最好的交付方式并不是纯粹的 SaaS 交付模式。因为在马太效应严重的行业(或者客户“有钱”的行业),大多是龙头大企业。如前所述,这类企业或多或少都有定制化需求电动执行器as25说明书,很容易导致SaaS公司陷入“项目制”的陷阱。目前国内SaaS公司面向这个市场的解决方案主要以“项目系统+SaaS”的形式交付,或者“aPaaS+SaaS”(有机会跟大家聊聊SaaS公司是否要做aPaaS) )。其实是对企业把握市场需求能力和战略决心的考验,很容易“一不小心”

2. 认知 SaaS 产品

1)SaaS产品和普通to B产品有什么区别?

如前所述,SaaS商业模式的本质是通过服务于大量客户的数量来摊销公司的运营成本,从而获得收入。产品端的要求是满足大客户的需求,这是与普通B端产品最大的不同。

因此,SaaS产品必须具备两个能力:

相应地,SaaS产品经理需要具备:

2)SaaS 产品的生命周期是什么?

与其他产品一样,SaaS 产品也有生命周期。吴昊先生的《SaaS创业路线图》会有更清晰的答案。推荐大家阅读,这里不再赘述。下面重点跟大家聊聊SaaS产品MVP阶段和C端产品的区别。

C端产品MVP流程。如下所示,

在产品规划设计中,C端产品需要不断为用户提供价值。用腾讯的话来说,“一切以用户价值为基础”。假设你的产品的最终价值是帮助用户更快到达一个地方,那么在MVP版本的设计中,你需要做的就是交付一个成本更低、到达一个地方更快的工具。从产品功能层面,您需要确保交付产品的每个版本的完整性和可用性。如上图所示,给一个滑板而不是一个轮子。

以及B端SaaS产品的MVP阶段,如下图:(ps请忽略我画的车只有4个版本..)

在用户价值上和C端是一致的,也需要帮助用户更快到达一个地方。

但需要注意的是,在产品功能设计层面,如果产品的最终价值是帮助用户更快到达某个地方,但现阶段受限于技术的实现,最快的交通工具可以只做一辆车,然后你就必须造一辆汽车。而不是首先提供滑板,然后是自行车。如果你这样做,每一次后续的版本迭代都是一场“重构”灾难。

二、判断

判断力实际上是依附于认知能力的。认知错了,判断就错了。在实际工作层面,产品经理的判断体现了他对需求的真实性、价值、优先级的判断。

1. 判断需求

在一般SaaS公司的架构下,B端产品经理一般与客户保持距离,“客户成功”的角色通常夹杂在两者之间。因此,目前对B端产品的需求大部分来自于客户成功同事传递的需求。在这个过程中,存在大量的信息失真,所以saas产品经理经常要做一件事——判断这个“需求”是否是需求,存在大量的信息失真,所以saas产品经理经常问做一件事-确定此“要求”是否是要求。

1)是否收到请求?

在现实世界中,人们往往下意识地反馈解决方案。例如,一个朋友告诉你,你拿了锤子和钉子给我。如果你不深入挖掘,把锤子和钉子当成他的实际需要,你将无法发现他的真正动机其实是挂婚纱照,也许我们能提供比锤子和钉子更好的解决方案。因此,在一些日常需求清单中,产品经理要注意区分什么是客户的真实需求,什么是客户自己提供的解决方案。

行业中已经有规范需求的范例。如果你能养成这种思考的习惯,你就可以轻松跳出解决方案的桎梏。范式如下:

作为【特定角色】,需要一种方法【满足xxx的需求】,然后【直接对用户有什么好处】

我们在上面的例子中替换。

作为一个已婚人士,他需要一种方法将他的婚礼相框挂在墙上,提醒他婚姻的甜蜜。

让我们再举一个例子:您的客户给了您反馈。我需要在系统后台的首页看到今天店铺的汇总交易数据。

遵循这个范式。

这种范式最好的一点是,解决方案被刻意缩写为一种方法,以便让您专注于需求,同时拓宽您的思维。避免被框定在特定的解决方案中,然后才能了解客户的基本需求。

就拿上面的例子来说,如果你想错了,一定要考虑在后台添加什么类型的数据到首页以及如何添加数据。如果你的思路正确,我想你会找到越来越好的解决方案。

2)判断需求的合理性

在B端的产品设计中,产品经理会遇到一些对某个角色来说合理可行的要求。但是,此要求对组织或其他角色有一定的利益和损害。这时,产品经理就需要有很强的利益平衡能力。

在to B行业,有一个老花生不太认可的产品“流派”:TO BOSS流派。他们认为,在B端产品的设计中,必须优先考虑决策者的需求而不是用户的需求,而BOSS就是典型的决策者。当然,我认为 TO BOSS 大部分时间都不是问题。毕竟下单和续约的决定都在BOSS身上,这是可以理解的。但一切都需要批判性思维和辩证地看待决策者的需求。

两个例子:

首先是去年疫情期间,一些营销SaaS公司,为了满足BOSS的需求,推出了全员营销功能,帮助BOSS更好地监控员工带来的客户数量,甚至将这个功能引入到市场作为亮点功能。

我对此事的看法是,没有权利,就没有义务。员工和公司应该是双赢的模式。如果只有单方面的员工义务,公司在某些方面难免会出现无形的损失。这不是一个长期的计数。

第二个例子是前年,我们在产品上遇到了类似的需求。当时,为了更好地了解门店的客户画像,业务方让业务员填写了门店所有的客户印象信息,完成率达到90%。更多。对于业务员来说,如果同一天有很多顾客到店,这基本上是不可能完成的任务,而且由于印象数据信息量相当可观,对业务员也没有实质性的帮助。

当时我们也是先根据BOSS的逻辑进行产品设计。运行产品一段时间后,我们发现了两个严重的问题:

从上面的例子可以看出,在to B的产品设计中,如果产品具有长久的生命力,就需要平衡整个生态环境中各个角色的利益,而不是盲目地站在决策者。

3)确定需求的优先级

需求优先级是产品经理的日常任务之一。如果排除一些特殊原因,比如老板任命、政策要求等,我一般按照投入产出比来判断。

ROI=需求价值/需求实现投入成本

需求值=用户数量*场景频率*场景重要性*用户效用

(用户数量一般取决于该需求所涉及的用户规模)

一位同事曾经告诉我,他在腾讯微信上了解到,只要有一点小改动,都需要张小龙审核确认。,有大量的功能只需要在群内审核即可通过。我们为什么不像微信那样做呢?

其实仔细想想就可以理解,因为对方产品的用户数量差了近几十倍,用户不在一个数量级,需求价值也不同。

不知道大家有没有注意到,一些优秀的产品在一些异常场景的处理上并不尽如人意,只保留了人工干预的入口。其实原因是场景出现频率太低,需求值太低。

对于其他产品,即使场景发生的概率是万分之一,也需要介入才能满足需求。为什么是这样?主要原因是这个场景对用户来说极其重要。就像我现在正在处理的交易环节,任何细节上的异常过程,即使发生概率极低,也需要介入解决。

在需求实现的投入成本方面,这需要产品经理有一定深度的技术理解。一般来说,对技术有一定了解,对系统实现有一定了解的产品,对人力投入和研发时间长短有一定的判断。

2. 判断方案

在确定了需求之后,对解决方案的优劣的判断也是极其重要的。对于SaaS产品来说,产品标准化是最重要的能力之一。SaaS 产品经理必须敬畏解决方案。如果你在过去的设计中设计了一个“病态”的解决方案,那肯定会给你后续的产品迭代带来很多困难,甚至将公司拖入泥潭。

那么如何判断一个解决方案是否可行呢?可以从以下两点来判断。

1)方案能否满足用户需求

解决方案能否满足需求,可以代入用户的视角,检查解决方案是否满足需求,基本可以由对其有深入了解的用户来判断。

2)解决方案是否具有可扩展性和通用性

可扩展性和通用性要求产品经理具有强大的抽象能力,并了解业务模块的边界和关系。比如B端产品经理经常接触的后台权限RBAC模型就是一个经典的产品抽象模型。下图是电商推广的产品模型。因为这件作品太抽象了,所以有机会和大家谈谈如何设计它。

但在判断方案时,不仅要求产品经理能够抽象建模,还要求产品经理对抽象粒度有很好的把握,避免过度设计。

过度工程是指设计的系统复杂臃肿,过度封装,一堆继承、接口和无用的方法,以及超复杂的xml配置文件。简而言之,客户的需求是杀鸡用刀。你设计了一把杀鸡用的刀。杀鸡为什么要用刀?

比如有一些C端操作后端或者轻量级后端,权限设计非常简单,甚至没有控制相应的权限。如果你是公司的产品经理,一定要用最复杂的RBAC(3)那个权限模型用在你的后端,明显是过度工程。

如何判断是否存在过度设计?只取最常见的场景进行查看。如果配置或操作变得极其复杂,则可能存在过度设计。

三、执行

大家应该不难发现,由于市场对产品定位的理解不同,对产品的要求也不一致。和一些传统的软件实施公司一样,对产品经理的需求一般只需要进行需求管理,而在一些新兴的互联网公司,一般要求产品经理担任项目经理职责的一部分。

产品经理的主要职责还是管理需求,今天我们主要讲这部分。

以一个需求从挖矿到上线为例,一般常规的互联网软件协作流程如下图所示:

在上述过程中,产品设计是产品经理专业能力的具体体现。在这里,我将重点介绍产品经理在产品设计中需要具备的技能。

我们主要根据用户体验五要素的方法设计相应的方案。很多同学可能对这种方法很熟悉,但在实际工作中,真正能按照五要素拆解设计方案的产品经理很少,甚至有些“老手”也想不通他们的PRD是如何对应的五要素。的。

用户体验的五要素如下图所示:

1. 战略层

在设计策略层时,产品经理需要能够明确回答两个问题:一是“用户可以从产品中获得什么价值”,二是“我们可以从产品中获得什么”。用余军先生的话来说,产品是用户与企业之间交换价值的载体。

战略层一般对应珠三角的背景描述。

以后台权限管理模块的方案为例。战略层是:

往往很多产品经理,因为战略层面的不清晰,导致整体产品设计偏离战略层面,导致产生“无效”的产品计划。

2. 范围层

范围层的定义是指产品的范围,包括产品边界、功能范围、用户需求范围等。范围层的设计是对产品经理能力的考验。它不仅需要考虑范围如何实现战略层的产品目标,还需要对用户的需求有很强的把握。

如果产品经理对范围层没有很好的理解,很容易在产品设计中产生一些“大而全”的产品方案。这种解决方案如果仅在准确性和完整性方面没有问题。是的,但无法回答“为什么是现在”这个问题,这会导致研发团队在当下花费大量时间处理一些低价值的功能,从而白白错失市场机会。

关于范围层的判断,以我之前设计的一个0-1的小产品模块——《CC笔记》为例。

CC Notes功能背景:

我们发现一线业务人员在给出官方产品介绍资料后会用微信做笔记(微信有自己的功能,类似于有道云笔记,主要功能是自由编辑图片、视频和插入地址)重新整理产品介绍资料,并通过微信转发给目标客户。

经过深入了解电动执行器as25说明书,我们发现业务人员觉得官方介绍信息过于“官方”,没有用户视角,目标客户在查看时需要二次信息转换。有两个问题:

那么我们在设计的时候,考虑到第一个版本,首先要完成CC笔记的替换。战略层定义:

当需求明确,战略层面明确时,下一步就是如何框架产品范围。

用抄送笔记功能完成对微信笔记的替换,在产品价值公式中,产品价值=(抄送笔记功能价值-微信笔记价值)-替换成本>0

因为我们当时的产品载体是微信小程序,所以从操作体验来看,非原生的抄送笔记功能无法超越微信笔记。在这个公式中,抄送笔记功能值=自己的编辑能力+数据能力。其中,CC Notes 自身的编辑能力是一个短板。战略上,通过加强数据能力,降低抄送笔记到微信笔记的替换成本,产品价值>0。

在数据能力的设计上,我们希望客户在浏览抄送笔记内容时,能够捕捉到客户在每个内容上的停留时间,从而更好的帮助业务人员了解每个客户感兴趣的内容点。

当时我们的产品没有这么强的数据采集能力,和研发同事评估这个功能的开发周期比较长,所以在数据采集上做了妥协,功能范围只完成了大规模客户数据的收集,例如单篇文章。笔记的阅读时间,打开的次数,打开的时间等等。

在降低替换成本的设计中,考虑到大部分业务人员已经编辑过微信笔记,我们主要考虑支持两种方式:一是将微信笔记转成长图上传到抄送笔记;另一种是支持微信笔记的内容复制、粘贴到抄送笔记上。

最后,我们框架的范围如下:

第一版主要是完成CC注释的替换;第二个版本支持管理员审核,避免内容风险。随后,我们进行了两个项目的试点启动。运行两周后,我们发现数据并没有达到预期,只有极少数业务人员完成了笔记的创建。通过数据分析得出,主要原因是更换成本太高,很多业务员在粘贴和编辑的过程中出现了很多问题。

通过这个例子,大家应该会觉得把握功能范围并不容易。我自己对功能范围的总结就是要和战略层紧密结合,战略层之外的功能要坚决去掉;框架范围内的功能必须满足用户的需求。

如果我再次重新构建范围,我将对其进行修改,如下所示:

图中黑色部分为修改后的部分。我会去掉一些其他类型的分享,只保留核心分享功能。更换成本,管理员为业务员预设模板,降低微信笔记更换成本。

后来我们还通过后台预设模板的小功能改动,成功将抄送笔记变成了推销员最喜欢的功能之一。

3. 结构层

对于非信息化产品,结构层是主要的交互设计。产品经理需要多思考什么样的交互能让用户开心?市场主流用户的操作习惯是什么?你的目标用户群的主流交互流程是什么?是否可以通过交互设计等降低用户对功能的认知,减少用户的误操作?

4. 框架层

框架层的设计一般集中在一个功能性的页面上。在设计时,需要对框架进行划分,以帮助用户首先看到他想看到的内容。在目前的互联网功能划分下,一般的UX/UI同事都会进行相应的设计,这里不再赘述。

5. 表示层

在目前的互联网产品设计中,主要是视觉设计,一般的产品方案不涉及这一层。

作者:老花生,5年SaaS产品经验。目前房地产营销垂直行业,拥有微信生态营销和丰富的B端0-1产品经验。

本文由@82岁花生原创发表于人人都是产品经理,未经允许,禁止转载

题图来自Unsplash,基于CC0协议

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论