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

1 评论 4992 浏览 64 收藏 9 分钟

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

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

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

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

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

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

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

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

2. 典型的错误案例

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

典型的错误的汇报方式:

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

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

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

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

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

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

1. 介绍业务背景

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

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

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

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

2. 介绍业务流程

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

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

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

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

3. 改进方案的详细介绍

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

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

4. 详细计划

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

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

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

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

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

四、验证愿景

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

以下为需求管理示例图。

本文由 @薯角 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 学到了

    来自浙江 回复