企业服务类产品,其底层逻辑是什么

24 评论 1.4万 浏览 248 收藏 13 分钟

编辑导语:

# 本文为人人都是产品经理《原创激励计划》出品。

企业服务类产品在国外发展已经成为了主流,但在国内这几年才掀起热潮,大部分还处于起步、探索阶段。习惯了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/界面交互)。

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

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

痛点=需求程度*需求频次,有效的流量必然是极度需求且高频需求的。

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

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

#专栏作家#

大井盖先生,公众号:八点四十,人人都是产品经理专栏作家。前某厂PM总监,现创业公司CEO;关注企业服务和金融赛道,爱好广泛,欢迎一起交流探讨产品或创业相关问题。

本文为人人都是产品经理《原创激励计划》出品,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
6人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 灵活用工产品经理路过,感谢分享

    回复
    1. 哈哈哈,加微信互撩,灵活用工周边赛道产品飘过

      回复
  2. 我公司就是做企业后勤行政管理的B端SAAS产品,也无需求各种来源老板、销售、市场、竞品、客户、系统使用对象(司机、行政
    企业大中小领导、一线员工、宿管大爷、保安等等),因为需求来源太多,多业务模块并行,场景丰满的同时产品越做越臃肿,各方面成本越来越高,在这个野蛮生长的领域我们系统也越卖越高价,人家专注一两个业务模块成本低,在竞标时候人家系统价格比我们系统低了好几倍,就算是人家系统不够好用,企业也会选,因为价格太有优势了。

    回复
    1. B端产品好用并不意味着会被客户采购,影响因素不是唯一的,在业务流程上要选择核心切入点,有自己的生态定位,不然做的太臃肿,客户反而觉得麻烦会离开产品,很多产品是被自己做死的,如果已经上升到PaaS就可以解决一部分个性化延展开发的问题。
      欢迎多多交流,产品嘛,多打磨多思考总是好的

      回复
  3. 产品需求排期是个很难处理的工作。尤其是那种开发资源不足,需求一大堆的情况,每个需求方都认为自己的需求重要。如果产品没有上一级的支持,文中那些排期手段会沦为纸上谈兵

    回复
    1. 能够理解您说的,产品经理都有自己的判断标准,我们始终是追求正确的解决方案,相信也是公司希望的结果

      回复
  4. 写的很好,怎么说呢,这一切的基础是要有大领导站台,其实很多产品都是很无奈的明明知道需求不合理,如果一旦上去会出现能想到的问题,但是最终还是会上,因为你无法说服领导,领导总是觉得自己的需求是对的。我一直是这么认为的,在没有大领导信任的基础上,我们就是个项目经理,仅此而已。

    回复
    1. 感同身受,卑微的产品狗们团结在一起~
      有个建议,咱们还是要不断加深专业能力,可以妥协用最小成本去跑跑测试方案可行性,但是不能无底线的妥协,不能因为惧怕就不提最优方案

      回复
    2. 所以才会有数不清的小公司,中小型公司的通病就是老板自以为是,公司永远做不大。特别是B端产品,甲方乙方两个自以为是的合在一起搭建一个五彩斑斓黑的舞台,产品交互设计们只能在下面鼓掌叫好了

      回复
    3. 是的,B端产品需求 来源更复杂,要让专业的人干专业的事,先实用再考虑美观。

      回复
    4. 你这么说,我目前所在公司的CEO是技术+产品出身,那我还算比较幸运

      回复
    5. 产品出身的CEO+1,哈哈哈

      回复
  5. To C产品讲的是用户体验,To B产品更多讲的是效率。

    回复
    1. 说得在理,B端产品先实用再美观

      回复
  6. 细细品读,受益良多,感谢分享!!!已关注!!

    回复
    1. 谢谢啦,多多交流~

      回复
  7. 接触B端产品半年多,确实对文中这几点都感触很深。B端比C端更考验产品经理对行业对业务的理解深度,更需要挖掘用户反馈表述的背后最根本的需求痛点是什么

    回复
    1. 是的,从业务倒退需求源头,不能单纯看成一个功能点。

      回复
  8. 当用户开始付费之后,用户会天然认为“顾客就是上帝。”在利益收入和产品初心上如何平衡有没有经验(比如用户策略、产品设计等)可以分享。

    回复
    1. 可以啊,很多SaaS做着做着就变成某家客户的定制开发商了,要解决普遍的需求,不能过于单独。

      回复
  9. 写的很不错,当然,其中还有一点我认为也值得拓展的,就是怎样让需求提出人(主要是运营和B端产品的用户)接收「你的需求被拒绝了」。虽然作为PM很明白原因,但如何让个人理解,除了强压或拿职位和负责版块之外,有没有更友好的方式,这点值得探索。

    回复
    1. 是的,感谢你提的建议,需求被拒要能够友好的上传下达

      回复
    2. 是的。我也有被这个困扰。对方是运营的VP。怎么说服她,让她接受“她的的需求不合理”进而让她放弃非常难。

      回复
    3. 看样子大家都有这个困扰,首先可以是请你们产品的负责人与运营VP同级沟通或者用最小可行的demo做一个打样

      回复