为了不被领导diss看不见方案的业务价值，产品经理需要掌握一定的技能和技巧，来帮助自己做好业务方案汇报，讲好业务价值。这篇文章里，作者就做了介绍和梳理，一起来看看吧。
刚刚入职大厂的时候，基本上每天都会被产品总监argue：
这三句话轮番上阵，活一点也没少干，被怼的也是真不少，我也差点因为这些批评抑郁。多亏了有一天一位人很好的同事姐帮我理了一下ppt的思路，我这才幡然醒悟。哦！原来，领导们要听的是这个。
现在市场上常常要求产品经理要有“从0到1”的产品经验，但是在软件行业发展至今的行业大背景下，“从0到1”是可遇不可求的，但是改善某一业务场景却是非常常见的。
典型的包括：过程质量改善、新增运营计划等等。
说到“失败”的汇报经验，我真的是集大成者。一方面，遇到了老阴阳人的领导，另一方面也真的是不会汇报。
典型的错误的汇报方式：
刚开始工作的时候，很多东西都不熟，我也会觉得要不不熟的东西就不讲吧，或者看到被人好的内容就直接拿过来。这样是非常容易踩雷的，一定要回避。就算相同的内容，最好自己画一遍，改改颜色也是好的。
我们要理解的事情是，领导在他们的领导面前和我们是一样的，没什么本质区别。我们每天都在认真工作，钻研在某些个具体的事务中，我们欠缺的是把事情组织起来的能力，但是领导们每天并没有那么多具体的素材，他们的工作是“指导“我们做有意义、有价值的工作。他们的素材就来自于我们的每一次汇报。这就是正确的“解题思路”。
现在，人们交朋友最看中“情绪价值”，同样地，产品最重要的就是提供“业务价值”。怎样讲好“业务价值”，是产品经理的既“虚无”又“实用”的基本功。“实用”在于这种“标准化”的介绍方式，最能帮助听众最快的掌握你的需求，例如向公司寻求某类支持、投入；“虚无”在于，所谓的“业务价值”是否真的有价值，会带来什么样的改善，并不一定会完全如愿。
但是，学会讲“业务价值”，至少可以让自己完成低阶产品经理的进阶之路。废话不多说，直接上干货。
介绍业务背景一共包括三个大方向的内容：介绍整体背景、介绍阶段背景、介绍本次方案的核心内容。
整体背景通常包括，行业背景、产品线背景，可以参考行业发展或者产品路标等等，重点在于对听众进行背景宣贯，拉齐听众对整个产品的定位的认知。
阶段背景则对标到现阶段的目标，可以参考年度计划等等，明确当前阶段的目标和现存的问题，梳理典型用户画像。可以理解为本次演出的演员就位。
概述本次方案的重点，针对现阶段存在的哪些问题进行改善，对应受到影响的用户是谁，各类用户的痛点和解决方案是什么。
介绍现有的业务流程是什么，梳理出当前问题中最急需改进的点。
例如，某个采购流程较长，导致研发过程的延期，梳理后发现最关键的问题是某个审批节点的审批人员常年在外出差，PC端审批内容尝尝错漏。为解决这一问题，提供移动端进行审批，方便审批人员快速便捷完成工作。
进行方案对比，对比改进方案前后会有哪些变化。可以从两个方向进行介绍
详细方案介绍包括，概述对各个相关系统的影响、各相关方的工作计划和安排以及详细的改进方案介绍
我们要时刻记住这是业务方案不是具体的需求评审。只是在讲一个改进的方案并且寻求支持，而不是做具体的介绍。很多团队会要求在一时间段出高保真之类的设计，个人觉得非常不合理。“高保真”属于详细设计阶段，而方案汇报则是在需求确认阶段进行的。此刻，原型是否完成并不是关键，重要的是业务流程的改进对各方的影响是否合理且正向。
详细计划一般重点介绍详细的排期，事先可以与开发团队沟通可用的技术资源。先给出按大功能模块排期的工作计划，预估出上线时间点和培训计划。汇报的重点也包括，当前上线计划是否符合业务目标、是否有足够技术资源支持当前目标。可以在会议上对这部分内容进行确认并通过会议纪要的方式存档。
第二个要关注的重点内容是验证指标。通常我们认为一些易用性的提升是比较好验证的，比如增加批量处理功能这类较小的功能点，这类无需重点强调。比如，访问量、目标用户转化率等等指标则需考虑是否需要埋点等等。
讲好“业务价值”，只是开始。业务方案评审会结束后，需根据会议上的内容进行详细设计、组织需求评审会、需求研发等等。
下图为IPD产品研发中需求管理的标准化模型。业务方案评审可以理解为需求分析和需求分发阶段的过程产物。
验证愿景，是指阶段性基于在详细计划中设计的验证指标进行回顾。比如，预计平均缩短采购流程1天，这是完全可以通过数据库拉取数据验证的。同时，应更新需求状态，对需求管理进行复盘，对比部门的年度计划验证整体计划的执行情况。
以下为需求管理示例图。
本文由 @薯角 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。