这样提需求，PM加班都愿意帮你做！

​

这是吴天的第6篇原创文章

一个普通的工作日下午，同事小R给我发了个钉钉对话截图（附带个委屈的表情）。大致的意思是Y姐要求PM在FAQ总增加几条内容，需求很普通，沟通方式很犀利。

“你不要问这问那，我在一线看到很多问题，你就赶紧给我加上去就行了！”

“能不能让我看一下您这边整理的调研资料？”

“不是跟你说了，我看到很多问题了吗，没工夫整理什么资料，你赶紧给我加上去，这么点事怎么那么费劲”

。。。。

最终因为断断续续的反复沟通了很多天都没有进展，只能升级到我这里处理了。

其实类似的事情在业务方和产品之间经常发生，这也就是为什么说产研团队最大的成本不是开发而是“沟通”了。

那业务同学到底该如何给产品经理提需求，才能更加高效呢？

第一、说清楚背景

每当业务同学提交需求的时候，都有个典型的特征：充满激情，有种要拯救世界，解放全人类的感觉。有这种特质的业务同学是非常优秀的，但也常犯一个典型的错误：想当然的认为产品也是这么想的。

其实，此时的产品就只会思考一个问题？

“这个需求真的存在吗？”。

这是一种定性的考虑，如果需求本身就不存在，那么产研团队后续的任何投入都是一种浪费。

这个时候你往往会发现，产品经理一直会追问你

“为什么需要这个功能？？”

“谁会使用这个功能？”

“会在什么场景下使用？”

本质上就是通过了解需求背后的场景，来做需求真伪的判断。

相信我，但凡有经验（被坑过次数较多）的产品一定会把这条作为优先级最高的判断。

所以，给产品经理提交需求。首先最重要的是，要交代清楚需求的背景，一般包括场景、用户和痛点（有的时候也是价值）。

一般的开场白如下：

hi，天儿哥。我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。

• 场景：扫街
• 用户：BD
• 痛点：优质线索获取效率低

第二、证明需求的相关性并量化其价值

真实的场景描述，会解除产品经理对需求本身真伪性的质疑。

但是众所周知，任何团队研发资源都是稀缺资源，意味着任何的投入都会产生机会成本。

产品经理的工作职责就是，保证在正确的方向上，任何的研发资源投入都要能够带来明确的产出。

所谓正确的方向，就是该需求产生的价值与公司业务当前阶段战略目标相关，能起到有效的支撑。如果公司当前的阶段目标是节约运营成本，这时候你提个“支付渠道路由对接”的需求，肯定好过提“对接用友财务系统”；

所谓明确，就是能够量化。不是说不能够量化的就不做，只是比较麻烦，需要老板特批（对不确定性的需求的一种认可）。一般来讲大部分都是可以量化的，只是没有深度思考罢了。

所以，此时产品经理紧接着会考虑的这样问题：

“你们部门的OKR是啥？”

“你这个需求的价值有多大？”

建议对话更新如下：

hi，天儿哥。我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。

我做了个统计，公司目前有2765名BD（示例），每天花费在检索线上的时间大概是2个半小时（通过BD陪访和问卷收集了200多个样本），统计下来，这方面每天大概要花掉6912个小时，占总工时的25%（按每天工作10个小时计算）。

俺们部门现在OKR重点是“提升BD人效”，所以这块咱们要是能搞一下，还是挺有价值的。

• 场景：扫街
• 用户：BD
• 痛点：优质线索获取效率低
• OKR：提升BD人效
• 价值：25%的工时占用，6912小时

第三、提供参考建议并附上注意事项

真实的场景，明确的价值，基本上就是个靠谱的需求了。

此时的产品会根据业务方提供的信息，考虑初步的解决方案了，一般会提供几种解决方案的思路，和业务讨论。

一般来讲，大部分业务会认为此时提交需求的事情基本上就完事儿了，剩下的就是等着产品经理给方案了。

这样没错，但效率很低。

造成反复沟通的原因无非两点：

1. 该考虑的业务风险没有考虑
2. 和理想中的方案有些距离，使用产品给的方案心理有点没底

以前听过这样一个法律纠纷，说是一家外贸公司进了一批北极鳕鱼，本来想要的是产地是俄罗斯的，结果卖家给的是法国的，最后法院只能以合同没有明确约定产地为由，驳回买家请求。

这个故事留下来的经验是，好的合同一定是律师和业务方一起努力的结果，仅仅是依靠律师肯定是不行的。

同理，一个好的方案仅仅是依赖产品经理，也是不行的。

所以，在提交需求的时候，如果你已经有了自己的想法，不妨明确的和产品经理提出来，作为参考。

同时，如果在业务方存在的一些规则和风险也要第一时间明确出来，避免后续因反复沟通耽误需求进度。

建议对话更新如下：

hi，天儿哥。我们在去BD陪访的时候，发现在BD扫街时效率很低，要自己人肉检索身边的线索，很多还是无效的（被别的BD跟进、竞品独家等）。

我做了个统计，公司目前有2765名BD（示例），每天花费在检索线上的时间大概是2个半小时（通过BD陪访和问卷收集了200多个样本），统计下来，这方面每天大概要花掉6912个小时，占总工时的25%（按每天工作10个小时计算）。

俺们部门现在OKR重点是“提升BD人效”，所以这块咱们要是能搞一下，还是挺有价值的。

来之前，我看了一下几家竞品的解决方案，其中这家我觉得挺好的，建议参考一下。另外，BD那边有特殊规定，不许BD跨区域拜访，这需要特别注意一下。

• 场景：扫街
• 用户：BD
• 痛点：优质线索获取效率低
• OKR：提升BD人效
• 价值：25%的工时占用，6912小时
• 建议：竞品xx的方案
• 注意：BD不许跨区拜访

第四、解决问题而不是坚持方案

此时就进入到了提交需求的隐性阶段。

一般来讲，在开发成本相同的情况下，产品会优先考虑业务方建议的方案，避免额外的沟通成本和业务风险。但在开发成本出现明显差异的情况下，产品会尝试说服业务接受新的方案。

主要的方式就是回顾目标，基于前期充分的沟通，大家对核心问题的认知是一致的，原则上“只要能在预期时间内能解决问题”的方案都是可接受的，当然那个更快就优先选择哪个方案。

建议方案选择上，业务同学要尽量尊重产品经理的意见。主要是要维护好他的主动性，比较没脑子的做法就是把产品经理当成写稿的。

所以，当出现此类问题的时候，业务千万不要在方案上纠结“到底用谁的”，这只会把双方的精力都分散到论证各自的正确性上，可笑的是最后大家拼的是“体力”。

没必要，只要能尽快拿到结果。

“黑猫、白猫无所谓，能最快抓耗子的就是好猫”

第五、友善的沟通方式

能做到上述的业务同学，可以说是优秀的水平了。

如果能在沟通技巧上在注意一下，那就更好了。

要知道产品经理，之所以叫做产品汪，真的是每天累成狗，对结果负责，工作没有边界。

要是你能在沟通之前，把需要沟通的内容提前发给产品经理，在约个沟通时间。

那本世纪最受欢迎的业务方，非你莫属。

第六、自行解决内部优先级

一个比较让产品经理头疼的问题，就是同一个部门有若干个需求方（共用研发资源），彼此之间的需求的预期时间存在冲突，一般情况下产品经理会主动反馈相关方自行沟通（有的时候产品也会参与）。

一般来讲这是大部分公司的常态，业务同学也会认为这就应该是产品经理分内的事情。

这么说，没毛病。

但是，太被动和消极了。

比较建议的做法是，找产品经理要一下需求池地址，主动了解目前的需求情况。如果在找产品经理之前，就已经协调好了内部的需求优先级。

相信我，产品经理一定会“以身相许”的。

太体贴人了！

第七、善用敏捷通道

上述表达的都是常规性的需求，周期比较完成和严谨。

还有一类比较特殊的需求，工程成本很低（改个文案、改个图片、调整各大小等等），个体价值不明显，但数量多了又对用户体验很有伤害（价值逐渐体现），此类被称为“敏捷需求”；

敏捷类需求的处理逻辑为“快速响应，持续迭代”。

快速响应，换句话将就是只对需求做最直观的判断，甚至直接以业务方的为准。

持续迭代，指一般的敏捷需求都会采用“周迭代”的方式，批次不断进行优化。

业务同学应该善于利用这个通道。尽量为自己的需求，找到一个成本很低的方案。

第八、及时表达感激

一旦通过业务的方案评审，产品经理就要推进工程团队尽快启动。

整个产研团队后续还要经过工程评审、进度review、联调测试、工程验收、业务验收、上线通知等等诸多环节，保证如期履约，还是很辛苦的。

这个阶段，业务同学除了要重视测试的验收，做好风控以外。

尤其要在意上线通知阶段。不管结果如何，一定要在对应的邮件回复表达对过程的感激。

当然，后续有正向结论的时候，要再进一步肯定产研团队的价值。

原因无他，为后续的合作，奠定一下感情基础。

写到最后，想起前两天看到的一句话，献给那些追求卓越的业务同学：

人生就是场马拉松，只要你愿意做出改变，任何地方都可以是起点。

未经允许不得转载（声明：本文内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：net-net@foxmail.com进行举报，并提供相关证据，工作人员会在10个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。）：策信智库资讯网 » 这样提需求，PM加班都愿意帮你做！