欢迎光临
我们一直在努力

这样提需求,PM加班都愿意帮你做!(原创)

中信

业务同学看过来,八个方法教你更高效给产品经理提需求!

一个普通的工作日下午,同事小R给我发了个钉钉对话截图(附带个委屈的表情)。大致的意思是Y姐要求PM在FAQ总增加几条内容,需求很普通,沟通方式很犀利。
“你不要问这问那,我在一线看到很多问题,你就赶紧给我加上去就行了!”
“能不能让我看一下您这边整理的调研资料?”
“不是跟你说了,我看到很多问题了吗,没工夫整理什么资料,你赶紧给我加上去,这么点事怎么那么费劲!”
……
最终因为断断续续的反复沟通了很多天都没有进展,只能升级到我这里处理了。
其实类似的事情在业务方和产品之间经常发生,这也就是为什么说产研团队最大的成本不是开发而是“沟通”了。
那业务同学到底该如何给产品经理提需求,才能更加高效呢?

01 说清楚背景

每当业务同学提交需求的时候,都有个典型的特征:充满激情,有种要拯救世界,解放全人类的感觉。
有这种特质的业务同学是非常优秀的,但也常犯一个典型的错误:想当然的认为产品也是这么想的。
但是,此时的产品就只会思考一个问题——“这个需求真的存在吗?”
这是一种定性的考虑,如果需求本身就不存在,那么产研团队后续的任何投入都是一种浪费。
这个时候你往往会发现,产品经理一直会追问你:
“为什么需要这个功能?”
“谁会使用这个功能?”
“会在什么场景下使用?”
本质上就是通过了解需求背后的场景,来做需求真伪的判断。
相信我,但凡有经验(被坑过次数较多)的产品一定会把这条作为优先级最高的判断。
所以,给产品经理提交需求。首先最重要的是,要交代清楚需求的背景,一般包括场景、用户和痛点(有的时候也是价值)。
建议开场白如下:
“hi,天儿哥,我们在去BD陪访的时候,发现在BD扫街时效率很低,要自己人肉检索身边的线索,很多还是无效的(被别的BD跟进、竞品独家等)。”

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

02 证明需求的相关性并量化其价值

真实的场景描述,会解除产品经理对需求本身真伪性的质疑。
但是众所周知,任何团队研发资源都是稀缺资源,意味着任何的投入都会产生机会成本。
产品经理的工作职责就是:保证在正确的方向上,任何的研发资源投入都要能够带来明确的产出。
所谓正确的方向,就是该需求产生的价值与公司业务当前阶段战略目标相关,能起到有效的支撑;如果公司当前的阶段目标是节约运营成本,这时候你提个“支付渠道路由对接”的需求,肯定好过提“对接用友财务系统”。
所谓明确,就是能够量化。不是说不能够量化的就不做,只是比较麻烦,需要老板特批(对不确定性的需求的一种认可)。一般来讲大部分都是可以量化的,只是没有深度思考罢了。
所以,此时产品经理紧接着会考虑的这样问题:
“你们部门的OKR是啥?”
“你这个需求的价值有多大?”
建议对话更新如下:
“hi,天儿哥,我们在去BD陪访的时候,发现在BD扫街时效率很低,要自己人肉检索身边的线索,很多还是无效的(被别的BD跟进、竞品独家等)。
我做了个统计,公司目前有2765名BD(示例),每天花费在检索线上的时间大概是2个半小时(通过BD陪访和问卷收集了200多个样本),统计下来,这方面每天大概要花掉6912个小时,占总工时的25%(按每天工作10个小时计算)。
俺们部门现在OKR重点是提升BD人效,所以这块咱们要是能搞一下,还是挺有价值的。”

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

03 提供参考建议并附上注意事项

真实的场景,明确的价值,基本上就是个靠谱的需求了。
此时的产品会根据业务方提供的信息,考虑初步的解决方案了,一般会提供几种解决方案的思路,和业务讨论。
一般来讲,大部分业务会认为此时提交需求的事情基本上就完事儿了,剩下的就是等着产品经理给方案了。
这样没错,但效率很低。
造成反复沟通的原因无非两点:

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

以前听过这样一个法律纠纷:说是一家外贸公司进了一批北极鳕鱼,本来想要的是产地是俄罗斯的,结果卖家给的是法国的,最后法院只能以合同没有明确约定产地为由,驳回买家请求。
这个故事留下来的经验是,好的合同一定是律师和业务方一起努力的结果,仅仅是依靠律师肯定是不行的。
——同理,一个好的方案仅仅是依赖产品经理,也是不行的。
所以,在提交需求的时候,如果你已经有了自己的想法,不妨明确的和产品经理提出来,作为参考。
如果在业务方存在的一些规则和风险也要第一时间明确出来,避免后续因反复沟通耽误需求进度。
建议对话更新如下:
“hi,天儿哥,我们在去BD陪访的时候,发现在BD扫街时效率很低,要自己人肉检索身边的线索,很多还是无效的(被别的BD跟进、竞品独家等)。
我做了个统计,公司目前有2765名BD(示例),每天花费在检索线上的时间大概是2个半小时(通过BD陪访和问卷收集了200多个样本),统计下来,这方面每天大概要花掉6912个小时,占总工时的25%(按每天工作10个小时计算)。
俺们部门现在OKR重点是提升BD人效,所以这块咱们要是能搞一下,还是挺有价值的。
来之前,我看了一下几家竞品的解决方案,其中这家我觉得挺好的,建议参考一下。另外,BD那边有特殊规定,不许BD跨区域拜访,这需要特别注意一下。”

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

04 解决问题而不是坚持方案

此时就进入到了提交需求的隐性阶段。
一般来讲,在开发成本相同的情况下,产品会优先考虑业务方建议的方案,避免额外的沟通成本和业务风险;但在开发成本出现明显差异的情况下,产品会尝试说服业务接受新的方案。
主要的方式就是回顾目标,基于前期充分的沟通,大家对核心问题的认知是一致的,原则上“只要能在预期时间内能解决问题”的方案都是可接受的,当然哪个更快就优先选择哪个方案。
建议方案选择上,业务同学要尽量尊重产品经理的意见。主要是要维护好他的主动性,比较没脑子的做法就是把产品经理当成写稿的。
所以,当出现此类问题的时候,业务千万不要在方案上纠结“到底用谁的”,这只会把双方的精力都分散到论证各自的正确性上,可笑的是最后大家拼的是“体力”。
没必要,只要能尽快拿到结果。
“黑猫、白猫无所谓,能最快抓耗子的就是好猫。”

05 友善的沟通方式

能做到上述的业务同学,可以说是优秀的水平了。
如果能在沟通技巧上在注意一下,那就更好了。
要知道产品经理,之所以叫做产品汪,真的是每天累成狗,对结果负责,工作没有边界。
要是你能在沟通之前,把需要沟通的内容提前发给产品经理,再约个沟通时间。
那本世纪最受欢迎的业务方,非你莫属。

06 自行解决内部优先级

一个比较让产品经理头疼的问题,就是同一个部门有若干个需求方(共用研发资源),彼此之间的需求的预期时间存在冲突,一般情况下产品经理会主动反馈相关方自行沟通(有的时候产品也会参与)。
这是大部分公司的常态,业务同学也会认为这就应该是产品经理分内的事情。
这么说,没毛病。
但是——太被动和消极了。
比较建议的做法是,找产品经理要一下需求池地址,主动了解目前的需求情况。
如果在找产品经理之前,就已经协调好了内部的需求优先级,相信我,产品经理一定会“以身相许”的。
太体贴人了!

07 善用敏捷通道

上述表达的都是常规性的需求,周期比较完成和严谨。
还有一类比较特殊的需求,工程成本很低(改个文案、改个图片、调整各大小等等),个体价值不明显,但数量多了又对用户体验很有伤害(价值逐渐体现),此类被称为“敏捷需求”。
敏捷类需求的处理逻辑为“快速响应,持续迭代”:快速响应,换句话将就是只对需求做最直观的判断,甚至直接以业务方的为准;持续迭代,指一般的敏捷需求都会采用“周迭代”的方式,批次不断进行优化。
业务同学应该善于利用这个通道,尽量为自己的需求,找到一个成本很低的方案。

08 及时表达感激

一旦通过业务的方案评审,产品经理就要推进工程团队尽快启动。
整个产研团队后续还要经过工程评审、进度review、联调测试、工程验收、业务验收、上线通知等等诸多环节,保证如期履约。
这个阶段,业务同学除了要重视测试的验收,做好风控以外,尤其要在意上线通知阶段,不管结果如何,一定要在对应的邮件回复表达对过程的感激。
当然,后续有正向结论的时候,要再进一步肯定产研团队的价值,为后续的合作,奠定一下感情基础。
写到最后,想起前两天看到的一句话,献给那些追求卓越的业务同学:
人生就是场马拉松,只要你愿意做出改变,任何地方都可以是起点。

本文由 @吴天 原创发布于今日看点。未经许可,禁止转载
题图来自Unsplash,基于CC0协议

赞(0) 打赏

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

免费做网站(蜜蜂中文站)

网站地图联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏