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

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

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 协议