大厂To B产品经理经验：如何讲好业务价值？

为了不被领导diss看不见方案的业务价值，产品经理需要掌握一定的技能和技巧，来帮助自己做好业务方案汇报，讲好业务价值。这篇文章里，作者就做了介绍和梳理，一起来看看吧。

刚刚入职大厂的时候，基本上每天都会被产品总监argue：

• “你的产品价值在哪里？”
• “你的方案业务价值在哪里？”
• “你的方案很难落地”

这三句话轮番上阵，活一点也没少干，被怼的也是真不少，我也差点因为这些批评抑郁。多亏了有一天一位人很好的同事姐帮我理了一下ppt的思路，我这才幡然醒悟。哦！原来，领导们要听的是这个。

一、为什么需要汇报业务方案

1. 常见场景：业务方案评审会

现在市场上常常要求产品经理要有“从0到1”的产品经验，但是在软件行业发展至今的行业大背景下，“从0到1”是可遇不可求的，但是改善某一业务场景却是非常常见的。

典型的包括：过程质量改善、新增运营计划等等。

2. 典型的错误案例

说到“失败”的汇报经验，我真的是集大成者。一方面，遇到了老阴阳人的领导，另一方面也真的是不会汇报。

典型的错误的汇报方式：

• 盲目列要改进的功能点
• 大量列举改进的原型图、交互
• 回避关键流程、不提及关键业务方
• 直接用其他同事的ppt，只改字和标题，大量复用别人的图表

刚开始工作的时候，很多东西都不熟，我也会觉得要不不熟的东西就不讲吧，或者看到被人好的内容就直接拿过来。这样是非常容易踩雷的，一定要回避。就算相同的内容，最好自己画一遍，改改颜色也是好的。

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

我们要理解的事情是，领导在他们的领导面前和我们是一样的，没什么本质区别。我们每天都在认真工作，钻研在某些个具体的事务中，我们欠缺的是把事情组织起来的能力，但是领导们每天并没有那么多具体的素材，他们的工作是“指导“我们做有意义、有价值的工作。他们的素材就来自于我们的每一次汇报。这就是正确的“解题思路”。

二、该怎么讲好“业务价值”？

现在，人们交朋友最看中“情绪价值”，同样地，产品最重要的就是提供“业务价值”。怎样讲好“业务价值”，是产品经理的既“虚无”又“实用”的基本功。“实用”在于这种“标准化”的介绍方式，最能帮助听众最快的掌握你的需求，例如向公司寻求某类支持、投入；“虚无”在于，所谓的“业务价值”是否真的有价值，会带来什么样的改善，并不一定会完全如愿。

但是，学会讲“业务价值”，至少可以让自己完成低阶产品经理的进阶之路。废话不多说，直接上干货。

1. 介绍业务背景

介绍业务背景一共包括三个大方向的内容：介绍整体背景、介绍阶段背景、介绍本次方案的核心内容。

整体背景通常包括，行业背景、产品线背景，可以参考行业发展或者产品路标等等，重点在于对听众进行背景宣贯，拉齐听众对整个产品的定位的认知。

阶段背景则对标到现阶段的目标，可以参考年度计划等等，明确当前阶段的目标和现存的问题，梳理典型用户画像。可以理解为本次演出的演员就位。

概述本次方案的重点，针对现阶段存在的哪些问题进行改善，对应受到影响的用户是谁，各类用户的痛点和解决方案是什么。

2. 介绍业务流程

介绍现有的业务流程是什么，梳理出当前问题中最急需改进的点。

例如，某个采购流程较长，导致研发过程的延期，梳理后发现最关键的问题是某个审批节点的审批人员常年在外出差，PC端审批内容尝尝错漏。为解决这一问题，提供移动端进行审批，方便审批人员快速便捷完成工作。

进行方案对比，对比改进方案前后会有哪些变化。可以从两个方向进行介绍

• 对于产品的改进点，如：产品更好卖、更专业、更好用、成本更低
• 从对各方影响的角度介绍，对用户有哪些好处、对客户有哪些好处、对公司有哪些好处。

3. 改进方案的详细介绍

详细方案介绍包括，概述对各个相关系统的影响、各相关方的工作计划和安排以及详细的改进方案介绍

我们要时刻记住这是业务方案不是具体的需求评审。只是在讲一个改进的方案并且寻求支持，而不是做具体的介绍。很多团队会要求在一时间段出高保真之类的设计，个人觉得非常不合理。“高保真”属于详细设计阶段，而方案汇报则是在需求确认阶段进行的。此刻，原型是否完成并不是关键，重要的是业务流程的改进对各方的影响是否合理且正向。

4. 详细计划

详细计划一般重点介绍详细的排期，事先可以与开发团队沟通可用的技术资源。先给出按大功能模块排期的工作计划，预估出上线时间点和培训计划。汇报的重点也包括，当前上线计划是否符合业务目标、是否有足够技术资源支持当前目标。可以在会议上对这部分内容进行确认并通过会议纪要的方式存档。

第二个要关注的重点内容是验证指标。通常我们认为一些易用性的提升是比较好验证的，比如增加批量处理功能这类较小的功能点，这类无需重点强调。比如，访问量、目标用户转化率等等指标则需考虑是否需要埋点等等。

三、讲好“业务价值”，只是开始

讲好“业务价值”，只是开始。业务方案评审会结束后，需根据会议上的内容进行详细设计、组织需求评审会、需求研发等等。

下图为IPD产品研发中需求管理的标准化模型。业务方案评审可以理解为需求分析和需求分发阶段的过程产物。

四、验证愿景

验证愿景，是指阶段性基于在详细计划中设计的验证指标进行回顾。比如，预计平均缩短采购流程1天，这是完全可以通过数据库拉取数据验证的。同时，应更新需求状态，对需求管理进行复盘，对比部门的年度计划验证整体计划的执行情况。

以下为需求管理示例图。