产品经理与产品经理讨论问题的情况是非常频繁的，大家会出现就某个功能或交互有不同的看法，然后会出现互相争论的情况。这里有几种情况是要尽量杜绝的。
一是不要为了说服别人支持自己的观点就拿着竞品或者某个很优秀的产品的对应功能对着其他产品经理说，「你看，这个产品也是这么做的」，那么这个产品的其他的功能点我们为什么不也去模仿呢。往往很多情况，为了说服别人支持这个观点就找相仿的一个应用来说事，下次为了说明另外一个观点发现之前那个应用做的跟自己的不一样就赶紧再找个跟自己做的功能相仿的应用来说事。
二是不要「我觉得」，虽然有很多文章和书籍都说了，做产品不要为自己设计，要让自己一秒变成小白用户，可是很多人都是很难做到的，很容易就把自己的经历代入场景。这样出现的问题是一个产品经理说「我觉得我会A，我就是这样的」，另外一个产品经理说「我觉得我会B，我就是这样的」，如果是这样讨论问题，没得聊了。最好的方法是拿数据说话，拿用户反馈说话（这也需要批判性去看待）。
三是不要拿极端情况试图推翻别人的方案。这其实是逻辑学上的一个非逻辑思维，要不得。你几乎在每个方案中都能找到问题，但这不代表别人的方案不好，为了说明别人的方案不好最好的方法是自己也拿出个方案来，不要瞎争论。其实个人觉得最好的方法是拿场景说话，看一个方案能否尽可能覆盖目标用户的场景。
一是交互没有深刻理解为什么做这个功能，当交互不了解时就会出现交互稿的偏差，这需要产品经理多沟通，不然产品以为交互都知道了，结果在讨论交互时都不在一个点上，会出现很多无意义的争论。
产品经理会对交互稿提出很多不一样的想法，认为交互应该是这样的。我觉得如果产品经理不太懂交互设计，尽量让交互设计师自己决定，专业的人做专业的事。如果想跟交互讨论细节，最好自己也很懂交互设计（不然是在浪费别人时间），而且我认为交互设计也是产品经理的一项基本功。
其实与工程师发生对某个功能的争论的情况是很少的，产品经理要做的事情就是告诉开发目前这个功能出现了什么问题，改善方案是什么样的，解决之后对产品有什么好处，优先级有多高，让开发有动力去做，就OK了。
运营人员会从他们的角度提出一些产品需求，当他们把大致的方案想好后就会来找产品经理讨论细节。这其中需要产品经理认真分析需求，不要来个需求就接，要了解清楚事情的前后经过，然后再评估。
比如运营拿个方案过来说要做这个东西，产品经理就得判断做这件事情是为了解决什么问题，目标是什么，大概会需要多久的开发时间。还比如，运营要求自己负责的某个功能的入口能大一点，这要考虑整个页面的布局情况和判断它的重要性。最后，把这些思考的过程和结论告诉运营，达成一致的想法，相信合作起来也会顺畅很多。
与各种人撕，你才有收获，有不同意见，你才能全面思考。
学会撕逼，走向成功第一步。
与老板撕，讲数据
应该有很多产品经理最怵的就是和老板讨论需求，往往觉得老板的需求不靠谱，但是又不好直接反驳。但是把老板的需求直接放到产品中，又影响用户体验。
其实是我们对老板的需求心态不对，作为产品经理，任何都都可以向你提需求，不管对与不对，都应该保持开放的心态接纳，特别是老板的需求，因为他是最希望产品成功的人，他提出的需求多么的不靠谱，也是为了产品好，因为你和老板看问题的角度不同，发现的问题和得出的结论会不同。
老板的思维都偏宏观，看问题喜欢看数据，那么和老板讨论需求，先不要急于否定老板，拿到老板的需求，先换位思考一下，是否合理，然后再站在你专业的角度来看，是否合理，然后去搜集数据，通过数据来证明需求是否合理。
与设计撕，将场景
和设计师的沟通是产品经理最容易犯错的地方，因为“人人都可以是设计师”（怎么感觉和人人都是产品经理一个状况啊），人人都有自己的美感，产品经理最容易犯的错就是以个人的美感去评判设计师的作品。
首先产品经理该如何和设计师沟通需求，当然是将场景，产品经理一定要想用户使用场景描述清楚，将清楚用户场景，然后就是讲清楚目的是为了什么？讲清楚你要解决的问题，不要带着解决方案和设计师沟通，要把设计的主导权交给设计师。
设计师完成设计以后，产品经理要做的只是评判是否满足了自己的目的，解决了自己的问题，符合用户使用情景，而不要主观的判断美感。
与程序员撕，讲逻辑
程序员是团队中最辛苦的一批人，他们也是最容易沟通的人。只要你能讲道理，说服他们。
程序员很在意他们开发出来的产品有价值，他们不愿意开发出来的东西没有用户用。所以当产品经理提出的需求不合理不靠谱时，程序员就会从内心抵制，那么他们的效率就会低，积极性就不高。
产品经理在和程序员沟通需求是，首先能够讲清楚需求的业务逻辑，需求必须具体和明确的，而且是可以实现的，不能天马星空。并能讲清楚需求的价值在什么地方。
与运营撕，讲方案
产品经理和运营是命运共同体，荣辱与共，但是往往矛盾重重，运营与用户接触最多，收到的用户反馈也就越多。所以运营经常会给产品经理提一堆的需求，产品经理也需要从运营得到用户的需求，但是产品经理又不理解运营讲的什么。这其实是产品经理和运营思维方式的不同，产品经理的思维更偏向逻辑性和严谨性。而运营人员更注重的是灵活性和商业性。
当提出来需求时，要多和运营沟通，了解需求的背景，不要和运营争论和否认。先拿出解决方案和数据与运营人员后，再一起讨论。
只有撕，才有碰撞，才有进步。
为什么要撕逼？
1.逻辑不清
问题还没想清楚就画原型，找设计，找开发，被人问住了还不承认，死鸭子嘴硬；
嘴笨，自己知道但说不清楚，被人一刺激就上火；
喜欢鸡蛋里挑骨头，以偏概全，为了撕逼而撕逼
老板的毛病，曾经有个同事说之前的公司老板最喜欢拉着一大帮人开会讨论，然后就开撕了
2.喜欢在自己并不熟悉的领域瞎指挥，瞎比比
不与技术商量，任性估算工时且没有优先级
老找设计的毛病，但就是说不上了所以然来
3.自己没想法，唯老板是从
老板说做什么就做什么，老板说什么时候完成就什么时候完成，功能需求三天两头改，问的时候还理直气壮的说老板要求的，久而久之，所有人都对你敬而远之，没什么问题也给你找事撕逼，最后，连老板也开始嫌弃你了
我们是为了工作，平心理性的交流，换位思考，相信绝大多数人还是能正常交流。。。
首先产品经理是需要对产品的整个过程负责和监督的。那么产品经理就需要了解产品从需求调研开始到产品上线整个过程的一系列工作。
第一，产品经理要清楚这个产品的需求和做产品的目的，不能轻易随着设计师、开发工程师等人员的意见来改变产品的功能和一些交互设计。
第二，不要在设计师、开发工程师和测试工程师面前大幅度的讨论他们岗位的工作，这样不仅限制了他们的想法还会让他们觉得你在藐视他的工作。在他的地盘动手动脚，不会觉得你牛逼，只会觉得你傻逼。
第三，要懂得设计、开发、测试等相关知识，这样才能更好地跟设计师、开发工程师和测试工程师沟通和表达产品的功能设计和功能效果。
一、撕之前先搞清楚为什么撕？
能避免撕逼的时候，当然不要浪费力气，一篇文档就能搞定的话，去撕逼岂不是浪费力气，还浪费水资源。如果是开发有意见，感觉需求不合理，或者不清楚，那么撕一撕还可以，如果撕到最好，发现啥也没撕出来，或者撕的根本就没意义，那么撕的岂不是很失败。
二、不同对象不同撕法
不同的对象，不同对待，所谓知己知彼，百战不殆。开发、运营、测试的关注点不一样，好吧，还有驱动和硬件。
开发：我要怎么做呢，要花多久，做起来会不会很操蛋，很费劲，给我预留了多长时间给我做，做完之后会不会被砍掉。这个需求看起来很不靠谱，我不想做怎么办？
运营：这个需求做出来之后会不会提高下载、留存，为什么不先做我的需求，我们的需求来自用户呀用户，给我们做需求才能看到钱知道不？你这需求是什么鬼？你做了万一用户一不爽把APP卸载了怎么办。
测试：你这个功能上了，版本不稳定怎么办？我们要封板，封板知道不？这个需求之前上个版本明明不是这样的，为什么不一样了?而且，我们还要改用例。
老大：还要人？要人？知道人力成本都高不？这个需求做出来，能带来多少用户？有数据么？成本和收益是不是对等？要花多少人？边际成本怎么样？我刚提的需求，怎么不先给我做？不靠谱？你说哪不靠谱？
三、有理有据的撕
1、要数据，好吧，网上的二手数据，调研数据，友盟等数据，分分钟用数据摔你一脸。数据是很好的佐证，即使没有直接的数据，也可以通过间接的数据导出想要的结果，
2、有可以拿的出的东西摔对方一脸。有文档、有PPT、有竞品分析，看我多认真，撕逼的时候分分钟摔你一脸。准备充分，没有功劳也有苦劳，尤其是在老大面前撕的时候，好吧，我要匿名，我曾经写了20多页的方案，从7种不同的角度告诉老大，他的需求有点不靠谱。
3、不怕撕，气势不能弱，尤其是感觉自己有理的时候，如果你自己摇摆不定，那别人怎么有理由听你的，要自信，但不是自负，如果突然发现撕的人说的是你想到的，确实是对的，那一定要去听。不要撕一撕就死要面子了，最后闹得大家都不好看，而且之后你再照样做出修改，打脸会更厉害的。关键时候，要里子就行了。
第一，把自己的逻辑想清楚，自己想不清楚，开撕的时候更容易被别人干到哑火。
第二，把自己的产品方案讲清楚，我认识的很多人都是头头是道的说了一大堆，到头来仔细想想其实什么也没说。所以头脑一定要清晰，123分别是什么说的清楚明白逻辑正确，才能更好的说服别人
第三，虚心接受别人的意见，可以这么说：你说的很对，我已经把你的建议写在备忘录，下个版本就加上！ 顺利结束撕逼~~~！
请RD哥哥吃饭。让他亏欠于你。
言归正传，哪里来的『撕逼』，『撕逼』何时起成了一种风气？无非来源于PM一次次的逻辑漏洞，需求改了又改，对用户本质需求和隐含需求无法把控等长期形成的不信任。
真要撕逼，那就表示有争论，大家也都不是傻子，不可能针对1+1=2这种问题来撕逼吧？有撕逼，那就表示确实在别人看来，你的某些思路确实有不足或者他不赞同的地方。何必过于执着于己？先听别人的，再决定撕还是不撕岂不更好。
所以，打铁还得自身硬，自己先把产品捋清楚，尽可能细致的想到最优的解决方案。当你的方案确实是经过多方论证就是最优时，别人拿你已经玩过的思路跟你撕，一切都会迎刃而解，因为他和你不在一个起跑线上。这样，你还会怕撕逼吗？
当然以上只是大部分情况，人无完人，我们确实无法完美的考虑到每一个细节。在这种时候，遇到别人提出新的问题，提出新的解决方案，可能我们会觉得手足无措。这时，我们就需要调整心态了。如开始所说，不要忙着瞎比比，先听听别人的，然后再对比自己的。这既是心性的养成，也是知识的拓展，难道不是吗？我们应该更开心才对。因为，无论结果如何，我们都成长了。至于最终的方案选择，何必纠结于谁的成败？你真以为产品经理，也就是你，所说的都是对的？
我们要做的仅仅是让正确的事情持续发生，而不是自以为正确的事情持续发展。
—————谨此献给那些还在苦闷于撕逼的你————
以上所述，仅属个人观点，与公司、行业、党国无关。
可以分两方面来看待这个问题：
1.如何判断分歧的双方中，哪一方给出的解决方案更优？这个是判断力问题
2.如果确定我方给出的方案更优，如何说服对方来接受？
稍微主观点儿的评估，如果问这个问题，很有可能代表了题主在问题1上稍微有点单薄。
我在职业初期的时候，也觉得太多的人不懂，但最终会发现，是我不懂他们。每一个事物都是一个多面体，太多数的分歧在于不同的人看到了事物的不同面。财务要控制预算，运营要快速新颖，技术要轻盈高效，设计要精益求精：
基于自己的利益/视角来考虑一件事是一个非常自然、非常本能的行为，这是不应该被指责的，也不应该是“他的方案”需要被打败的原因。
关键是：他的提议是否有助于达成项目的目标
要赚钱就基于赚钱来考虑，要做流量就基于流量来考虑，要做口碑就基于口碑来考虑。
无论老板怎么要求，无论客户怎么反馈，无论同事怎么评价，那里一定有一个优先级，也一定会有在这个阶段最优先要达成的目标。而你需要明白这个目标是什么。
哪种选择对这个目标更有利，就用哪个。
然后才有了基于选择之后的说服与被说服，而这个过程，我反而认为相对简单：
先把对方拉到跟你同一个纬度上。如果这个都很困难，那就不要浪费时间了，直接升级。
通过与上层的沟通来修正你对于优先级目标的判断，不断反复。
经过一段时间之内，团队内部自然会认可你对于资源的安排能力，之后过程中就会多了解释，少了分歧，你也就逐渐解脱了。
很抱歉，我个人很讨厌“撕”这字。如果有同事有这方面的想法的话，我会第一时间避而之，以免负能量太大。
工作中经常出现这种需要被题主认为需要“撕”的场面，其实是产品费劲千辛万苦得不到他们想要的资源和支持。特别是在一般的大公司，存在开发制度不健全、人员分工不明确、人员流动快、工作交接不彻底等等企业通病。那么如何去解决这种问题呢？
重点就是你想要的具体是什么？
这里面涉及到产品新功能为什么需要做？具体做什么？需要哪部分支持？达成什么目的？
①为什么要做，就涉及到竞品分析、产品现状数据，用数据说话；这一部分是需要对团队研发人员说明，他们很多情况下不想做“无用”工，而非不做，需要有充分的理由让他们信服。当然在做的时候他们更多的是用最小的成本解决现阶段问题，但是产品有责任和义务指出，如果这样做，后期会有什么样的问题，最好邮件回复，以免后期再做这部分功能的迭代的时候让研发感觉产品这边缺乏思考。
②具体做什么？这部分需要准备一下PRD，建议PRD也不要太繁琐，将重点集中在做什么上，其实大家都知道那部分都不会怎么去看。如果没有PRD，其实也是ok的，只是每次都需要口头交流，是一件很浪费时间和经历的事情.
③在这里设计到需要那部分支持?特别是跨线协作的时候。需要做好充足的准备的同事，不懂就是不懂，虚心请教，制定方案。不能想当然的去做设计方案，不然会被别得产品笑话，甚至会将研发带到坑里面起不来；
④达成什么目的？这个其实和为什么要做这个功能类似，但是达成什么目的带有KPI，做完之后如何校验，需要给参与这个项目的人员一个反馈，方便下一阶段的迭代升级。
我不是一个想和别人撕的人，也不善于和别人撕，产品尽可能的以理服人，多多沟通交流。没有谁应该听谁的，除非后者是一个对结果不关注且情商很低的人，我想谁都不愿意成为那样的人吧？
当然在找资源的时候会存在诸多审批流程，这时候该走的还是要走的，看公司情况而定
这个问题提的很凶悍啊，下次可以描述里写上，“在线等，挺急的”
言归正传，撕逼首先得知道为啥撕，一般也就那么几个事儿“这个做不了”“为什么又要改”“这样也挺好”，咱一个一个说
“这个做不了”，先在市面上找一款有类似功能的产品，解析一下，看是如何实现的；如果市面上没有就找一个第三方的开发哥，了解下自己产品当前的架构是否可以完成这个功能，撕逼时告诉对方具体的实现方式，数据生成，处理，储存，展示几个流程逻辑讲清楚就好，让他给出排期
“为什么又要改”，千万别说领导让改的，虽然会很简单，但是很憋屈，再提需求变更之前一定要有非改不可的理由，比如这个需求不实现会影响xx重要功能，这个需求做了可以让xx需求数据提高xx，然后改需求这件事本身不是光彩的事儿，去撕逼时最好带一瓶可乐或者红牛，看时机塞到开发哥哥的手里。
“这样也挺好”，开发们的想象力是无穷的，一定要适时的限制下，当做出一个跟预期不一样的需求，一定要让他改回来，这时候拿出文档和曾经的往来邮件，一字一句告诉他“这个跟我的预期不符，请按prd来”，当然有时候你的prd像屎一样，真的没写清楚，就一定要想好怎么应对了，最好将这个需求跟后续的优化策略绑定在一起，如果不改，下次需求就要大改，只能这样，然后切记，以后prd一定要写清楚啊~
以上
这个撕逼功能真的要双修，对外要说服别人，对内要说服领导，不管什么行业来说，都有一种领导总是问你为什么要这样，拿出数据来，还有一种同事，我就是没错，你们都错了，说服领导还能从数据出发，说服那种全世界都错了就我没错，反正数据是公司的，我就干成这样了，要改你改，我坚决不改，卧槽，谁能告诉我这种同事怎么好好地撕逼？！
被撕-怕撕-能撕-多撕-耐撕-享受，是一个痛苦的过程，需要一个强大的敌人，或者一群强大的敌人。同时，也是自我能力、知识、口才等能力提升的过程。能不能抓到敌人的弱点撕，怎么撕，被撕后怎么反撕，如何优雅的撕逼都是一门学问。
与程序猿的斗争
说斗争其实不太合适，产品狗和程序猿的对立自从互联网出现以来就从来没有消失过。由于程序猿一般不接触老板，所以对产品的理解仅仅限于和产品经理的沟通。产品经理该需求，要么是老板让改，要么是觉得自己设计的不好还需要改进，但是当时已经按错的做了，只能要求程序猿从新去做，这就使矛盾激增源远流长。
产品要理清
这个算是对全体产品经理的一个希望与要求，自己的产品是不是真的经过了足够的思考，是不是构成了自己的闭环，是不是排查了所有的边界。
据我了解产品和开发的矛盾容易出现的两个地方（排除老板该需求因素）第一个就是产品经理自己没有想清楚，需求一再变化不定。这个一般会出现在新手之中，因为他们本身经验不足，对产品的把握也不好，很容易在自己没有完全想好的时候，就与开发沟通，当然这个在大公司里一般不会存在，新手要被老人带，而且制度也会对产品经理有一定约束。第二个就是，边界问题。对特殊情况的处理没有考虑清楚。特别是一些非技术的产品经理，会有一些问题无法想到而导致了措手不及的状态。这些问题其实都是由于产品经理经验不足，缺乏对相关事务的把控。所以，各位产品经理在需求评审之前，千万要将产品想的很透彻，几轮评审，专家走查之后应该得到是一个比较完整闭环的产品体系交付开发。
开发有情怀
作为开发的同学可以来看看这里，其实产品经理是一群苦逼的人，需求没有提明确确实是他们的问题，不过如果是业务型的产品经理在不懂技术的前提下，是很难把所有的问题都给出明确的解释和处理。所以这就需要开发与产品不断的沟通磨合，毕竟大家都不容易，相互尊重对方的专业度。在这一点上，最能体现出开发的情怀。
产品经理间的斗争
往往一个产品不可能只有一个产品经理，不同产品经理之间有意见不统一往往也会存在一场斗争。这种斗争比前两个发生的更频繁更直接！一个产品每个人都有自己的看法，不管是为了面子，为了威信，还是为了更高的追求，产品经理也一定会坚持自己的观点。
解决这个问题有2个方法：
第一，就是靠产品总监了，一个有能力有作为的产品总监在调节此类问题应该是家常便饭。
第二，就是用小流量做AB测试，谁设计的好用数据说话。
大公司靠第二种方法，小公司靠第一种。
正常撕我理解为是讲道理，这种撕早就习惯了而且上面说得很好PM一定要自己先想清楚，不要自己都站不住脚就被人给灭了，这个不合格。
然而当撕逼占据了绝大部分工作时间简直无处不在的时候，应该想的不是提高撕逼能力
而是公司团队可能成员素质匹配程度差异较大、工作流程不清、分工定位不明确
想清楚功能的出发点，还有开发、运营各个环节的衔接，逻辑清晰，做起来会受到大家的尊重的。有时候要学会拒绝需求，比如来自运营提的需求，运营的工作灵活、多变，但他们往往不擅长评估开发成本，希望技术来帮忙解决问题。比如来自老板的需求，要弄清楚来龙去脉，再设计功能流程。
联系客服
