【产品日思录】vol007.你的需求被质疑了怎么办

图片发自简书App

你的需求被质疑了怎么办？今天的问题主要考察面试者在进行需求评审时的沟通能力，尤其面向开发人员的沟通能力以及抗压能力。

其实这种现象很常见，产品经理绞尽脑汁想出的功能，自以为流程顺畅、体验极致、用户跪求、业界领先，但一到开发那里通常会被喷得体无完肤：“这需求是你的还是用户想要的，需求有什么价值？别的产品我看都没有这个功能，为什么我们要做？不要看别人做了，我们也要做，你觉得这么合理吗？……”这种情况下，处理是否得当，就能体现出产品经理的能力来。

对于答案，建议不要回答的太简单，太笼统，反面例子如下。

这种情况我会多和大家沟通，说清楚为什么要做这个功能，努力说服大家。

（如何说清楚怎么沟通，大家不能被舒服怎么办？这些都没说清楚）

我会求助领导，让我的领导和开发领导去沟通。

（这是个办法，但这体现不出你的能力。）

我会重新想想我的需求是不是合理，如果不合理就改。

（如何判断是否和你开发说的就不合理嘛，如果你觉得和你开发觉得不合理，那又怎么办呢？还是没解决？）

OK，那接下来比较好的答案是什么呢？我叫大家一个六字真言。

有价值，可实现。

展开来说。首先是有价值。

价值这个词，说通俗点就是让开发觉得这个需求没白做，要么是用户爱用，要么是能挣钱，要么是能达到公司目标，再进一步有大量的用户爱用，能挣到很多钱，能迅速达成目标就更有说服力了。说学术一点就是这个需求要有用户价值，商业价值，公司价值。当然在描述时空口无凭，建议尽可能的数据举证，可以是历史数据估算，也可以是销售额数据，可以是竞品类似功能使用情况，可以使用户反馈数据，总有一款适合你。

再说可实现。

什么是可实现呢，并不是指能不能做，对开发而言，没有做不了，只有做的好不好。这里有两个大前提，第一个是产品逻辑合理可达，一是实现方案高质高效。满足这两个前提开发是不会挑毛病的。对于前提一，产品只要能把流程梳理完备，符合MECE原则，无关键遗漏即可；但对于前提二，则是比较考验产品的经验和技术功底，很多功能逻辑上没有问题，但技术上却很难高效地实现。举个例子，需求是：要求每个用户单独统计未读推送消息数，但由于每个用户的消息单独存储，每次统计都要遍历所有用户的所有消息判断状态，性能消耗极大。如果没有更好的方案，开发是不愿意这么做的，除非你能找到别人做过同样的功能，因此这种情况就只能做出权衡，砍需求。实际在回答这个问题时，建议说到这一步，单纯说“开发说不好实现就砍需求”是不行的。

其实说回来，大部分企业，尤其是大公司开发都是很好说话的，而且实力很强，所以实际工作中遇到被挑战，被质疑的情况不多，但有效沟通，努力推进合理需求的实现是产品经理的必备技能。

作者：第六夫人
链接：https://www.jianshu.com/p/7d6c7ed41bd9