B 端企业内部产品经理赋能业务心得

作为一名产品经理，如何增加工作成就感并提高工作能力呢？本篇文章从业务赋能这一角度出发，帮助大家理解产品经理该如何做好业务赋能，希望本篇文章能对大家有所帮助。

最近常常被问到服务于企业内部的产品经理，常常陷入被动实现业务诉求的死循环，缺少成就感和工作动力。

那么企业内部产品经理该怎么主动去赋能业务，来体现产品价值，摆脱产品经理成为业务与技术之间传话筒的尴尬定位？

本人结合多年大厂、中厂、创业公司等企业内部产品从业经验，分享一下 B 端企业内部产品经理赋能业务的心得体会。

1. 企业内部的产品经理是一群什么样的人
2. 赋能业务，究竟拿什么去赋能——从产品经理的资源和能力展开
3. 如何去赋能业务——具体实操经验（赶时间直接看这里）

一、Who 企业内部产品经理是一群什么样的人

说事之前先谈人，企业内部的产品经理是群什么样的人，有什么特点？

下面从所处环境、业务的关系、与 Saas 产品经理区别三个方面浅谈企业内部产品经理人群画像。

1. 所处环境

• 角色与部门：企业内部产品经理往往属于技术序列，隶属于像传统企业的IT支持部门，或互联网公司的xx技术部，组织架构上离研发近，离业务远。
• 主要工作目标：根据公司业务阶段和形态不同，产品经理主要工作目标从保质保量完成项目上线，到直接负责相关业务指标达成，都可能涵盖。
• 日常工作：企业内部产品经理的工作日常，会议（围绕需求与业务、产品、研发、设计、测试、运营等各工种的需求沟通会）、产品设计、调研、运营、数据分析等，产品经理作为需求或项目的信息中枢，时间和精力会被拉扯的四分五裂，整体上会呈现繁忙杂乱的状态。

2. 业务的关系

服务于企业内部的产品经理，从入职第一天就面临着与业务的关系问题：是产品主导业务，还是业务主导产品？

产品与业务关系的上下限，一个是“业务方是老大，因为业务指标达不成业务背锅，所以业务说怎么干就怎么干”，另一个是“业务方不给力老挖坑，听产品的，产品说怎么干就怎么干”。这两种都是服务或主导思维。

对于企业来说，整体上需要的是合作思维。虽然说业务同事是公司业务好坏的直接利害关系人，但也不存在产品经理单向服务于业务经理的说法，而是产品经理与业务同事共同服务于公司的业务目标。

具体上需要根据谁是责任人来判定谁是主导的一方，是产品发起的项目还是业务发起的项目，都需要对方尽可能的配合。

角色定位并非固定而是多变的。

3. 与 Saas 产品经理的区别

同为 B 端产品经理，企业内部的产品经理和 Saas 产品经理的核心区别是什么呢？

企业内部产品一般情况不需要考虑产品怎么盈利，而是以产品为载体，在降本、提效、保质、数字化改革等方向降低公司业务运转的边际成本。

二、What 拿什么去赋能业务，产品经理有什么

提到赋能，无非从资源和技能两个角度去谈：

• 资源：产品经理核心可调用的资源主要有产品和研发资源，可以决定在不同业务上的资源投入，是角色附带的资源属性，这里不过多讨论。
• 技能：产品经理有什么特有的技能可以赋能到业务？

1. 基础技能

1. 产品能力

• 产品掌握程度：包括熟悉产品用户及定位，使用者有哪些，他们的日常工作是什么（判断业务需求是否属于该产品范畴）、历史产品功能及系统逻辑（是否可复用）、熟悉产品规划（判断业务需求是否在产品迭代主方向上，合理设置优先级）等。
• 产品设计能力：包括原型、流程图、状态机、底层信息结构等。

2. 业务能力

• 了解业务目标，总目标和子方向或阶段性目标（合理分配资源投入）。
• 了解业务流程及规则（与业务同频沟通，方案还原度更高）。

3. 项目能力

• 资源争取、协调沟通能力、项目风险控制等。

2. 高阶技能

1. 数据赋能

• 掌握业务数字化解决方案路径，提高管理效率，以及依托大数据算法的策略模型训练与应用等。

2. 低成本方案

• 企业内部产品经理常遇到的，由于公司业务发展较快，需要系统快速响应支持，系统先上线再说。面对这类时间优先的需求，需要产品经理提供快速的非完美解决方案，帮助业务快速试错或快速抢占市场先机，所以企业内部产品经理需要具备低成本快速解决业务问题的能力。

3. 对业务走势的判断

• 正如一位知名冰球运动员所说：“好的冰球选手会竭尽全力追赶冰球，但是伟大的冰球选手则会寻找冰球的下一个位置，然后等在那里给以致命一击。” 企业内部产品经理需要对业务走势有判断力，主动做规划，而不是被动疲于应付需求。

三、How 如何赋能业务，具体实操经验

基础技能1：如何提高产品能力，让自己更加专业？

拥有产品的专业力，是赋能业务的基础。

1. 如何做到对产品了如指掌

如果是长期供职的公司及产品，产品经理自然对自己的产品了如指掌。这里主要讨论下新人如何快速提升产品熟悉程度。

大部分公司都不会给新人足够长的时间充分了解产品后再投入实际产品工作中。

所以对新人而言，往往需要一边了解产品现有功能一边处理新需求。

对产品的不了解，让产品经理面对业务时无法提供专业建议，只能业务说啥是啥，那么新人产品如何快速熟悉产品和系统呢？

• 请教产品的资深参与者，如产品经理、研发骨干等。企业内部系统，尤其是系统逻辑相关的问题，请教资深的研发往往比请教资深产品效果更佳，因为存在需求文档未及时更新或临时口头需求等情况，需求文档不一定能准确反应出系统逻辑，而线上代码是现在系统逻辑的最直观表达。所以，作为企业内部产品经理，与研发同事的关系应该更加紧密，工作开展会更加顺利。
• 阅读相关产品文档，如交接文档、产品历史需求文档、调研报告、数据分析报告等。问人是第二优先级，第一优先级是自查。问人是把困难留给他人，把方便留给自己；自查是把困难留给自己，把方便留给他人。那么如何快速找到关键信息呢？每家公司的公司语言及文档形态都不尽相同，需要具体情况具体分析，大体的思路上可以遵循由大到小、由总到分的顺序去查阅。如熟悉一款新产品，先去了解产品定位、服务人群、主要解决的问题，再逐模块拆分去了解，最后才是具体功能的逻辑，这样有助于理解整体的产品结构，为后续在产品上添砖加瓦提供准绳。
• 除以上常规方法之外，还有一种快速熟悉产品逻辑的方法。产品经理主动加入线上运营反馈群，以类客服的身份上手处理用户反馈的问题。企业内部产品的用户，往往是自己领域的产品使用专家，跟进解决他们提出的问题，可以倒逼产品经理快速了解用户痛点和产品功能。

2. 提高产品设计能力

包括设计流程图、状态机、原型、底层信息结构等。产品经理的基本功，多学多练即可提高。

新人可学习身边优秀同事的产品文档，或者底下回复微信，之前在某大厂的项目文档可以分享。

基础技能2：如何提高业务能力，让自己能和业务同频对话？

不清楚业务问题，或无法准确理解业务现状，何谈赋能业务。

1. 了解业务目标，总目标和子方向或阶段性目标（合理分配资源投入）

赋能业务，需要了解当前业务痛点或目标，才能有的放矢。

• 如今年公司销售部门的目标是增加收入，质控部门的目标是减少异常损失，那么围绕业务目标业务部门就会有一些业务动作，比如增加收入的话，可以通过开拓新客户、提高老客户续签率、提高客单价等等手段来实现。
• 再举一个我个人的例子，之前在某厂工作时，由于公司运营资产较重且丢损严重，如快递车辆损坏无法定责、循环包装袋（箱）容易丢失等，每年大概有几百万的成本损失，业务部门系统做精细化管控来减少这部分损失，那么这是业务目标，产品部门围绕这个目标，做了针对快递车辆、流转物资等公司资产的线上化管控平台，来减少异常丢损等情况，实现产品赋能业务减少损失。

2. 了解业务流程及规则（与业务同频沟通，方案还原度更高）

• 清楚业务目标之后，还需要更具体的了解公司业务是怎么运转起来的。如公司主营业务流程是什么样的，流程中都有哪些节点，需要哪些角色参与什么动作，还包括逆向流程和异常分支流程等等。
• 业务知识的获取可以分为理论和实践两部分：理论层面的信息可以通过日常与业务的各种信息渠道来接收（如会议、聊天群、周报邮件、文档等）；实践层面可以通过实地调研、访谈、轮岗等方式了解不同业务场景下的业务流程。目的是通过理论和实践相结合的方式，从而对业务有全方位的理解。

基础技能3：如何提高项目能力，把事做漂亮？

了解产品和业务之后，需要强执行力将方案落地。执行力的强弱往往通过会通过具体项目来表达，这就需要产品经理有较强的项目能力，尤其是企业内部产品经理。

怎样在资源和话语权都不足的情况下将项目完美落地，需要以下几点能力：

1. 项目资源争取

这里的资源指人力、物力和一些特殊许可等与项目成败相关的因素。

资源获取往往需要产品经理向直接上级或者更高级别的老板来申请。

那么如何才能成功争取到项目需要的资源，立项成功与否的关键因素，总结有两点：可观的项目收益和有逻辑的收益预测方法。

1. 可观的项目收益是指这个项目做完，刨去成本能给公司带来的实际收益能有多少。一些简单易算的直观收益如带来营收增加多少，减少多少人力成本支出（人员工资）等，和一些不易被清晰定义的收益。如借用自动化设备缩短快递履约时效的项目，那么需要借鉴历史数据中超时投诉影响复购的概率，或参考同行竞品的一些数据做收益预估。项目收益与项目成本（人力、物力、一些特殊的许可等）的ROI越高，获取到资源支持的概率越高。
2. 仅有项目收益还不行，需要让拍板人认可这个收益，那么就需要有逻辑的收益预测方法。内部产品经理经常会做业务流程的优化，对于业务流程优化项目，一个简单的计算公式：

项目收益=单次理论收益*影响范围*发生概率

单次理论收益：单次理论收益指的是流程发生一次产生的收益，如效率提升（人员工时支出成本减少）、质量提高（减少投诉损失）等方面去考虑收益计算逻辑。

影响范围：产品经理往往会针对某一特定业务场景进行优化，那么就会有一个影响范围，比如影响的人次、件数、店数等等计量单位，考虑影响范围才会让项目收益更加可信。

发生概率：如果系统存在相似场景的数据，那么可以直接套用，如果不存在，那么需要产品经理具备和拍板人同频的业务sense拍一个靠谱的概率，这下前面积累的业务知识就派上用场了。

顺利争取到项目资源，考验的是产品经理站在公司角度对商业逻辑的思考，也是从执行者向管理者迈进的重要一步。

2. 协调沟通能力

项目的落地，需要多人多角色共同完成。产品经理需要在其中穿针引线，保持项目组信息一致，推进节奏一致。

如果是跨部门合作的项目，也可能会遇到资源冲突的情况。比如对方部门的排期不满足或项目成员被上个项目拖住迟迟开不了工等，需要产品经理去协调沟通，对当事人沟通，对当事人的上级或上上级沟通等。

沟通风格因人而异，但切记太硬或太软。太硬长期关系难以维系，太软自身利益得不到保障，产品经理需要与合作方培养长期良好的合作关系，有时需要做一些适当让步。

3. 项目风险控制

对风险的控制，就是对交付质量的保障。既是时间的保障又是质量的保障，常常遇到项目临期但功能还未开发完，就会生产出阉割版先用着的情况。

后续再优化，但一般就没有后续了，最后落地个 70 分的项目。这其实就是对整个项目功能包开发量预估的不准确，或对于工期的评估过于乐观，未考虑到其中风险点。如轻视了功能或流程的复杂度，或忽视了人员熟练度不足的影响等等。

一名合格的产品经理，需要与技术同事一起在事前事中事后三个环节做风险控制：

1. 事前做风险预估：在项目启动会、在需求评审会上，邀请研发同事一起对产品方案做实现风险评估。诸如一些并发问题、渲染效率问题等需要专业技术人员给出方案建议，进而修改方案或准备 plan B ，尽量在开发前将方案风险控制在最小。
2. 事中做风险跟进：一些问题和风险往往会在开发过程中暴露出来，需要产品经理及时响应，短时间内给出风险处理方式，调整方案或适当调整工期。如果一个人无法决策，那么需要拉更高级别的人参与进来决策。可以将问题及处理方式抛出，得到决策人认同或新建议后再继续进行。
3. 事后做风险分析：一般经验来讲，系统上线之后，回过头分析这个事可能会被其他高优先级的事情挤兑而忽略执行。这里强调一下事后复盘非常重要：眼光放长远，不要怕浪费时间和浪费精力准备材料和会议。如果马上埋头进入到下一次项目循环，该出的问题还是会出，整个项目组的能力还是没有提升，工欲善其事必先利其器。

高阶技能1——如何利用数据赋能业务，助力企业数字化改革

管理学大师彼得·德鲁克曾说过：If you can’t measure it , you can’t improve it 。

数据赋能，用数据去体现业务情况，以及提供数据依据去影响业务发展方向。

产品经理链接业务与技术，可以结合业务场景和数据口径进行数据整理和分析，是数据赋能业务的最佳人选。那么产品经理该怎么用数据赋能业务呢，可以按照系统开发的前中后三个阶段分别来看。

1. 开发前

产品经理在前期与业务沟通需求时，协助业务捋清业务目标和收益，并将需求目标指标化公式化。比如便利店员工经常将商品上错架或忘上架，业务希望让员工将商品上架到正确位置，那么业务指标是商品上架合格率，计算口径是上架正确的商品数/总商品数。

将需求目标指标化，对于后续上线后的效果监测和产品迭代，会提供清晰的数据依据。产品经理需要做的是协助业务将目标指标化，并且能够洞察指标背后的业务含义（业务流程及动作），以设计对应的产品功能。

有时需求收益不容易被计算或是短期亏损但长期应该投入的方向，往往是基础建设类的需求。这类需求需要自上而下去推动，需要公司有相关基因或战略规划，比如传统企业的数字化改革等。

2. 开发中

产品设计时，除功能需求外，应增加数据部分需求——即将业务指标转化为可开发的数据库表设计和看板设计。

将业务指标梳理拆解，可根据不同业务场景横向拆解，或按流程节点纵向拆解，以便于具体分析问题所在，并与技术同事达成一致留好底数。包括结果数据和过程数据，为后续报表看板提供便捷易得的数据源。

3. 开发后

将业务指标可视化为可以满足业务管理诉求的看板，看板提供底数和便于直观分析的趋势图、分布图等。那么有了数据看板之后怎么应用数据去解决业务问题呢？

Q：怎么看数据？

A：可视化数据呈现出来后，怎么去看数，便于我们快速识别风险点和机会点。

可从量级、趋势、异常、结构、细分五个维度去观察分析：

1. 量级，即数据的多寡；
2. 趋势，即通过数据的升降，判断企业业务健康度走向，或判断产品功能上线后对业务走势的影响；
3. 异常，即看数据骤然的升降，定位机会点或问题点；
4. 结构，即了解数据的组成、组成占比、优先级等；
5. 细分，即通过细分维度的数据，结合不同业务模式，在细分业务模型下的数据表现。

Q：怎么分析数据？

A：

• 有头绪——验证式：有头绪的数据分析，一般可根据过往经验或历史数据，得出一些可能解，再结合具体场景，逐一验证解决方案的匹配，可快速缩小问题范围，效率较高。
• 没头绪——探索式：没头绪的数据分析，需做可能解穷举，再放到可能得到答案的环境去定位问题，像 debug 一样逐一排查。
• 一些精益管理的数据分析工具：帕累托图（ pareto )、因果图（ cause-and-effect diagrams )、直方图（ histograms )、控制图（ control charts )、散点图（ scatter diagrams )等。

4. 更进一步的，通过前端系统、传感器等端口将现实世界的信息元素收录于系统中。

在数字世界中通过海量数据训练算法模型，发现数据与数据之间的相关性，建立最优的业务策略模型，并与现实业务有机结合，实现真正的数据反哺业务。

无论是业务数据可视化，还是真正的数字化赋能，都是高阶产品需要具备的数字思维，具备数字思维的产品经理，可以更加精细缜密的赋能业务。

高阶技能2——如何通过低成本产品方案，让产品设计更加务实

公司业务发展较快，需要系统快速响应支持。面对这类时间优先的需求，需要产品经理提供快速的非完美解决方案，帮助业务快速试错或快速抢占市场先机。

这也是企业内部产品经理与 Saas 产品经理的区别之一。

企业内部产品经理往往输出的是性价比最高的方案，而非最完美的方案。尤其在一些短期实验性的业务方向上，业务规则可能随时被废弃或变更，系统变更开发的成本是巨大的，产品经理需要提供短平快的系统方案快速响应业务变化。当然在一些公司级或者年度战略项目上，产品经理还是需要考虑系统健壮性和扩展性的。

更加具体的，低成本方案包括在用户体验方面做一些牺牲，增加一些人力成本串联流程，以及在一些潜在的业务变更项上预留配置或开关。

经验告诉我，包含关键功能的 MVP 版本上线后，就已经能够解决业务的大部分问题，就已经可以帮助业务在时间上占据先发优势。这点在残酷的商业环境下往往比多一两项功能重要的多，产品经理后续可以在系统准确度、流程自动化、系统包容性等方面逐步将产品完善。

不必做最好的产品，而是做最适合的产品。

高阶技能3——关注业务走势，提前做产品规划

关注业务发展动向，有助于决策产研资源投入及判断需求相关性。

1. 业务知识

缺乏业务知识的产品建设，如空中楼阁，无法解决实际问题。

• 了解公司业务：可以通过旁听业务会议、阅读业务同事周报等方法，了解业务最新近况，寻找现阶段业务问题以及未来业务发力点。产品经理主动去了解业务，信息同频，与业务配合起来才会事半功倍。
• 关注行业信息：了解行业最佳实践，学习同赛道下的其他公司的业务是如何运转的。以及公司在哪些领域是领先的，哪些领域是落后的，落后的部分可能存在着可提升的空间。

2. 产品技巧

产品层面，考虑到业务未来的发展趋势，业务或稳定或易变，产品设计上会有不同。

• 模块化设计：将技术开发的解耦思维运用在产品设计上，如前端可复用的交互组件，后端抽象出的通用系统逻辑。为的是业务需求变更后尽可能少的代码开发量，以及更快的响应业务变化。模块化设计往往应用于确定性较高的业务方向上，产品在前期基础能力建设上多下功夫，后期业务快速成长也能从容应对。
• 开关与配置：埋下系统开关或系统配置，通过热更新的方式快速满足业务在不确定场景下实验诉求。适当的灵活配置，也可以解放研发资源，不必再被动处理业务的临时需求变更。开关与配置灵活化设计往往应用于不确定性较高的业务场景下，产品经理需要结合业务情况和研发成本，设计恰到好处的灵活配置程度，过分灵活和全部程序写死都是不可取的。

具备深厚的业务知识和丰富的产品研发经验，才能够设计出“恰到好处”的产品，这样的产品经理会成为业务同事靠谱的合作伙伴。

四、写在最后

企业内部产品经理，不应为自己设限，躬身理解业务，并从产品、数据与技术等专业领域给与业务同事输入。

都说公司真正性感的是业务而不是产品，那产品经理就为性感业务上增加一些理性的智慧。

​Read More