业务同学看过来，八个方法教你更高效给产品经理提需求！
一个普通的工作日下午，同事小R给我发了个钉钉对话截图（附带个委屈的表情）。大致的意思是Y姐要求PM在FAQ总增加几条内容，需求很普通，沟通方式很犀利。
“你不要问这问那，我在一线看到很多问题，你就赶紧给我加上去就行了！”
“能不能让我看一下您这边整理的调研资料？”
“不是跟你说了，我看到很多问题了吗，没工夫整理什么资料，你赶紧给我加上去，这么点事怎么那么费劲！”
……
最终因为断断续续的反复沟通了很多天都没有进展，只能升级到我这里处理了。
其实类似的事情在业务方和产品之间经常发生，这也就是为什么说产研团队最大的成本不是开发而是“沟通”了。
那业务同学到底该如何给产品经理提需求，才能更加高效呢？
01 说清楚背景
每当业务同学提交需求的时候，都有个典型的特征：充满激情，有种要拯救世界，解放全人类的感觉。
有这种特质的业务同学是非常优秀的，但也常犯一个典型的错误：想当然的认为产品也是这么想的。
但是，此时的产品就只会思考一个问题——“这个需求真的存在吗？”
这是一种定性的考虑，如果需求本身就不存在，那么产研团队后续的任何投入都是一种浪费。
这个时候你往往会发现，产品经理一直会追问你：
“为什么需要这个功能？”
“谁会使用这个功能？”
“会在什么场景下使用？”
本质上就是通过了解需求背后的场景，来做需求真伪的判断。
相信我，但凡有经验（被坑过次数较多）的产品一定会把这条作为优先级最高的判断。
所以，给产品经理提交需求。首先最重要的是，要交代清楚需求的背景，一般包括场景、用户和痛点（有的时候也是价值）。
建议开场白如下：
“hi，天儿哥，我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。”
02 证明需求的相关性并量化其价值
真实的场景描述，会解除产品经理对需求本身真伪性的质疑。
但是众所周知，任何团队研发资源都是稀缺资源，意味着任何的投入都会产生机会成本。
产品经理的工作职责就是：保证在正确的方向上，任何的研发资源投入都要能够带来明确的产出。
所谓正确的方向，就是该需求产生的价值与公司业务当前阶段战略目标相关，能起到有效的支撑；如果公司当前的阶段目标是节约运营成本，这时候你提个“支付渠道路由对接”的需求，肯定好过提“对接用友财务系统”。
所谓明确，就是能够量化。不是说不能够量化的就不做，只是比较麻烦，需要老板特批（对不确定性的需求的一种认可）。一般来讲大部分都是可以量化的，只是没有深度思考罢了。
所以，此时产品经理紧接着会考虑的这样问题：
“你们部门的OKR是啥？”
“你这个需求的价值有多大？”
建议对话更新如下：
“hi，天儿哥，我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。
我做了个统计，公司目前有2765名BD（示例），每天花费在检索线上的时间大概是2个半小时（通过BD陪访和问卷收集了200多个样本），统计下来，这方面每天大概要花掉6912个小时，占总工时的25%（按每天工作10个小时计算）。
俺们部门现在OKR重点是提升BD人效，所以这块咱们要是能搞一下，还是挺有价值的。”
03 提供参考建议并附上注意事项
真实的场景，明确的价值，基本上就是个靠谱的需求了。
此时的产品会根据业务方提供的信息，考虑初步的解决方案了，一般会提供几种解决方案的思路，和业务讨论。
一般来讲，大部分业务会认为此时提交需求的事情基本上就完事儿了，剩下的就是等着产品经理给方案了。
这样没错，但效率很低。
造成反复沟通的原因无非两点：
以前听过这样一个法律纠纷：说是一家外贸公司进了一批北极鳕鱼，本来想要的是产地是俄罗斯的，结果卖家给的是法国的，最后法院只能以合同没有明确约定产地为由，驳回买家请求。
这个故事留下来的经验是，好的合同一定是律师和业务方一起努力的结果，仅仅是依靠律师肯定是不行的。
——同理，一个好的方案仅仅是依赖产品经理，也是不行的。
所以，在提交需求的时候，如果你已经有了自己的想法，不妨明确的和产品经理提出来，作为参考。
如果在业务方存在的一些规则和风险也要第一时间明确出来，避免后续因反复沟通耽误需求进度。
建议对话更新如下：
“hi，天儿哥，我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。
我做了个统计，公司目前有2765名BD（示例），每天花费在检索线上的时间大概是2个半小时（通过BD陪访和问卷收集了200多个样本），统计下来，这方面每天大概要花掉6912个小时，占总工时的25%（按每天工作10个小时计算）。
俺们部门现在OKR重点是提升BD人效，所以这块咱们要是能搞一下，还是挺有价值的。
来之前，我看了一下几家竞品的解决方案，其中这家我觉得挺好的，建议参考一下。另外，BD那边有特殊规定，不许BD跨区域拜访，这需要特别注意一下。”
04 解决问题而不是坚持方案
此时就进入到了提交需求的隐性阶段。
一般来讲，在开发成本相同的情况下，产品会优先考虑业务方建议的方案，避免额外的沟通成本和业务风险；但在开发成本出现明显差异的情况下，产品会尝试说服业务接受新的方案。
主要的方式就是回顾目标，基于前期充分的沟通，大家对核心问题的认知是一致的，原则上“只要能在预期时间内能解决问题”的方案都是可接受的，当然哪个更快就优先选择哪个方案。
建议方案选择上，业务同学要尽量尊重产品经理的意见。主要是要维护好他的主动性，比较没脑子的做法就是把产品经理当成写稿的。
所以，当出现此类问题的时候，业务千万不要在方案上纠结“到底用谁的”，这只会把双方的精力都分散到论证各自的正确性上，可笑的是最后大家拼的是“体力”。
没必要，只要能尽快拿到结果。
“黑猫、白猫无所谓，能最快抓耗子的就是好猫。”
05 友善的沟通方式
能做到上述的业务同学，可以说是优秀的水平了。
如果能在沟通技巧上在注意一下，那就更好了。
要知道产品经理，之所以叫做产品汪，真的是每天累成狗，对结果负责，工作没有边界。
要是你能在沟通之前，把需要沟通的内容提前发给产品经理，再约个沟通时间。
那本世纪最受欢迎的业务方，非你莫属。
06 自行解决内部优先级
一个比较让产品经理头疼的问题，就是同一个部门有若干个需求方（共用研发资源），彼此之间的需求的预期时间存在冲突，一般情况下产品经理会主动反馈相关方自行沟通（有的时候产品也会参与）。
这是大部分公司的常态，业务同学也会认为这就应该是产品经理分内的事情。
这么说，没毛病。
但是——太被动和消极了。
比较建议的做法是，找产品经理要一下需求池地址，主动了解目前的需求情况。
如果在找产品经理之前，就已经协调好了内部的需求优先级，相信我，产品经理一定会“以身相许”的。
太体贴人了！
07 善用敏捷通道
上述表达的都是常规性的需求，周期比较完成和严谨。
还有一类比较特殊的需求，工程成本很低（改个文案、改个图片、调整各大小等等），个体价值不明显，但数量多了又对用户体验很有伤害（价值逐渐体现），此类被称为“敏捷需求”。
敏捷类需求的处理逻辑为“快速响应，持续迭代”：快速响应，换句话将就是只对需求做最直观的判断，甚至直接以业务方的为准；持续迭代，指一般的敏捷需求都会采用“周迭代”的方式，批次不断进行优化。
业务同学应该善于利用这个通道，尽量为自己的需求，找到一个成本很低的方案。
08 及时表达感激
一旦通过业务的方案评审，产品经理就要推进工程团队尽快启动。
整个产研团队后续还要经过工程评审、进度review、联调测试、工程验收、业务验收、上线通知等等诸多环节，保证如期履约。
这个阶段，业务同学除了要重视测试的验收，做好风控以外，尤其要在意上线通知阶段，不管结果如何，一定要在对应的邮件回复表达对过程的感激。
当然，后续有正向结论的时候，要再进一步肯定产研团队的价值，为后续的合作，奠定一下感情基础。
写到最后，想起前两天看到的一句话，献给那些追求卓越的业务同学：
人生就是场马拉松，只要你愿意做出改变，任何地方都可以是起点。
