本文作者从自身工作实践出发，和大家讨论了PM每天都会经历的两个话题：产品经理为何会撕逼？产品经理如何撕逼？

一、产品经理为何会撕逼？

首先，面对这样的问题，用了次级分析的方法，网上搜了一下，出现了很多相关的文章：产品经理如何正确撕逼，产品经理如何撕逼，产品经理如何撕逼最有效，产品经理日常撕逼绝招，产品经理如何正确撕逼，如何提高产品经理撕逼能力，新产品经理如何漂亮撕逼…各大站点各种文字，似乎都非常有道理，阅读人数10万+的也不在少数。

然而，似乎为何会撕逼的这个问题并没有被广泛讨论？

本人从业有些时间，大大小小也经历了不少场撕逼，多数是被动的，极少极少主动的开炮。从我的视角来看主要有这么几个原因：

1. 认知不同

不同人对问题的认知会存在偏差，人都是一个个独立的个体，尤其互联网企业，一次团建桌上坐的可以来自五湖四海，都找不到一个老乡的，这样的团队和构成，大家的认知绝对不会相同。不同年纪的人，认知问题也会不同，人生的三大境界，看山是山，看水是水；看山不是山，看水不是水，看山还是山，看水还是水；不同境界人看问题的方式角度都会不同，在一个地方开会讨论，能完全认知一样么？答案显而易见。不同地域也是一个原因，地域结构不同，文化不同，原生家庭不同，祖传的各种习惯不通，也会导致各种认知差异。正是这么多的差异，导致在看问题的过程，结果，对人对事的各种差异。

2. 角色不同

每个人在公司都是被角色化的，或者你在团队里面也都是担负一个角色的成员，不同角色的人会承担不同的责任，背负不同的KPI，有时候对方撕你，不是因为他看不上你，而是他的角色就是会这么思考。当然有时候他就是看不上，就是想怼人了，我们另当别论。

产品负责设计，开发负责实现，这种已经确定了基本的对立关系，也存在一定的相爱相杀。测试是守门员，安全第一，必须保证质量，不能放过一个不稳定的因素去到线上。面对不同的出发点，大家思考角度不同。每个项目的负责人肯定关注的自己的项目，每个PO关心自己的资源，每个业务运营关心自己的指标和项目，为了自己的指标，业绩开撕都是非常正常的。而产品经理日常工作的必须做的事情就是“一碗水端平”。实在端不平，那也只能一口一口喝了。

3. 目标不同

长挂在嘴边的一句话，大家的目的是一致的，都是为了把事情做好。实际上也真的是如此的，至少在一定的高度下，在大方向上是如此的。但是落实到了细节，每个人，每个项目的目标真的一致么？是否有量化的ROI去确定目标，有些公司有，有些没有，有些有ROI也无法追溯和量化，有些业务是看感觉的，定性分析的判断结果，结果感性的认识与上了理性的分析，土八路遇上正规军……

有的同学是为了好好工作，有些同学是为了混日子，有些同学是为了挑战自己，有些凭着责任性和工作操守工作。每个人的目标不完全一致，每个团队的诉求也不完全一样，产品在设计的时候，面对不同的用户需求，最重要的就是挖掘不同的受众群体的真实需求，探寻本质的能力，也基本确定了一个产品经理的底层能力。如果目标不完全一致的话，对设计的要求就会更加高。有时候不得不ABtest或者几个方案拍一个做决策。这种情况下，能不撕么！

4. 规则不同

说一个现象，现在都说敏捷，排期，版本，小步迭代，这些在软件体系演化这么多年的变迁中，已经被非常广泛的运营了。但是这些都是保护研发的，不是对产品的，一个版本下来，研发的工作是按照点数来估计的，前端5个点，后端3个点，总时间看一看还有多少个点，可松可紧。但是产品不是，如果一个一直在打仗的团队，或者是业务驱动的团队，产品的可交付工作量基本都是非常弹性的，松的时候可以无所事事，紧张的时候可以天天加班，“白天开会，晚上写文档”这样的日子太正常不过了。没了保护伞，所以收到的压力也会更加大。

还会有很多其他的不一样，这些差异性导致了在一个需求评审会，或一次次沟通中，往往把产品经理推向了风口浪尖，在一门门重炮之下，习得一身赖以生存的18般武艺，不断耐撕，不断皮实。

对年轻的产品经理的劝解：趁着自己能撕逼的时候，就多去撕一撕，等年纪大了，有时候就有太多的顾忌和规则限定，想撕逼都不行了。

二、如何撕逼？

这个话题，似乎就等同于，邻居家的老李偷了我家的狗，我去和那厮理会一下的意思。至于方法，文的还是武的，先礼还是先兵，先攻还是先守，没有定论，也没有答案。一个口若悬河的老兵，被人一招破了武功；一个天天被人“欺负”的小丫头片子，冷不防绝地反击一下，渗人的很，也是常有。胜败是我家常事，不用太过较真。若想多胜少败，这里也有几个招，不妨看上一看。

第一招，讲道理

关键词：理

这是最基本的招式，也是最难的，80%以上会用到，用的好的，可以不用看下面的方法，当然一般能处理的非常好的，也不会来看本文了，基本上够应付各路江湖好汉了；

讲道理，就是正儿八经的说道理，说通大家，不屑于用技巧的或者对技巧还不是非常熟练的，或者非常熟练的老手，也是肯定要用讲道理的，毕竟基础招式，在一次武林大会上出现的戏份不会少。可以更多的参考产品PRD的规范，需求的背景，正确的逻辑推理和解答方式，得出一定的解答，来概述每个产品设计的功能，方案，策划的目的，技巧。

对于刚刚入门的小伙伴来说，不建议开始就玩技巧，200份PRD之后再玩不迟；基本功要扎实，本文后面提到的方法，也是要给予基本功而定的，所以的目的都是在对事情的正确分析上，得出的有理有据的方案。所以对行业的认知，对产品领域的认知，对软件行业的认知，对整体体系文化的认知，加上自己的各种十八班武艺，可以得到一个自己的知识体系，解决工作中95%的方案输出，基本都是在用这一招。

第二招，拖字诀

关键词：拖

为了掌控节奏，按照固定的Roadmap输出和推进产品的迭代，为了控制团队的研发节奏，避免代码冲突，为了需求老不急做，研发来不及做，产品来不及输出，有些没有意义的需求不拖上一拖实在对不起团队。诸如此类，种种场景都会遇到一个字，你需要“拖”。它不一定是不好的，虽然给人感觉是贬义的。但是拖的好，运用的好，也是对团队的一种保护。对最后结果有正向的作用。有这么几个办法：

1. 这个我们已经在思考了，之后就会排期操作；
2. 研发已经在思考了，给出排期之后我们就操作；
3. 还有几个大项目，我们先做完大项目，再做这个；
4. 已读不回；
5. 有一个前提条件，等满足了我们再来做；

特别说明：不要对合理的需求使用，他们就该被正确的对待；

第三招，太极推手

关键词：推

“这个已经不归我管了”，“这个你找陈某”，“这个需要几个部门配合”。很多时候，当一个团队主动或者被动的使用推字诀的时候，要不这个事情不归他管，要不就是他确实不想做。

小公司基本没什么好推的，大公司会存在着这样的问题，很多时候绕一圈，又绕回来了，找了一群人，发现没一个人管这事的。这种大公司病大家都不喜欢，都不解决问题，但是它存在于现在的环境下。

特别说明：在团队内部可以立下flag，不允许推给自己人，leader以身作则；

第四招，避免硬杠

关键词：避

评审会上，小产品会遇到几个词：“你这个需求不合理”，“这个设计不能满足我们”，“具体哪里我也说不上，反正就是不合理”…怎么整？！

一般一个正式的评审会，出席的人很多，小的也有7-9个人，在这种场景下，很多不能直接沟通的，或者存在一定的争执的，都会被放大。所以，我们把线上的沟通提前放在线下，确认好几个细节，方案过一遍，会上只是走个形式，过一下。也有缺点，增加了沟通成本，但是却是有效的，可以让PM对方案的细节沟通的更加清楚，反复确认业务需求，互相补位，保证产研体系效率更高。

第五招，借力打力

关键词：借

谁说只能是“坏人”狐假虎威，电视里面每个出来的坏人都很得瑟，话多，最后死状惨烈。但是这些招式如果被好人用来，即使没有主角光环，产品经理也可以轻松推进自己的工作，省去不少沟通的成本。至于是否假传圣纸，看每个人的道行，风险系数也很高，遇到的机会不太多，高阶招式后续我们再议。

借力不只是向上接力，还可以借同伴的力，借中间人的力，借外部的力，总之能实现打击的都可以用上。

第六招，大厂这么干的

关键词：flag

听的非常多的一句话，也已经耳熟能详了，我们XX以前就是这么做的。其实非常有道理，就是大厂已经给大家梳理起了一个标杆了，很多做法都是可以借鉴的。我们不鼓励抄，要抄也要抄到精华。很多已经被大家采用的做法，不论是B端的还是C端的，已经教育了市场，采用一下的效果也是非常好的。所以，可以直接丢一个flag过去，这样，开会的时候也可以省去各种口舌。

当然，在一些中型企业，或者有大厂牛人存在的团队，这样的做法不一定有效。可以找一些更大的厂^_^，更大腕！看谁腿粗谁腰细。

第七招，扔数字

关键词：数字

用数字说话往往都是非常有效的一种做法。实在无法说服大家的时候，AB吧，用数字说话，哪个方案最后效果好，在一定的环境下，用数字说话。使用的时候特别注意一下，数字可能会说谎！操作的人需要公正严明。

第八找，忍

关键字：忍

万般无奈之下，也只能忍了。重要的是，同时做好心理调节，佛系一点，不与SB轮长短。道理和招数都用过了，但是依旧不行，说明不在一个维度上。同时，多考虑是否存在其他的原因，比如是老板的要求，比如是历史故事的影响。凡事必定有因可探寻，没有因果的一般比较少。

最后总结一下

产品经理为什么会撕逼，主要是认知问题，角色问题，目标问题，规则问题导致的；产品撕逼基本招式有：讲道理，拖字诀，太极推手，借力打力，大厂flag，扔数字，忍。还有其他招式，以后也会和大家继续探寻。

最后，对手不是死靶子，放在那里让你打。技巧和招式有很多，但是也需记得活学活用，随机应变。死招式遇到活人，还看谁的功夫深。

另有一篇高阶的方法，一共4招，技巧更高一些，后续推出。

本文由 @二师兄 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。