相信每个做PM的小伙伴都多多少少从不同人口中听过这句话，“这个功能有啥用啊”“这个产品有啥用啊”（如果没有听过那说明你真的很幸运！）。
其实这个问题本质上就是对方表达了对产品的不认同，算是产品经理职场沟通中的常见场景了，在争取各种资源以及和各个业务方串讲的过程中，免不了会有不同的想法和判断。
所以本篇想理性讨论下，如果遇到这种问题应该怎么办，除了沮丧的情绪，还能干点啥让情况不更糟而是更好，会从以下几个方面展开，具体见脑图。
（点开可查看大图）
如果你也遇到过类似的情况，那就继续往下看吧～
如何优雅应对“这个功能没啥用”
所以优雅应对的第一步，是稳定自己的情绪。
学会处理批评和否定，这些在产品经理的工作中都太正常了。产品作为一个低门槛工作，人人都可以是产品经理，每个人都可以judge。
虽然UED也是半个产品经理，但是UED说美没人敢说不美，你能说你的审美比设计更好嘛？
但是产品经理说这个对用户有价值，任何一个人都可以说，我是用户我觉得这个没价值，你还没法反驳。
所以从我们选择做这份工作，就意味着可能要克服很多阻力去推进一些我们想坚持的正确的事，而且是想尽办法克服一切阻力，只要事成了，中间的过程，受不受委屈，有多少人否定，其实并不重要。（有一种“虽千万人吾往矣”的豪气）
虽然道理简单，但做起来并不那么容易。
我们可以慢慢尝试，第一次第二次可以归咎于生疏，让情绪占上风，但第三次第四次的时候，就要学着有意识的控制自己的情绪了。
牢记一件事情，“你可以否定我的需求，甚至可以否定我，但不能砍我需求”，只要不砍我需求，爱说啥说啥，I don’t care。
牢记我们的初心是，克服万难，推动需求上线。
（图源网络，侵删）
另一个面对“被否定”的常见误区是，急着去解释和获得肯定。
我之前常常犯的一个错误是，如果有人在需求串讲的时候，对某个小细节提出一些质疑，我就会很着急的去说服他。
从我是怎么调研，怎么分析数据，怎么得出结论，为什么这么考虑说起，结果是打乱了整个串讲的沟通节奏。
人家可能只是一个小疑问，并不构成阻塞性意见，但我太急于说服对方，太急于让所有人都认可，在需求评审的时候花费大量时间去获得单个人的认可，导致时间把控不到位，真正该细讲的内容讲的不够充分，耽误了会议的效率，消耗了其他参会者的信任。
这类问题其实可以说“会上时间有限，这个细节一会会后我们单独沟通，我先继续往下讲”。
稳定情绪之后，可以开始理性解题了。
被“他”否定真的很重要吗
但正式解题之前，还有一个比解题更重要的事情，就是评估重要性和影响范围。
就好像解bug一样，不是所有bug都一定要修复，如果影响范围仅限于老版本，且复现步骤及其复杂，只影响到极少部分用户，就不一定要花时间去解决，可能性价比极低。
-1️⃣重要性。
这个人有没有对这个需求的一票否决权，虽然有点现实，但是确实要学会抓关键角色，比如你老板，老板的老板，研发老板，这些重要的角色的认可是一定要获取的。
对于研发，也要尽可能获得研发1号位的认同，如果是从他们口中提出的否定，一定要极度重视，并且进一步去沟通他们为啥不认可，不认可整个需求还是不认可部分细节。
除了一号位，还有一些影响力比较大的关键角色，也需要关注他们的评价。
比如我之前在推送里夸过的一个研发哥哥，虽然并不是研发leader，但他的靠谱程度有目共睹，产品都相信他开发的需求质量一定高，研发都相信他写的代码一定结实。
所以，从他口中提出的质疑，一定要谨慎对待和回答，避免导致大范围的不信任。
如果识别不是关键角色，那就看情况了。
我们要意识到其他人不是产品经理，没有你那么全的信息，咱们也不可能在需求评审把所有的背景讲的那么清楚。
退一步，即使讲清楚了，也有可能由于他们本身不是这个需求的目标群体，无法对我们的目标用户共情，所以认为没用。
再退一步，即使他们能共情，也有可能单纯就是喜欢嘴炮，热衷于否定别人（当然不是说要恶意的揣测别人，只是说什么情况都有可能，我们要理性面对被否定）
面对这种非关键角色，有精力的话可以去沟通，去获取更多认可。没精力的话，忽略就好，继续该干嘛干嘛。
-2️⃣影响范围
除了重要性，还需要识别一下影响范围。比如在需求评审等重要场合，公开的负向评论有可能影响到其他人对需求的看法和评价，不容无视，需要尽快解决。
不过，这不就和我刚刚提到的case有冲突了嘛，一下子说需求评审的时候不要急着说服别人，可以先安抚一下对方会后找他沟通，以免耽误时间，一下子又说需求评审上的负向评价要尽快解决。
这俩不是自相矛盾吗？
到底要不要当场解释清楚，我觉得在于当这个人说出自己的疑惑或者反对意见的时候，是不是获得了其他人的潜在认可。
如果当他表示了对某些细节的不认可从而diss你的需求的时候，很明显只代表他的个人意见。
在座没有其他人表示认可，大家也没有被他所带偏，那么不用花太多时间去急着解释，安抚对方情绪，建议会后沟通，然后接着讲就行了。
但如果当他发表完意见的时候，你发现在座挺多人都表示了认可，说明他们心里也有这些疑惑。
或者这个人比较有影响力，无形之中说服了大家，大家也开始趋向于认为这个需求还有待商榷，还有一些值得质疑的细品的点。
那这个就不再是单点问题了，需要及时的当场沟通清楚。否则大部分人都跑偏了，后续你讲的内容大家也听不进去了。
至于到底怎么辨别是不是大多数人都被对方说服了？
这个就需要考察产品经理的察言观色能力了，对方表达不认可的时候，底下其他人什么反应，有没有人在频频点头表示认可。
（所以再强调一次，这个时候不是陷入自我为中心，感受到被否定和自我崩塌的时候，聪明人在一边审时度势一边思考对策，根本没时间沉溺自我）
如何说服一个人
按照上面的评估方法，如果重要性低，影响范围小，那就该放放，多一事不如少一事。如果重要性高，影响范围大，那为了确保需求能上线，一定要想办法说服这个人。
那么问题来了，怎么有效说服一个人？
这个是最近在脱不花老师的《沟通训练营》中学到的，按照我自己的理解分享给大家。说服一个人的方法=自己说话有分量+击穿对方心理阈值。
1）自己说话有分量
其实这个大家生活中都能有体感，刚刚提到识别重要性的时候，就提到了两类人，领导和高影响力的人，他们说的话更有分量更值得重视。
反之亦然，如果你是领导或者人群中高影响力的人，你说话就更有分量，更容易说服别人。
当然这不是说领导说的话一定就是圣旨，但相对而言，职级也是某种程度上的能力象征，职级越高，能力一般越强，能力强的人说出的话大概率经过了深思熟虑，大家天然的信任感更强。
所以，我们如何让自己说话更有分量？
方案A：努力当领导（也是个思路，核心是努力提高自己能力，职级是一个体现）
方案B：努力做个高影响力的人。
我们主要讲讲B方案，当然，这里指的高影响力是正向的影响力，“代码杀手”“破坏王”“需求变更小能手”不算是我们现在提到的高影响力。
在和研发的沟通中，高影响力来自于靠谱。
在长期的合作中，作为产品经理，如何建立一个靠谱的形象，这个话题在之前的推送中已经提到过了，这里不再赘述，有兴趣的小伙伴戳“六月工作思考｜努力做一个靠谱的产品”）
不过，这些远水解不了近渴。
拿到具体的实战中，我手头的这个需求，要怎么样说服研发给我做呢。
关键我也不知道对方觉得我靠不靠谱，有多靠谱，或者说我就是第一次和这个研发沟通，以前和其他研发建立的影响力纽带根本不work。
那么，让本次沟通的说服力大大增强的秘诀就是强准备。
只要你准备足够充分，充分到别人想到的你也想到了，别人想不到的你也想到了，且都做好了充分的准备和考虑，就好像打辩论之前思考反方论点一样，知道对方要问什么，猜到对方怎么立论，才知道怎么反驳。
无论别人怎么问怎么盘都盘不倒你，击穿对方的心理防线。通过强准备来让对方感知到你是有备而来，而且充满信心。
那么问题来了，强准备可以准备些啥呢？
technically，准备你想得到的一切，多准备点总是没错的，因为你不知道哪个细节才能超出对方预期，让对方感知到你的强准备。
比如说面试场景，本身能力素质够硬是前提必备的，此外你可以提前了解这个公司，你可以提前在脉脉上查一下你的面试官名称，了解他的过去经历，去了解他之前做过的产品（当然，耍小聪明，了解对方喜好并且投其所好这种歪路子不鼓励），你可以在牛客网和各种地方查面试面经，看看自己是不是还有没准备到的地方。
再比如跨部门协作的时候，希望对方部门和你合作，那首先要知道对方要什么，对方部门的核心OKR是什么，我们的这次协作是否有机会协助对方完成他的O，进而帮助他们达成自己的KR，找到共同目标是完成协作说服对方的第一步。
此外，提供一个小技巧，能够大大增强说服对方的概率，这也是多次需求串讲实践得到的。这个技巧就是讲故事。
（真的超级好用的讲故事大法）
很多时候，开发不认可的原因在于，没有足够的同理心，很难代入我们所描述的场景，所以理解不了目标用户在该场景下的痛点，从而无法理解需求的价值。
为了帮助对方共情，可以通过举实际例子或者讲故事的方式，来帮助对方共情。
人天然就是喜欢听故事的，在故事中植入你想表达的观点，说服力会大大增强。
比如说，我之前提过一个需求，主要目的是打感知。
类似于你住酒店的时候，酒店会通过给卫生间的卫生纸折角来让你感受到“房间已经被精心打扫过了”，我提的就是一个类似于“给卫生纸折角”的需求，但是开发普遍觉得用户不需要这个，这个没什么用。
所以我在需求串讲的时候，面对这个问题，给开发讲了一个小故事。
故事的背景是，你暗恋的女孩有胃病，医生让她每天吃早餐。所以你开始每天早上偷偷往女神的桌子上放早餐，这的确是她最需要的东西，但是怎么让她感受到呢？
可以在某天不经意的时候假装落下你的小笔记本，笔记本上写着，周一早上要去护国寺小吃给女神买早饭，周二要准备小米粥和鸡蛋，周三要准备xxxx。让她不经意间发现，原来不是每个人桌子上都会长早饭，原来这些都是你精心准备的，原来你默默为她做了这么多。
而我们这次要做的需求就是，做一本小册子，让用户也能感知到，我们做了什么。
这个故事效果拔群！（也许大家都有过一个暗恋的故事吧hhh～），总之在大家的笑声中，疑问自然解散了，需求串讲也很成功。
（我大胆猜测，看完这篇一周后，大家可能不记得这篇讲了啥，但是记得有一个暗恋的故事🤦♀️）
2）击穿心理阈值
其实强准备已经是击穿心理阈值的方法之一了，但这里还有一个隐藏在大气层的说服技巧。
刚刚提到的方法，是说在需求串讲的现场被质疑或者否定了，怎么样去当场说服别人。但其实要求的难度还挺高的，要被质疑的那几秒钟判断是不是要立即解释，并且要想好怎么解释才不会越说越糟。
隐藏在大气层的说服技巧是，将风险前置，把说服这个过程战线拉长，并且分成单点去击破。
吹风指的是在正式的串讲或者沟通之前，先用各种方式把消息放出去，让对方大概听说这么个事，而不是完全陌生（大家对于完全陌生的信息可能会下意识的警惕甚至反对）。
而且越是大事，越要慢慢吹风。
真·吹风.jpg
吹风的实战技巧是其实和我老板学到的。
背景是下半年本来我们部门有个重点项目，项目还没正式立项之前，我老板就开始通过周会也好，各种正式非正式渠道也好，给我们的合作部门吹风，鼓吹这个事情的重要性和重视程度。
于是当我们真正开始落地实施的时候，老板层面基本都拉通了，而合作方也差不多都知道我们有这么个事儿。
真正业务上沟通的时候变得无比顺畅，不用花很多时间去说我们有这么个项目，然后有多重要。
大部分时候，大家都表示，行行行，不用多说了，我已经知道这事儿了，也知道有多重要，老板层面已经拉齐了需要高度配合，你直接说需要怎么配合就行。
吹风的重要性在此可见一斑！！！（呜呜呜我老板tql！要是能围观一下怎么吹的就好了
除此之外，脱不花老师还介绍了一个风险前置的说服小技巧，也是非常神奇！
这个技巧就是，道德绑架之化“敌”为友。
如果你已经可以预知到某些人可能会提出反对意见或者质疑，或者你拿不准某些关键角色是不是能认可你的方案，那就前置沟通而不是等需求串讲。
（既然他的意见这么重要那确实值得单独沟通，这也考验我们识别关键角色的能力，毕竟单独沟通是比较花时间的）
此外，你不一定非要他认同，而是充分考虑他的意见，并且按照他的有效意见进行修改，把他的建议充分融入你的方案。
这样串讲的时候，你可以说，“关于实现链路的部分，也非常感谢xx同学的宝贵建议，帮助我们规避了xx问题和风险”。
这样，对方就不会再坚持反对了。
毕竟，没有人会反对他自己。我们成功的化“敌”为友。
我在工作中真实碰到的案例是，我在跨部门沟通的时候，特别害怕一个研发，就是X哥。我非常认可他是一个超级靠谱的研发，因为他会抠细节抠的非常细，所以最终实现的时候会非常流畅。
但是这也意味着他对产品文档要求很高，如果产品文档有没有细化的逻辑和细节，在他眼里就是不及格考卷，就会毫不留情的diss。
比如“这个需求根本做不了，太多边界没有考虑到了”。
之前很多次被大哥在串讲现场diss，但是我太紧张了，完全没有get到他希望我细化哪个部分，哪一块逻辑。
所以参照这条技巧，这次项目串讲之前，我在自己尽量想的足够细的基础上，在正式串讲之前先单独和他前置沟通，并且诚心请教，“那，x哥你觉得还有哪些不完善的地方需要补充吗？”。
然后大哥给我提出了从代码实现层面还有哪些逻辑不完善，哪些场景和边界需要处理。最终在正式串讲之前按照他的意见进行了细化，串讲过程就变的很顺利了。
（内心窃喜！知识就是力量啊友友们！之前真的怕的要死，不知道本次串讲会不会被diss，甚至有点每次有X哥参与的串讲都紧张的开始磕磕巴巴的。）
最后，如果有些人就是死活没法被说服，但是又越不过去怎么办？
那就小火慢炖。
（图源网络，侵删）
虽然火很小，但只要持续时间足够长，一定能炖烂。
核心点在于在不把对方搞烦和惹怒的情况下，充分沟通，找到可以立足的共同目标，挖掘对方不同意的原因，慢慢优化和迭代，直到给出对方能接受的方案。
说服与被说服的自我反思
关于这个题，还有一个值得反思的点，我是一个难以被说服的人吗？
之所以反思这个题是因为，这周小伙伴西番哥给了我一个宝贵的意见，提到了一个词，叫做“温柔的压迫”。
之所以用这个词是因为，很多时候和我沟通时，虽然我没有黑脸，也没有很凶，虽然是一直是笑着说的，却是不容置疑的语气，不允许任何反对意见的那种，which means我其实自己也是一个难以被说服的人。
我在费尽心思考虑怎么说服其他人的时候，我自己也变成了一个不怎么好说服的人。
屠龙少年终成恶龙，我叭叭叭的吐槽别人难沟通，难被说服，结果我自己也没好到哪去。
这其实并不是一件好事，之前提到的开发X哥难沟通的背后，是对需求品质的把控，而且是能够通过不断完善需求去获得他的认可的。
而“温柔的压迫”的背后不是我的意志力多坚定，多不被花言巧语迷惑，是来自于我性格的两个方面：急躁和好胜。
比较急性子的性格导致我很多时候希望事情尽快如我预期一般推进，很多时候自己心里有了倾向的答案之后，只听自己认为重要的信息和自己认同的信息。
对于自己不认同的信息，倾向于直接打断不让人说完，然后把强行输出自己的观点，把自己的观点强加给别人。
（这种性格万一以后当领导了，那员工可太惨了😭😭。所以我得尽快改正，不要成为我自己讨厌的那种人。唉，管理能力是比产品能力更大更难的一门课）
好胜心强导致我不太能接受反对意见，和男朋友吵架的时候，虽然后边已经慢慢意识到自己错了，但还是不肯承认，而且试图找到对方的错，证明是两个人都有错。
和开发以及合作伙伴的沟通也有这个毛病，喜欢挑别人的错，逻辑漏洞也好，考虑不充分也好，反正想尽办法找错。
这种无法被说服，是不讲道理的那种拒绝沟通，长此以往，对我自己和对合作方都不好。
所以，非常感谢我亦师亦友的小伙伴西番❤️，先是大部分时候都先肯定我的方案，不直接反对或者否定（不然的话我肯定是听不进去）。
然后慢慢吹风，指出我可能的一些问题，陪我一起优化方案。
最后用“温柔的压迫”这个词完美总结和点出了我的问题所在但又顾及了我的面子，让我能够心平气和的接受问题并且意识到问题所在～沟通技巧和段位高太多了，神仙同事🐂🍺～
今天的推送就是这些啦。主要是以需求评审的常见场景——“这个需求没啥用”入手，介绍了怎么应对这种场景并且提高自己的说服技巧，也反思了自己在沟通过程中的常见问题。希望对小伙伴们的职场沟通会有一丢丢帮助。
推荐阅读
更文不易，你点击“在看”的样子真的很美👇
