在职场工作中，数据思维是必不可少的，那么产品经理要如何学会用数据给自身赋能、提升数据与业务的映射能力呢？本篇文章里，作者就对产品经理如何用好数据、提升职场竞争力这件事儿进行了总结，一起来看看吧。

在产品经理的日常工作中，无论是需求沟通、case处理、还是述职汇报，你是否见过那些可以用数据描述问题，可以用数据解释现象的同事，是不是会下意识的给TA贴上“靠谱”的标签？这类人往往具备出色的数据采集分析能力，和数据与业务的映射能力，有理有据且逻辑自洽。那么作为产品经理，如何用数据给自身赋能，提升职场竞争力呢？

对于一名优秀的B端产品经理来说，理解业务、会用数据和了解技术这三项能力缺一不可。

理解业务可以对问题做清晰定义，方向不跑偏；会用数据可以客观测量问题严重度以及量化改善效果；了解技术可以保障方案落地的顺畅和准确。

B端产品经理的核心能力在于用技术手段来解决企业业务问题，并通过数据保障解决目标和解决路径的科学合理。

其中，会用数据，用好数据，会给产品经理带来诸多职场优势。

一、数据理解

对数据的理解，在B端产品范畴内，数据≈数值+语义环境。数值是一系列或业务或系统或人为的行为记录，语义环境则是具体的业务场景。对数据的理解，应依托于对业务的理解，在具体的业务场景下描述数据的特征，如最大值、最小值、平均值、中位数、众数、方差和标准差等。

中位数：通常用于描述数据的集中趋势，可以排除极端值的干扰，结合平均值对一般化水平进行分析，如中位数和平均值差异很大，可以做异常值定位分析，看数据是否合理是否需要剔除等。

方差和标准差：方差和标准差都是用于描述数据的离散程度，通常用于衡量数据的波动程度和稳定性，方差/标准差越大，数据组波动大越不稳定，需要寻找不稳定的原因进行分析，发掘一些机会点。

二、识别缺陷

B端产品的需求来源主要有二，来自业务侧或产研内部发起，业务侧需求通常以解决业务问题实现业务指标为目的，通过产品形式来进行方案落地；产研内部需求通常由产研自身发起，或是解决业务问题、或是偿还历史债进行功能/流程重构。那么如何科学的识别问题，还是需要通过数据表征，通过数据异常或数据的变化趋势，识别问题或预防风险。

如在618期间通过取消单数据，发现某些品类的商品，用户下单后较容易反悔撤单，但是订单信息已经传送至物流开始履约，甚至已经开始采购或者拣货出库了，这时候撤单对整个物流履约的撤销成本较大，所以针对部分容易撤单的商品，增加特定的冷静期设计，在用户下单过了冷静期后再开始物流履约，可以大幅减少已经开始履约订单的撤销成本。

业务数据是业务行为的一维表现，其背后是业务行为的累加结果。数据有波动，一定是某些节点不同于往常，需要重点关注。

比如：

• 某个业务动作的执行时长边长，是工作量变大应付不过来还是人手不够？
• 客户的投诉变多，是门店人员的服务意识不够还是门店卫生太差？
• 员工出现违规操作的次数变多，是态度问题还是能力不行？

数据波动的点，就是问题点，敏锐的产品经理应快速捕获缺陷，作为下阶段工作重点。

三、合理规划目标

麦肯锡把问题分为三种类型：恢复原状型，追求理想型，防范潜在型，而产品需求本质就是在解决问题，所以产品需求也可以归为以上三类。

1. 恢复原状型问题是指企业或组织在运营过程中遇到的问题，需要采取措施恢复正常运营。例如，生产线出现故障需要修理、员工离职需要招聘新人等。
2. 追求理想型问题是指企业或组织希望达到更好的运营状态，需要采取措施实现目标。例如，提高产品质量、扩大市场份额等。
3. 防范潜在型问题是指企业或组织预防潜在的风险和问题，需要采取措施防范未来可能出现的问题。例如，制定应急预案、加强信息安全等。

通过数据分析，可以准确识别问题和合理设置目标，其中每一类型的问题都对应不同的北极星指标。

如在仓储拣货场景下，因引入自动化拣货设备，在早期存在人机配合流程不合理或不熟练等问题，导致单位时间人均处理包裹量下降。那么，从商品上架、商品动线、格口分配等各拣货环节进行分析，将上架准确率、商品规划路径及移动时长、平均拣货入筐耗时等关键指标进行抽离，通过完善产品功能和优化SOP等方式，将各项指标数据恢复到历史同期最佳水平，作为需求目标。

功能上线后，对指标及时跟进，分析指标实际值、原值和目标值情况，对情况比较有以下几种情况：

• 实际值<原值：负面效果，数据向坏发展，该回滚回滚该下线下线，然后排查原因是什么？二次上线需制定备用方案。
• 原值=<实际值<目标值：说明没有让该方案变得相比原来更差，但实际值为何低于目标值？低多少？是否有提升空间？分析清楚后再评估是继续改进还是放弃。
• 实际值>=目标值：说明达到目标，甚至超过预期，分析为什么会超过预期，是否有虚假繁荣的情况，如果数据真实可靠，应尽快大范围推广该功能，或举一反三，用类似思路去改造其他功能。

四、有力说服：数据也是论据

场景一：需求评审

你是否有过或见过因为需求不合理或需求价值不清而被打回的情况？需求评审是由产品发起向研发侧传递问题背景及解决方案的信息渠道，也是产品经理日常最重要的工作之一。一次合格的需求评审，至少需要讲清楚四个问题：需求背景是什么？该背景下发生了什么问题？目标又是什么？以及具体的改善措施？

案例：

• 背景：在快递配送场景下，一些大客户要求货物在送到后，需要由收货人签写回单，并由快递小哥将回单邮寄回客户处，作为已收货凭证。
• 问题：一些回单格式不正确或签名字迹模糊等问题，致使回单不符合要求导致客户无法入账，对公司造成客户投诉罚款的风险。
• 目标：提升回单质量，降低客户投诉罚款。
• 方案：在货物妥投前，增加回单上传及图像识别，回单样式正确才能成功妥投。

经过我的描述，也许你已经清楚了确实发生了问题，但是问题的严重程度不得而知，无法判断严重程度也就无法合理规划优先级及资源投入。所以，还需要我们在此基础上增加一些数据描述，看看效果怎么样。

• 背景：在快递配送场景下，有32%的大客户要求货物在送到后，需要由收货人签写回单，并由快递小哥将回单邮寄回客户处，作为已收货凭证。这类运单约5万单/天，约占运单总量的10%。
• 问题：其中有15%的回单存在格式不正确或签名字迹模糊等问题，致使回单不符合要求导致客户无法入账，对公司造成客户投诉罚款的风险，去年共造成投诉1500次，罚款300余万元。
• 目标：将不符合要求回单比例控制在1%以下，预计挽回罚款成本300万元/年。
• 方案：在货物妥投前，增加回单上传及图像识别，回单样式正确才能成功妥投。

在描述问题的同时，通过数据的加入，将需求价值和收益进行量化表达，增加数据依据以判断问题的严重程度。优秀的产品经理，应该善于使用数据去描述需求、表达观点，使对方易于理解和准确执行。

场景二：向上汇报/述职答辩/资源申请

如果说需求评审是面向平级同事的，那么与上级的汇报述职等，更应该通过数据来佐证你的观点或工作价值。一般老板们对事情的了解不会特别细致，那么就需要你通过数据进行概括，提炼核心观点，用最简短的话语将事情讲清楚。

以我个人为例，之前在某零售公司，经常会直接向ceo进行述职汇报，这家公司述职有个特点，ceo会直接review公司重点项目的进展，ceo时间比较紧张，所以一般会在1个小时内过10个以上项目，一个项目的汇报时间需控制在5分钟之内，这就需要项目owner能用极简的方式进行汇报，这也迫使我加强练习了用数据说话的能力，因为数值才是最没有歧义和理解成本的信息。

我的汇报结构一般是：

1. 现状/背景：发生了什么问题。
2. 目标：预期效果及收益，恢复原状（不继续变差）？追求理想（变的更好）？
3. 做了什么/进度：成果展示（数据）。
4. 后续计划/milestone：产品规划，会在什么时间点达成目标。

填充数据之后的汇报案例：

1. 现状/背景：由于员工将商品上错架而导致的供应商投诉，约5%的SKU会发生此类问题，出现问题的原因有几种：分别是1、2、3。
2. 目标：通过事前培训、事中监督、事后检查的方式，将错误SKU比例控制在0.1%以内，数量控制在100个/周以内。
3. 做了什么/进度：已有50%的错误SKU已通过方法A、B、C得以改善…
4. 后续计划/milestone：剩余问题中，其中10%由团队a解决，预计xx时间可以生效；20%由团队b解决，当前正在开发中，预计xx时间可以生效…

数据的融入，使汇报内容更具象，有分析有方法有规划，给对方十足的确定性，确定性也正是老板最最最需要的，毕竟老板花的钱（你的工资）能够有预见性的带来回报。

所以，向上汇报时，数据的使用会更加重要，老板可能对项目细节感知性不强，但老板一定对数据敏感，会用数据讲话的职场人，也一定会给老板留个好印象。

场景三：求职

在求职简历和面试中，融入数据表述项目背景、执行动作和效果收益，可以使面试官直观get到你的价值也更容易相信你所说的。

• 背景：什么场景下发生了什么事情，事情的大小、发生次数、发生频率等。
• 问题：问题的定义，影响的范围，问题发生的概率等。
• 动作：围绕问题做了哪几个关键动作，动作的具体内容，如实地调研x家门店，输出y份调研报告，拆解xx项产品功能等。
• 效果及收益：系统上线后服务了多少家客户，优化了哪些流程；提高了多少收入，降低了多少损失，提高了多少人效，减少了多少投诉等。

通过数据来阐述你的项目内容，以定量的形式进行分析总结归纳，至少在数据思维和项目表达上，是能够让面试官打勾的，也就更容易拿到下一轮的门票。

写在最后

所谓数据，并不是那些躺在数据库或数仓里孤独的数字，而是需要一位懂它的人，听听它在表达什么，以及描述着怎样一幅画面，也许这就是数据之美。