企业服务类产品，都有边啲底层逻辑？

转载：本文来自微信公众号“人人都系产品经理”（ID:woshipm），作者：大井盖先生，转载经授权发布。

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