8年产品经验复盘总结-2.2业务规划中的业务调研

人人都是产品经理

  ·  

2025-07-08 03:05:31

  ·  

0次阅读

业务规划做不好,往往不是因为缺乏战略眼光,而是因为调研做得不够扎实。在产品经理的实际工作中,业务调研既是信息输入的起点,也是决策质量的保障。本文基于作者8年产品经验,系统梳理了业务调研的核心方法与常见误区,从调研目标设定到信息结构化输出,手把手教你如何用调研驱动业务判断。

1.案例分享

我曾经入职一个零售公司,在前期还没熟悉业务的时候,就得到一个让人摸不着头脑的任务:

把经营状况好的地区团队做得好的部分总结出来,考虑系统化给其他团队复用,达到全网经营水平提高的任务。

更重要的是,我只有两周周时间。

不过结果我还是完成了任务,给出一场产研部门和业务团队都点赞的调研分享。这个任务是怎么完成的呢,请耐心听我接下来的分享。

a.要总结好的部分给其他团队,这就说明存在差距,有对比。

就像做实验,要有实验组和对照组。所以,要调研全网做得最好的地区,也要找一个相对较差的地区。如果时间允许,再根据两者的对比结果找一个中等地区做验证。

b.一个地区团队由多个岗位人员组成,经营良好理论上是共同努力的结果。

要想调研结果全面,必须覆盖尽可能多的岗位人员。所以必须合理运用时间,对每个岗位都做一次沟通对话。如果岗位有两个人,那么就调研表现更好的一个。

于是我拟定了沟通时间计划,和地区总经理打了招呼。要进行一系列的人员沟通访谈

c.让地区人员脱产来和产品沟通,问的问题必须要足够关键,最大化时间的价值

每个岗位在工作的行动,必然是有指标在背后驱动的,可以是销售目标,也可以是异常指标,比如客户的投诉,上级的催促,自我驱动…这些指标可以是量化的,也可以不是量化的,但必然有一个可以被观察得到的信息。

我最终得出了一套极为抽象的公式:观察指标 – 行动 – 观察指标 – 改进 – ….

基于此,我调研业务团队的问题就是:

1、你负责什么内容(开场)?

2、具体的工作有哪些?

3、你工作的依据是什么(或者怎么判断要做这件事)?

4、这些工作中,时间占比分布是怎么样的?

通过问题1和2,把每个岗位都进一步细化拆解成一个个工作流。

通过问题3,了解每个工作流的依据,还有团队和个人的业务指标。

通过问题4,了解每个工作流在实践过程中所耗费的人力成本,对团队降本增效的路径有了明确的方向。

回过头来总结一下,这次的调研对产品经理在进行业务调研有什么启发呢?

产品经理的本质是解决业务问题,在业务调研中,产品要做的是:

1.确定(暴露)业务中的问题,暴露产品可以解决的业务问题

2确定这些问题的解决优先级

2. 暴露问题

对于企业来说,使用软件系统的目的,在于降本增效

企业由员工组成,员工其实又是由一个个要完成的工作组成,给企业增效,本质是给人增效(给每一个工作流增效)。

而每一个工作流,背后又都是由指标驱动。

系统帮助企业降本增效,可以简单分三步

a.把工作流线上化。通过线上化,让员工之间的信息传递更快,协作效率更高

b.线上化的同时,也把数据线上化了,指标也就同步完成了线上化,问题能暴露得更及时

c.再进一步,把各个业务环节的指标数据打通,让公司知道每个工作流背后可能带来的收益和成本,辅助调整决策结果,那么公司的运转效率将会最大化。

产品经理的业务调研是辅助后续的系统设计的,那么业务调研要完成的任务,就是了解业务工作流中的以下部分:

a.找到没暴露的指标

b.找到信息传递缓慢的环节

c.设计功能模块,将工作流尽量线上化

d.打通数据,辅助优化决策逻辑

结合这些调研问题,通过当面沟通,能够帮助产品经理确定业务中的问题

除了看到问题,我们还要确认业务问题的影响范围,给问题解决的优先级排序。

3. 问题排序

确认业务问题的影响范围,我把这个过程定义为定量,通过判断不同业务人员反馈信息的真伪,听到他们的言外之意,来确定实际的影响范围。

这就要求要先对公司各个部门和人员的角色有一定的了解。

a.了解企业部门和人员结构

企业存在分工,有不同部门,部门里面也有不同岗位,部门和部门之间,岗位和岗位必然存在业绩指标的差异,也就存在一些指标冲突。

举个部门指标冲突的例子:

销售:销售人员的指标是客户量,所以他们会不断地通过各种手段去开发客户,对内压指标或者用不合理的奖金引诱销售人员行动。但如果他们对新客户不加筛选,很容易就会导致客户池里出现过多的低质用户

运营:后期进入合作阶段,运营指标、商品销售数据都不好看的情况。

整体结果:销售部门的kpi很好,运营部门kpi极差,公司花了不少经费在市场推广和销售工资商,结果经营情况不达预期。

产品资源其实也是资源的一种,能够辅助企业中各个部门完成指标。

同一个问题,对不同部门不同人员的影响也不一样,有正向的有负向的,有大有小的,所以在确定业务问题实际影响范围的过程中,对企业内的组织结构,对外部客户的相关信息,有一个大体的了解,往往就能帮助产品经理判断对方对这个问题评价结果的原因。理解他们反馈的内容,更好的帮助我们判断调研信息的真伪。

简单介绍常见的公司组织结构。

如果是销售实物商品的公司,一般总部有职能部门,地区也有对应的职能部门,虚线接受总部职能部门的管理和建议。

总部职能部门,因为对整体指标负责,要实现的更多是全局性的策略,各地区通用的策略。还有一些整体性的管理需求,比如数据看板之类的

而地区团队,如果地区是自负盈亏的话,关注的更多是执行的内容,对外维护供应商,对内加强管理,考核执行。如果地区不是自负盈亏,那么就是执行总部策略了。

如果是销售软件的公司,总部会有职能部门,地区则一般只有商务部门,大一点的也会有技术支持部门,复杂到客户现场解决技术问题。

如果是纯toC的互联网公司,则没有地区团队,只有总部。

职能部门常见的是行政、人力、财务、市场、销售/运营、商务、商品研发/产品研发。

具体负责的指标,不同公司要求的不一样,有粗有细,这里就不深入了。

本文由 @正经的产品经理 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

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