企业服务类产品底层逻辑

上周,在重庆出差时,老裴晚上给我发了一条消息,说她终于理解我为什么总说虎蛙是招聘版的有赞了,关于这个问题,回来后我们有过深入交流。

企业服务类产品底层逻辑

从虎蛙开始为人力资源公司(劳务中介)提供服务开始,我们一直说自己是“招聘赛道的有赞”,对标有赞一方面是业务场景的相似性,另一方面是发展路径的借鉴意义。当然,有赞是服务商家,虎蛙是服务人力资源乙方,在大的行业背景下,我们是完全不相关联的独立个体。

这两年人力行业很火爆,准入门槛低但天花板明显的生意,大家都还是愿意试一试的。对于制造业产业结构的变化和社会用工人群的变迁,未来3-5年,人力赛道的核心竞争力还是招聘交付能力,虎蛙在做的就是帮助每一个客户提高招聘交付能力。

作为一家深耕企业服务类产品(人力)的公司,我们内部对于to B产品的底层逻辑,有一些自己的见解和认识,和小伙伴们分享,欢迎多多交流!

1、理性看待:“用户永远没有错”

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

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

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

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

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

2、需求评级:建立判断模型

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

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

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

由于之前踩过坑,后面在做蓝领送工SaaS时,我们在早期就开始建模型,形成内部产品需求优先级判断标准,产品同学接收到需求后,按照划分的四个维度去归类,根据“一大带四小”的原则去快速启动排期开发。如果功能上线后,用户的使用反馈不达预期,排除其他因素,是需求的源头出了问题,我们会组织内部讨论,修正更新判断标准。

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

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

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

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

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

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

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

3、系统底层:搭建最小可用的业务闭环

做B端产品,要具备有系统的基础建设意识,包含业务梳理、个性化需求评审、产品架构设计等流程。企业服务类产品,在设计时要考虑能覆盖全场景、完整业务链路的闭环,因为任何一个环节的缺失和不完善,都会导致客户的业务流程无法正常运转。

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

当然,对于SaaS产品来讲,稳定性压倒一切,服务器不能宕机,同时产品风格要保持统一连续性。如果后期,平台想要做功能延伸,在产品架构规划初期就要预留可拓展的空间,始终为用户提供持续稳定的安全感,to C产品可以追求UI的新奇,B端产品仍然以稳定为王。

4、用户体验:感知层保持一致

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

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

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

5、产品克制:抓大场景

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

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

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

企业服务类产品解决客户的需求可以大致分为两类:“开源”或者“节流”。开源表示能够为客户带来新增营收或者提高收益率,节流就是常说的降本增效。对于任何新客户,为开源需求买单的预算远比节流需求更充足,意愿更强烈。

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

考虑到当前国内的用工市场情况,买方和卖方发生了换位变化,我们设计产品结构(骨骼)时,舍弃了乙方和甲方(用工单位)签约的CRM场景,这个场景我自己认为不是主流需求发生地,做这个决策谈不上客观,基于自己对行业的理解与判断。影响产品成功的关键因素,除了创始团队对特定市场的深刻理解与前瞻预见之外,还有团队对资源的掌控调用能力。

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

6、有效流量:用户痛点=需求程度*需求频次

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

痛点=需求程度*需求频次,有效的流量必然是极度需求且高频需求的。如果不是建立在痛点基础上,仅仅是通过一些营销手段获得了流量,这种流量根本没有任何黏性可言,活跃度也会极差。用户的获得感>用户的产品使用能力,流量才不会离开。

虎蛙目前在做推动底层蓝领服务数字化&标准化的事业,要做成它,我们都清楚会是一场马拉松式的长跑。任何行业想去变革都会异常艰难,人只有走上坡路时才感到难,走下坡路是轻松的,相信任何做企业服务产品的 团队都和我们一样,虽难但仍向往之,始于初心、成于坚守、久于做难而正确的事!

业界动态

抖音杀死头条

2021-5-9 9:06:35

业界动态

推荐策略产品经理:构建标签体系的二三事

2021-5-9 9:21:47

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