产品经理需求沟通的艺术

产品经理经常需要与RD进行需求沟通，有个很有名的幽默漫画是这样画的。

产品的需求，经由产品经理定义成产品规格后，开始找RD讨论。而一切的错，也就从客户（或Product Manager）口中的需求开始。

PM：「我们要发展一种在无重力状态下也可以使用的多功能原子笔，也就是说墨水不会因处在无重力下就无法送达笔尖。」

RD：「这个想法做不到。因为OOXX，所以XXOO」

PM：「可是之前看日本技术展的时候，他们有展示不受重力影响的液体封装技术。你们要不要研究研究，这么快就说做不到，会不会太草率？」

RD心理在干：「你到底有没有听懂我讲话啊？就不可行啊！讲不听。就说产品经理每次都在外面看到什么新玩意，就自己High了起来。明明是外行又要装内行，专门想出一些怪东西来整我们！」

PM又说：「客户说他们对这种产品有很大的需求，这个订单对我们公司很重要。」PM开始拿客户需求这个神主牌来压。

PM心里也干：「这些RD超没干劲，每次开需求给他们，他们东闪西躲，就是不想做事情，老是说做不到，明明就有人做的到。RD都欺负PM在开发知识上不如RD。可恶！」

上面的需求沟通，到底出了什么问题？

曾经有人教过Mr PM，跟RD沟通，要「态度柔软，但立场坚定」，或是「要怀疑RD说的每一个做不到，要常常找出别人做得到的证据，逼RD就范」 。 PM和RD的关系，就在这些经验传承之下，越来越紧张，不是你压倒我，就是我每次都反驳你。

问题的症结点在哪里？在于产品经理没有好好叙述产品的故事。

什么叫做产品的故事？就是把产品的从头到尾的使用过程，如同小说般的叙述出来，至少要包含下面几个范畴。

• 产品在哪一种情境之下被使用？
• 在什么场合被使用？
• 被哪一个人使用？
• 为了达到什么目的？
• 使用方式？
• 达成什么效用？
• 使用频率多高？
• 其他背景因素，诸如：个性、天气、月份…等。

最好的话，还可以画出使用情境图来（工业设计上经常这样使用），笔者建议每个产品经理甚至可画出「真人照片连环漫画」来当作需求沟通的工具。

产品经理若没有先叙述产品故事，而直接开产品规格请RD评估，就会闹出「要RD做出可在无重力状态下使用的原子笔」的笑话。若是产品经理可以事先说明「太空人因为有时候要做实验抄数据，来不及输入到电脑，所以需要暂时写在纸上」的产品故事，那RD面对所谓的奇怪产品规格时，就很容易跳脱「无重力状态下用的原子笔」的解决方案陷阱，进而能根据真正的需求，进行方案的构思。而想出不需要用原子笔，只需要用铅笔的聪明解决方案。

而面对喜欢直接开规格的产品经理，RD在面对一些难以实作的规格时，应该也要学会问「这个规格背后真正的需求是什么？」，这个问题可以去刺激那些不爱说明产品故事的PM，把难以实作的规格背后的真正需求说清楚。有时候是因为PM自己的知识有限，然后又赶着要将产品kick off，所以就直接开了规格（越有经验的PM越常做这种事）。殊不知，若是PM能把真正的需求讲清楚，其实RD手头上还有更棒的解决方案或能达到相同目标的替代方案可用。

有时候问题不在于对方很机车不配合，而在于你思考模式出了问题。

千万记住，别把别人的答案当作真正的问题。就「做出可在无重力状态下使用的原子笔」的例子来说，就是PM把「外太空书写」这个问题，先行找出解答是「无重力下可输写的原子笔」，然后再把解答当作问题来问RD。一般人非常容易犯这个毛病，请大家多多注意。

把产品故事叙述清楚的好处还不只如此。回到最上头关于秋千的幽默漫画，团队成员因为都了解最源头的产品故事是什么，所以在讯息层层传递与转译的过程当中（需求规格->技术规格->系统分析->实际写code ），每个人都有了基本依据，而减少认知上的错误，降低产生误解的机率。

产品故事甚至可以激励团队成员，因为他们知道，自己做出来的是个什么样的产品，甚至可以大家都可以贡献一些idea，把这个产品弄得更好，毕竟大家都希望自己做的产品能够大卖，这样自己的考绩也会打得好一些。而且在大家都贡献了自己idea以后，就会更觉得这个产品与自己紧密相关，进而更愿意付出心力在开发产品上。

最后要提醒的一点是，其实对PM来说，要跟每个相关的人都讲一次产品故事，其实还挺累人的。笔者也常想偷懒直接跟某些比较不核心的成员，直接从最后的结论切入，而不去铺陈告诉他们产品原始的故事。其实后来证明，跟每个成员都不厌其烦的讲产品故事是有必要的，所以，PM们，别偷懒噜。

Mr PM在经历过许多产品开发经验后，终于明了到前辈说的「态度柔软，但立场坚定」…等的「对立」思考逻辑，还是不如「站在同一边」的思考逻辑。小小心得与大家共享之，希望大家也可以多花点时间在「产品故事」的叙述上。

原文：需求溝通的藝術