当你的产品内测时，这时候程序员看着那个功能或者交互很不爽，开始各种吐槽，紧接着一群程序员开始吐槽，有多不爽，有多鸡肋，有多麽。。。。balabala。。你该怎么办？（@CSQ000）
夏阳回答：
我只从产品的角度来回答，虽然我只是一个民间红娘而已，同时感谢@JR 同学提供和收集的问题。
JR收集的技术反馈问题主要有3个：
1、当前没时间开发；
2、这个东西，特别是已经迭代过几次的产品，其框架和技术选型其实已经制约了某功能的实现（不是做不了，而是做出来满足不了客户的需求）；
3、该技术人员目前还没掌握此需求所需的技术积淀。
回答：
1、如果排期确实都排满了，就看优先级呗，毕竟人家人手有限，或者假装人手有限，你也不能强迫他，只能从优先级上着手，不然人家就一副“我不是不想做，我做不过来，谁让你不早点提需求”的欠揍表情。
2、满不满足用户（客户）的需求，产品有很大的发言权，如果开发同学跟你说功能没用，那你就用到你最根本的沟通能力来给他讲解需求，如果连他都说服不了，你能说服投资人么？创业就更不用想了。不用多，你有两次这种成功的说服，就会让他们佩服你。
如果是功能被底层制约了，那你要先验证需求的可行性，如果确实要做，就分步骤来，先解决有无，然后再丰富。阿里巴巴这么多年也重构了几次底层了。做与不做就看这个东西值不值得做，而值不值得，很大程度上取决于你的水平。
有时候不要因为这个不允许，那个不保证的，丢掉了用户的需求和契机。好多产品往往就是愿意做你不愿意做的事情，居然就成功了。
3、开发同学没掌握技能和技术沉淀，那你跟他说，别人都能做，你为啥不能做，那你还在我面前BIBI个机⑧，好好承认你不行，回去虚心学习去，别没事在我这人五人六的聊国际先进技术，聊谷歌苹果脸谱网的，好像乔布斯老大，你老二，结果老大还死了。
然后果断回头权衡是用别的功能来代替采用曲线救国的方式（举例，用户找车位难，不一定非要弄停车场，弄个拼车有时候也能解决问题，要把需求的祖宗十八代都挖出来），还是马上做技术储备，让这些小朋友长大了再来。
补充一点：
好多开发无非是不想做某个功能，觉得麻烦，或者自认为功能没用，作为产品经理，你要反问他，你觉得哪个功能有用，如果只做这几个功能，产品还有人用么；还用你这个如此高端凌厉的开发工程师来做么，随便找个大学生一样可以做基础功能。
当然，如果你一肚子道理，就是不能说服，那说明你基本的沟通能力还是有问题，别再说自己是个称职的产品。调动积极性和触发人性共振点，是你必须要做的。别忘了，好多开发工程师入职的时候，都信心满满，心比天高，愿意做很多有意思的好玩的功能，好像苹果没找他都瞎了眼了。但是时间长了，他们就疲惫了，开始当工人了，多余的东西或者有挑战的东西一点不愿意做。这个是要改变他们，要变相画饼激励（做好价值观传递，让他们知道自己做的东西很牛逼，军功章有他们很大的功劳）。
说的有点多了，这么多年，我的开发都在背后骂我，面前从不骂，也算是死猪不怕开水烫了！
回答者简介：夏阳 ，互联网产品从业者 / 民间红娘，山城红娘公益相亲平台创始人，御弟哥哥快餐连锁品牌创始人，嘿快轨道WiFi 产品负责人。
vivigoose回答：
说到产品经理和程序猿，无法摆脱的就是“撕逼”这个词，公说公有理，婆说婆有据，每个角色出发点不同，站在的角度不一样，思考的方式不一致，都是引起撕逼的导火索。这种现象是无法避免的，但是可以缓解和降低撕逼的气焰。我觉得遇到这种情况的处理方式有以下几点——我给他简称‘三步走’：
1、第一步： 产品经理在整个产品生命周期中是统筹，协调的，因而首要任务是稳定程序猿们的情绪，并组织他们展开圆桌会议，耐心倾听程序猿的意见和建议，并在白板或者白纸上记录程序猿的建议和意见。——倾听永远比争执来的更有效，而且也体现了对彼此之间的尊重。盲目的争执只会激化撕逼和争执，只会影响彼此之间的合作度、配合度。严重的话，会导致程序猿和产品经理之间的隔阂，会误认为每次我的想法建议都是被排斥或者不接纳，恶性循环后影响整个产品的研发。
2、 第二步：当场对程序猿的想法进行一个表决， 看程序猿们赞同建议的票选率如何，根据票选率来进行第三步的流程——采取公投的方式产生的结果可以让程序猿信服：这是你们认为需要、想要改进的地方，你们很公正的票选出来的决定，而不是作为产品经理的我强制压给你们的想法和建议。
3、 第三步：表决阶段会有两种情况产生：
情况1：当程序猿绝大多数赞同一个建议的时候，那么PM可以在保留原版数据的基础上，按照程序猿的想法进行一个可行性的大胆操作，检验是否出来的成果会更加合适。这时可以邀请一部分用户或者群体来进行体验，用以检验更改后的方案效果如何。假如效果合理可以采用新思路。如果无法很好的收的成效，产品经理和程序猿需要一起开分析其不合理或者不适合的原因，研究探讨下是什么问题导致的这个情况的发生，然后再继续探讨可行性方案——比如在程序猿现在这个建议上优化或者调整，是否原方案更好等问题。
情况2：如果意见不均衡，可以选出两个赞成呼声最高的想法，进行A/B方案的操作，此时也是需要小规模体验团队来检验其成果，根据其结果进行两方间的对比，以及和原方案之间的对比，三者用淘汰制的形式来择优入选。
通过实践和用户体验的成果来作为有力的证据，这样才能让产品经理和程序猿都信服。毕竟产品最后面向的是所谓的目标群体，而目标群体的体验是最有力的证明。这样就能缓和撕逼的现象，也能让程序猿更愿意发表自己的看法和建议。即便他们的想法忽略了站在用户的角度，但可以帮助他们日后友好的和产品经理撕逼而不是掀桌子的那种。
回答者简介：林夏薇，被小伙伴亲切称呼为-小鹅，14年底漂流回来的海龟派。并以vivigoose的名称混迹在PMCAFF产品经理社区里学习和交流心得看法。
网友评论