业务部门应该如何向产品经理提需求?

5 评论 8166 浏览 18 收藏 15 分钟

常常会听见业务部门抱怨,自己提的需求没有被产品经理重视,而后者也常常抱怨业务部门。本文作者将从业务部门的角度出发,谈谈如何向产品经理提需求,以此来促进产品更好地发展。

01

对产品经理来说,公司内部的业务部门,就是给自己“提需求”的存在。

公司根据业务需要,会划分出若干业务部门,比如说市场部、销售部、财务部、客服部、运营部等等。

这些部门在运行过程中,为了更好地完成自己的任务,会源源不断产生新的“需求”。

而产品经理的主要工作之一,就是承接这些需求。

某种程度上讲,这些业务部门,都是产品经理需要用心伺候的“老爷”。

尤其是那些为公司创造真金白银收益的部门,更是一刻都不能怠慢。

情况按理说应该是如此。

但是,据我观察,业务部门普遍觉得,和产品经理打交道很困难,自己的意见经常被产品经理忽视,自己的需求总是被拖延,最终交付的效果总和自己的要求相去甚远。

为什么业务部门会有这样的认知呢?

我认为,这是因为业务普遍不了解产品经理的工作,也不清楚项目开发的流程。

业务不清楚应该如何与产品经理对接,所以在需求讨论、项目推进的过程中,业务与产品之间容易互相误解,协作不顺畅,甚至出问题。

所以,这里我想站在业务部门的角度,来谈谈“业务部门向产品经理提需求”这个话题。

当然,如果你是一名产品经理,我也建议你稍微看一看。

这种换位思考,我认为也是一种不错的自我反思方式。

02

为什么说“业务部门”是产品经理需要用心伺候的老爷?

产品经理的工作,都是围绕着“需求”进行的。

那么,在实际工作中,产品经理的“需求”,主要来自哪里呢?

需求的来源,主要有两个:老板、业务部门。

如果严谨一点,也可以说是三个:老板、业务部门、其它。

产品经理的需求,我认为,大概有80%来源于“老板”和“业务部门”。

这其实很好理解。

我们打造一款产品,并不是为了参加“产品设计大赛”,而是为了公司业务的需要。

那么,谁最懂公司的业务?

当然是“老板”和“业务部门”。

老板,掌握着公司所有信息,而且往往是在行业内打拼多年的行业专家,可以说是最懂公司业务的。

各个业务部门,他们的日常工作,就是围绕着“具体业务”进行的。他们了解业务的每个具体细节,对市场最新动向非常敏感,肯定比产品经理更懂业务。

从某种意义上讲,“产品”的本质,是公司业务的载体。产品经理的工作,不是“开辟”公司业务,而是“服务”业务部门,使之能更好地通过“产品”去服务用户。

如果是十来人的小公司,一般来说,需求大部分来源于“老板”。

这是因为,这时候公司本质上是靠创始人团队自身的资源和渠道来运转的。

随着公司逐渐步入正轨,业务部门人员不断扩充,来自“业务部门”的需求会逐渐增多,最终成为产品经理需求的最主要来源。

这时候,产品经理的主要工作,就是去服务好这些业务部门。

03

业务部门对产品经理最常见的不满,就是产品经理不重视自己的需求,要么把需求打回,要么延后处理。

这里就涉及到“需求管理”的问题。

说到“需求管理”,最常见的大概就是“四象限法则”。

把需求按“重要/不重要”、“紧急/不紧急”2个维度进行分类,决定各需求的优先级。

但是,这并不是说,完全由产品经理自行决定每个需求的优先级。

需求传达到产品经理这边时,其“重要紧急”程度,已经大体确定了。产品经理不过是进行“微调”而已。

就好比,你同时接到3个任务。但是你只有一个人、两只手,任务只能一个一个做。

3个任务中,有1个不那么重要,就先放着。

剩下2个都是重要的,1个是下周要完成,1个这周末就要。

那就先做这周末要的那个任务。

所谓“需求管理”,简单来说,也就是这样。

所以,需求的“重要紧急”程度,在传达给产品经理之前就已经基本确定了,也就是说,是由业务部门根据业务具体情况来确定的。

比如说,市场部和合作公司谈了一个项目,定好下周要上线推广。那产品经理还有什么好说的呢?当然是马上暂停手上的工作,集中精力先去把这个项目搞出来。

当然,不同公司的决策机制各不相同。有些公司,产品经理会有不小的决策权。

那怎么分辨呢?

其实也很简单。

我们想象这么一个场景:有个项目没有按时做好,领导震怒,把人叫到办公室去骂。

那么,简单来说,被叫到办公室的人,就都是有决策权的人。被骂得越惨的人,决策权就越大。

看到这里,有些业务同事可能就要不同意了:“你说需求的优先级,主要是由我们业务来决定。但是,我明明说了需求很重要,还是被产品经理给否了!我明明说了需求很紧急,可好几天了,产品经理还没开始搞!”

对此,我要反问一句:“你的需求真的重要吗?真的紧急吗?”

产品经理普遍是很忙的。

比如说我,身上同时堆着5、6个大需求,基本是常态。

可能,我现在在做的需求,是半个月前提过来的“重要”需求。领导催了3次的那个需求,前面还有一个更重要的,它只能排在第3位。还有2个需求,需求方可能自己都忘了,实在没空搞,先放着。

每个人都觉得,自己的需求,才是“最重要”、“最紧急”的。

说需求很重要,可产品经理提几个意见,你就不搞了,那怎么算“重要”呢?

说需求很紧急,可产品经理给搁置了,你也就不了了之,那怎么算“紧急”呢?

光说是没有用的,要用行动来证明。

被产品经理“怠慢”了,就多交涉几次。不行,就让上级去和产品经理交涉。还不行,就找领导。找领导也不行,就发工作邮件,抄送给所有相关的领导同事。

这样,产品经理才能感受到你的“诚意”。

反之,如果产品经理“不重视”,业务就“妥协”,那也就意味着,这个需求其实并不着急。

04

业务部门给产品经理提需求,简单来说,就是安排任务。

其实没有太多讲究,把任务说清楚,就行了。

业务部门在提需求过程中,有几个常见的问题,这里简单说一下。

1. 提需求要按照规定的流程来

提需求,是一个常规操作。每个公司,都会有相应的流程要求,有些是明文规定,有些是约定俗成。

不少业务同事,在提需求时,可能是觉得走流程浪费时间,总喜欢绕过这些条条框框,直接去找和自己关系比较好的、或者比较好说话的产品经理,让其处理。

把一个正常的工作流程,搞得和“走后门办事”一样。

这是不对的。

为什么呢?

做这个需求,往往意味着要暂停、推后其他需求。产品经理,尤其是初级产品经理,往往是无权单独做这个决策的。

做一个需求,并不是产品经理一个人写个文档就完事的,它需要调动若干部门的人和资源。产品经理本质上并没有这个权利。

这些,都是需要通过“制度流程”来解决的。

业务同事不按流程来,那就只能由产品经理来补。业务是省时间了,但却占用了产品经理的时间。

产品经理手头经常会堆积很多需求。那些不按流程来的需求,自然而然会被排在正式需求之后。

2. 需要完整清楚地传达需求的背景

在与需求方沟通时,产品经理需要分辨需求方所讲的是“需求”还是“解决方案”。

但这是产品经理这边的事情,业务同事可以完全不用在意这点,把自己想要传达的内容传达出来就可以了。

相对的,在提需求时,业务同事需要比较细致地说明清楚需求的背景,以及业务的情况。

正所谓“隔行如隔山”,一些在自己领域内的“常识”,外行人其实并不清楚。

产品经理,其实并不懂业务,至少没有业务同事那么懂。

所以,在提需求时,需要说明清楚这个业务是怎么样的,流程是怎么样的,为什么要做这个需求,要在什么场景下使用,市场上其他公司是怎么做的,监管上有什么硬性要求,等等。

这些情况,是产品经理策划需求时非常重要的决策依据。

有些业务,可能是出于对产品经理的不信任,或是觉得麻烦,提需求时不愿意提供这些必要的信息,“你只要照我说的,这里这么做,那里那么做,就行了”。

对于这种情况,产品经理也只能按照需求方的要求来搞。至于后续出现什么纰漏,产品经理也爱莫能助了。

3. 体验好不好,可能得听产品经理的

产品经理经常会收到很多“用户体验优化”的建议。

这些建议都很有价值。

因为,市场部门肯定比产品经理更了解商品和业务,销售部门肯定比产品经理更懂得如何吸引用户购买,客服部门肯定比产品经理更清楚用户生气的点。

但是,产品经理不会简单地全盘接受,而是需要进行通盘考虑。

每个人都觉得,自己发现的这个问题,是那么的“显然”,产品经理居然不接受,很莫名其妙!

但是,产品经理知道,“个人的体验”是有特殊性的,不一定代表“用户的体验”。

简单来说,就是“你觉得的”,不一样是“用户觉得的”。

业务同事可能会问:“那产品经理觉得的,就能代表用户吗?”

说实话,其实也不能。产品经理也不能代表用户。

那凭什么要听产品经理的呢?

很简单。因为如果产品的体验不好,被骂的是产品经理。所以产品经理有这个决策权。

当然,并不是说我们不能给产品经理提意见。

我想,大部分产品经理都是非常乐意听取别人反馈的。

05

提需求,是有成本的,而且成本还不小。

这点,可能很多业务同事都没有意识到。

提需求,并不是和产品经理沟通清楚,把任务安排下去,就完事了。

需求立项之后,后续的需求讨论、项目跟进、测试验收,全程都需要需求方跟进。这是非常耗费时间精力的。

如果提了需求就不管,那么验收时,很大概率会发现,交付的东西完全偏离了最初的设想。

所以,业务和产品,从某种意义上讲,是站着同一阵营的,双方需要互相协作,共同推进项目,共同为需求负责。

 

作者:简明产品轮,个人公众号:简明产品论(ID:JianMingPM)

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

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 谁说业务部门最懂业务了,更多情况是不懂,没想法就去找产品,难道还要带着业务从头梳理吗,这也是为什么产品有时候不愿意理业务的原因。我有一个对口业务,问我什么是ab测试,功能上线从来不考虑产品和研发成本

    回复
    1. 功能上线从来不考虑产品和研发成本====我们有个运营也是这样,每次都要先讲一遍道理,再拒绝这种需求。

      回复
    2. 一般业务部门先以业绩结果为主考虑,关于产品研发成本就要拉上项目经理、部门负责人在评审阶段讨论?资源紧张时,可以摆出来大家再排序,正常是可以理解吧

      回复
  2. 有两种人可以解决:懂业务的产品,或者懂产品的业务。😂

    回复
    1. 现实中不存在这样的物种 😳

      回复