企业服务类产品,都有哪些底层逻辑?

人人都是产品经理17小时前

关注
一共是6个逻辑。

编者按:本文来自微信公众号“人人都是产品经理”(ID:woshipm),作者:大井盖先生,36氪经授权发布。

企业服务类产品在国外发展已经成为了主流,但在国内这几年才掀起热潮,大部分还处于起步、探索阶段。习惯了To C 思维的我们,在对垂直场景下的SaaS应用往往没有很清醒的认知,以 To C产品的发展视角来看待企业服务这门生意,只会到处踩坑。本文是一位to B赛道创业公司的CEO,以自身创业从0到1打造多款企业服务类产品的经验,分享其对于企业服务类产品的搭建、设计、运营逻辑。希望对各位有所帮助。

理性看待:

“用户永远没有错”

C端产品的用户表达需求,往往比B端产品的用户表达更精准或者说更明确,人人都可能是C端产品的用户,而B端产品却不是个体的使用决策,是集体使用体验。

俞老师曾说“用户永远没错”,看过产品军规12条的小伙伴肯定记得这一条,大家要理性冷静,俞老师表达的不是字面意思,应该解读为“用户面对问题时,所产生的情绪和感受是真实有效的”。

作为产品设计者,我们需要理解在特定情景里用户的逻辑和反应,然后……考虑满足他们的意见或否定他们的意见,又或者放弃这一部分用户。

做B端产品,我们围绕着用户核心的需求,专注极致。与其说用户在选择我们,其实因为资源有限,我们也在选择用户,不是所有功能我们都能做 ,最终只能在一个维度里解决最“痛”的点。

做减法比做加法更需要策略与克制,无论to B产品还是to C产品,最终的解决方案都应该是最简单的极致体现,以最短路径和最低资源成本满足用户的需求。

需求评级:

建模,制定前置规则

关于产品需求优先级的评判,如果没有统一标准,不同的产品经理估计能诞生一千种不同结果。

B端产品经理接受需求的来源要比C端产品丰富而复杂,对于B端产品经理,梳理需求的优先级开发排序是一件“左右逢源”的难事,要考虑服务部门的情绪,要照顾业务部的指标担当,还要兼顾公司市场拓展的进度。

有些需求是老板给的政治任务,有些需求是销售部提的(如果不做就分分钟影响公司营收指标),有些需求是为了支持运营活动的,有些需求是为了减轻客服团队重复答疑工作量的,以上种种都是产品需求来源的内部渠道,需求还包括用户使用后的反馈、行业技术进步等等,对于产品经理而言,学会将需求合理的排期是一门硬核技能。

由于之前踩过坑,后面在做蓝领送工SaaS时,我们在早期就开始建模型,形成内部产品需求优先级判断标准,产品同学接收到需求后,按照划分的四个维度去归类,根据“一大带四小”的原则去快速启动排期开发。

如果功能上线后,用户的使用反馈不达预期,排除其他因素,是需求的源头出了问题,我们会组织内部讨论,修正更新判断标准。

举个实战例子,当接到个别客户提出的需求时(判断个性化需求or普遍存在的通用性需求),我们可以从以下五个维度评估:

  • 疼痛的深度:个性化需求对于用户而言,是不是刚需,优先做“雪中送炭”的需求,再排期“锦上添花”的需求。

  • 影响的广度:是不是牵扯到上游和下游不同业务流程的完整性,如果有紧密关联,不处理则会影响用户的正常操作,就像前面提到的钉钉绩效考勤表。

  • 寻找最大公约数:是某个特别用户的唯一需求,还是普遍存在却被忽视的隐藏需求。产品要解决用户普遍存在的问题,就好像数学上解题寻找最大公约数,这一点也会涉及到公司商业模式,有些产品确实解决了用户问题,但撑不起一家有体量的公司活得很滋润。

  • 关乎公司发展布局:有些需求必须开发不是单纯为了用户,和公司的战略发展决策有关,比如刚刚提到的我们公司建立判断模型,这个模型是动态的,跟着公司目前的发展节奏和行业所处生态位。

  • 技术评估:除了以上四点外,还需要考虑一下技术层面,是否现有技术可以实现,实现成本是否太高。

权衡需求优先级:战略定位、用户影响范围、实现成本。

系统框架:

搭建最小可用的业务闭环

对于咱们做B端产品的同学来说,得有系统的基础建设意识,包含业务梳理、个性化需求评审、产品架构设计等流程。

企业服务类产品,在设计时要考虑能覆盖全场景、完整业务链路的闭环,因为任何一个环节的缺失和不完善,都会导致客户的业务流程无法正常运转。

举例来说:

钉钉现在成为了大部分企业的内部OA。

如果公司HR想要做上月员工的薪酬绩效,钉钉不能提供员工的日常考勤记录,需要HR从其他系统导入或者人工录入,那HR想要实现的绩效核算就无法推进,这样无法完成一个薪资核算的闭环,代表它不能满足用户的基本需求。

当然,对于SaaS产品来讲,稳定性压倒一切,服务器不能宕机,同时产品风格要保持统一连续性。

如果后期,平台想要做功能延伸,在产品架构规划初期就要预留可拓展的空间,始终为用户提供持续稳定的安全感,to C产品可以追求UI的新奇,B端产品仍然以稳定为王。

用户体验:

整体感知,保持一致的表达方式

对于同一个角色,如果行业内有多种不同的称呼。就好比城市里的Kevin,春节返乡,被人叫“狗剩”一个道理,假设城市和农村两个地域场景重叠在一起,那就是双城记了。

每一处给用户表达的内容,都需要是一致的,不做多样化。从注册登录开始到退出结束为止,从 “首页”跳转到“我的”,界面视觉、文字内容与标点符号,给用户一个完整的情境。

举个例子:

在蓝领送工系统里,我们将人力公司的业务场景拆分后,发现5个用户角色就已经可以覆盖全部的业务流程,那我们就花时间去推动用户接受旧角色的统一“新名称”,把之前叫“业务员”、“工头”的全部引导成叫“劳务经纪人”,这样无论是行业内的沟通成本有明显降低,还是角色的职责定位也越发清晰明了。

功能克制:

围绕主流程,抓大场景

上周业务团队在复盘时,对目前的产品提出了一堆的诉求,包含了个性化的需求、业务快速推进过程中的市场策略需求等等;针对这次需求追源大会,我们内部达成了共识,专注解决产品创立初期的核心问题,先有了树干再发展枝叶;针对B端产品,涉及到客户繁杂的业务流程,里面可以衍生的需求非常多,一不留神就会陷入无穷尽的开发旋涡。

做大而全很容易,做少而精很难,全面的东西是平庸的。

如果,咱们没有化繁为简的能力,就要克制自己做多的欲望,产品都是被“加法”作死的。

不堆砌功能,功能一定是服务于特定场景下用户的整体体验,没有脱离场景的单独功能。做多,本质上源于不自信,如果围绕核心需求提供的解决方案最优,用户的黏性自然强,不需要叠加一堆杂七杂八的功能作为陪嫁。每天砍掉几个需求带来的价值,大于提出几个新需求。

企业服务类产品解决客户的需求可以大致分为两类:“开源”或者“节流”——开源表示能够为客户带来新增营收或者提高收益率,节流就是常说的降本增效。

对于任何新客户,为开源需求买单的预算远比节流需求更充足,意愿更强烈。

举个例子:

虎蛙产品的目标客户是人力资源公司(劳务中介),我们在确定为乙方提供数字化服务时,把行业内的全业务场景做了三段式流程划分,即“甲乙双方的用工订单”、“乙方分包与招聘”、“内部管理及结算”。

考虑到当前国内的用工市场情况,买方和卖方发生了换位变化,我们设计产品结构(骨骼)时,舍弃了乙方和甲方(用工单位)签约的CRM场景,这个场景我自己认为不是主流需求发生地,做这个决策谈不上客观,基于自己对行业的理解与判断。

影响产品成功的关键因素,除了创始团队对特定市场的深刻理解与前瞻预见之外,还有团队对资源的掌控调用能力。

产品经理要深入了解行业,了解行业后才可能从全局视角看产品功能规划,先有了产品结构的骨骼,才慢慢长出肌肉和皮肤(功能/UI/界面交互)。

有效流量:

用户痛点=需求程度*需求频次

聊聊流量,建立在痛点满足基础上的流量才是有效流量。

痛点 = 需求程度 * 需求频次

有效的流量必然是极度需求且高频需求的。

如果不是建立在痛点基础上,仅仅是通过一些营销手段获得了流量,这种流量根本没有任何黏性可言,活跃度也会极差。

用户的获得感>用户的产品使用能力,流量才不会离开。

该文观点仅代表作者本人,36氪系信息发布平台,36氪仅提供信息存储空间服务。

(0)

相关推荐