产品经理需求沟通的艺术

产品经理常常须要与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在经历过许多产品开发经验后，终于明了到前辈说的「态度柔软，但立场坚决」…等的「对立」思考逻辑，仍是不如「站在同一边」的思考逻辑。小当心得与你们共享之，但愿你们也能够多花点时间在「产品故事」的叙述上。

原文：需求溝通的藝術