企业服务类产品底层逻辑

编辑导语：C端产品是面向终端用户或消费者的产品，往往承担引流和转化的任务，所以C端产品是企业与消费者之间的重要媒介，也是企业重要的获客手段之一；本文作者分享了关于企业服务类产品的底层逻辑，我们一起来了解一下。

一、理性看待：“用户永远没有错”

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协议。