如何正确给产品经理提需求？
产品经理的主要工作就是承接业务部门的需求。某种程度上讲，业务部门都是产品经理需要用心伺候的“老爷”。尤其是那些为公司创造真金白银收益的部门，更是一刻都不敢怠慢，但业务同学却觉得与产品经理沟通很困难，经常被怼。
那这是为什么呢？
是因为业务同学普遍不了解产品同学的工作，也不清楚项目开发的流程。业务同学不清楚应该如何与产品经理对接，所以在需求讨论、项目推进的过程中相互难以理解，沟通困难。
那如何正确给产品经理提需求呢？
一、背景
业务同学给产品同学提需求的时候，首先要说明需求的背景，一般包含场景、痛点、价值，也就是这个需求是怎么产生的，你为什么要提这个需求，这个需求能解决什么问题，把事情的来龙去脉、完整经过说清楚。产品同学会根据你的需求背景去提供解决方案来满足你的需求。
如果业务同学不说明需求背景，或者自己就搞不清楚背景是什么，只是直接要求产品同学按照自己说的去做的话，作为一个负责任的产品经理，是会拒绝的。
首先：产品同学不了解需求背景的情况下，是无法判断需求合理性的，更不可能提供出有效的解决方案，真正地满足业务需求。
因为人与人的沟通之中，很多时候业务同学所表达出来的和自己所想的并不一致，这并不是业务同学的问题，这是一个沟通难题，所有人都会存在这种问题，要不大家也不会把沟通能力看得那么重要。
产品经理一项重要的工作就是做需求分析，何为需求分析？那就是挖掘你最真实的想法、你最核心的需求，只有满足了你的核心需求，才能真正解决问题。这也是产品经理为什么会问你很多问题的原因。
其次：业务同学是没有产品同学了解业务系统的，所以业务同学需要给产品经理讲清楚需求背景，让产品同学给你提供解决方案才是最好的合作方式，而不是直接告诉产品经理你应该做什么。
如果业务同学过于强势，产品经理在不了解需求背景的情况下，真的按照业务同学要求的直接去做了，那可能会使系统缺少规划，难以长期、有效、快速地支持业务发展。
例如：你提的需求系统已经支持了，但你不知道，产品经理不了解需求背景的情况下，直接按照你的需求做了，会导致重复开发、系统臃肿等一系列问题。
所以首先要讲清需求背景，然后交由产品经理提供满足需求的解决方案，让专业的人做专业的事。
二、需求分类
业务同学提出的需求主要包括这么几类：功能类、数据类、体验类、性能类和BUG修复类，其中业务同学最多的是功能类和数据类需求。
- 功能类：通过人与系统交互的方式，来帮助业务同学解决问题，完成任务。例如：订单修改功能、记录备注功能、线索分配功能等。此类需求需要业务同学具有较好的逻辑思维能力，能把需求逻辑或规则梳理描述清楚。
- 数据类：主要包括两块内容，一个是数据字段定义，即数据统计口径。很多时候出现数据不准确的问题都是因为数据口径不一致导致的。另外一个是筛选条件，当数据较多时，能够有效地对数据进行筛选。
- 体验类：C端产品，用户体验直接关系到用户转化和用户留存，关乎到产品的成败，至关重要；B端产品，关系到业务同学的工作效率，可以通过优化操作流程或页面呈现来提升用户体验。
- 性能类：一般是指响应速度、可靠性、安全性等。例如：页面过很久才能打开，响应速度慢；或者有时候能打开，有时间打不开，可靠性较差；或者可以随意修改数据，安全性较低。
- BUG类：是指已上线功能未能按照需求逻辑得到预期结果。业务同学在描述BUG的同时，最好能提供CASE方便技术同学排查。BUG可能会带来未知的损失，需要立即被解决，所以这也是优先级最高的需求。
还有一些其他的需求分类方式，例如：KANO模型。
KANO 模型多用于对C端用户需求的分类，是以分析用户需求对用户满意的影响为基础，体现产品性能和用户满意之间的非线性关系。根据不同类型的质量特性与顾客满意度之间的关系，将产品服务的质量特性分为五类：
- 基本（必备）型质量——Must-be Quality/ Basic Quality；
- 期望（意愿）型质量——One-dimensional Quality/ Performance Quality；
- 兴奋（魅力）型质量—Attractive Quality/ Excitement Quality；
- 无差异型质量——Indifferent Quality/Neutral Quality；
- 反向（逆向）型质量——Reverse Quality。
三、收益才是王道
每个需求都需要动用研发资源，所以需要产品经理站在公司的角度去考虑ROI（投入产出比），让任何的研发投入都能够带来最大化的收益，这是产品经理本职工作之一。
一个需求的收益不仅决定了这个需求要不要做，也决定了需求的优先级，高优先级会被尽快开发，低优先级就要给高优先级让路，最后有可能会被一直搁置。
最简单的确定需求优先级的方法就是“四象限法则”，把需求按“重要/不重要”、“紧急/不紧急”2个维度进行分类。
如何让产品经理认为你的需求在第一象限呢？如何能够快速推动一个项目呢？那就是收益，收益才是王道。
那如何计算收益呢？可以想一下你的OKR是啥？你的KPI是啥？
这个需求对你的OKR或者KPI有啥影响，有多大的改善。量化收益的确是一个很难的问题，需要业务同学多想想。不能拍脑袋，要有理有据，功能上线后，产品经理是要对收益进行验收的。如果提供的收益不靠谱，可能以后的需求也会被产品经理质疑其重要、紧急的程度。
四、用数据说话
当你和产品经理就一个问题争执不下的时候，最好的办法就是用数据来证明。数据分析主要包括六个阶段：明确分析目的和思路、数据收集、数据处理、数据分析、数据呈现、报告撰写。
数据分析最重要的，也是最先要做的就是明确分析目的和思路。
只有明确了分析目的和思路才能有效地对数据进行分析。如果不事先明确分析目的和思路，只是一味的盲目分析，最终是得不出任何有效结论的。花了很多时间做分析，却不知道自己在分析什么，只能是白白浪费时间。
数据分析比较简单常用的分析方法有对比法、交叉法、综合评价法和漏斗图法。
五、如何提升逻辑思维
在提需求的时候，如何把业务流程、规则等说清楚？那就需要有很好的逻辑思维了。产品经理普遍都具有较好的逻辑思维，这不是天生的，也是慢慢练出来的，所以业务同学也可以具有较好的逻辑思维能力。
那如何锻炼自己的逻辑能力呢？
1. 流程图
对于具有较强逻辑性的业务，可以通过画流程图的方式来提升自己的逻辑能力。
把一个事情或者一个流程，通过流程图的方式，按步骤表达清楚。画流程图也是产品经理的日常工作，产品经理逻辑能力好不是没有原因的，都是日常锻炼出来的。
2. 思维导图
思维导图可以帮助你分析问题，将一个问题或者一个事情细分，按照不同维度进行拆分，帮助你分析思考。当一个需求涉及内容较多的时候，产品经理也会使用思维导图来梳理需求。
3. 5W2H
5W2H是分析问题的一种方法，将一个事情或者一个需求从这7个方面去拆解，按照拆解的结果将需求转化为系统的各个功能模块。虽然不需要业务同学能够拆解需求，但能够使用该方法先对自己的需求进行梳理，也会大大提升与产品经理沟通效率的。
发明者用五个以W开头的英语单词和两个以H开头的英语单词进行设问，发现解决问题的线索，寻找发明思路，进行设计构思，从而搞出新的发明项目，这就叫做5W2H法。
- WHAT——是什么？目的是什么？做什么工作？
- WHY——为什么要做？可不可以不做？有没有替代方案？
- WHO——谁？由谁来做？
- WHEN——何时？什么时间做？什么时机最适宜？
- WHERE——何处？在哪里做？
- HOW ——怎么做？如何提高效率？如何实施？方法是什么？
- HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
六、没有完美方案
产品经理提供的解决方案是平衡了对需求的满足程度和开发成本的，是要考虑ROI的。
在开发成本未出现明显差异的情况下，产品经理会尽所能地满足业务需求，或超预期的满足业务需求；但在开发成本出现明显差异的情况下，产品经理会在满足业务同学核心需求的情况下，去说服业务同学采用不完美的次优方案，但却是ROI最高的最优方案。
所以，当出现此类问题的时候，业务千万不要过分纠结方案是否完美，要明白在满足业务需求的前提下，ROI最高才是最优方案。即便是不惜一切代价做出来完美方案，但也只是现阶段的完美。
随着业务的飞速发展很快就变得不完美了，不能再支持业务的发展。在互联网行业，能够快速抢占市场，也是需要业务同学考虑的重要因素。过于追求完美方案，最终失去了抢占市场的先机，得不偿失。
引用一句邓爷爷的名言：“黑猫、白猫无所谓，能最快抓耗子的就是好猫。”
七、表达感激
产品经理之所以被叫做产品狗，是因为真的每天累成狗，对结果负责，工作无边界。不仅要对接业务部门需求，还要跟进开发进度、测试验收等，保证需求按时按量落地。
所以业务同学要及时表达对产品同学的感激，在有正向结果的时候，要及时同步产品同学，肯定产品同学的工作和价值。
要是你能提出高质量高收益的需求，提升产品同学工作效率和价值，那产品同学也会由衷感谢你的。
八、最后
如果你能做到以上这些的话，那你已经是一个具有产品思维的业务同学了。你会发现再也不被产品同学怼了，沟通也变得高效了。产品同学会成为你最坚实的后盾，帮助你攻克一个个业务难关。
作者：月尊；公众号：杂的界
本文作者 @月尊
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
