本文作者從自身工作實踐出發，和大家討論了PM每天都會經歷的兩個話題：產品經理為何會撕逼？產品經理如何撕逼？

一、產品經理為何會撕逼？

首先，面對這樣的問題，用了次級分析的方法，網上搜了一下，出現了很多相關的文章：產品經理如何正確撕逼，產品經理如何撕逼，產品經理如何撕逼最有效，產品經理日常撕逼絕招，產品經理如何正確撕逼，如何提高產品經理撕逼能力，新產品經理如何漂亮撕逼…各大站點各種文字，似乎都非常有道理，閱讀人數10萬+的也不在少數。

然而，似乎為何會撕逼的這個問題并沒有被廣泛討論？

本人從業有些時間，大大小小也經歷了不少場撕逼，多數是被動的，極少極少主動的開炮。從我的視角來看主要有這么幾個原因：

1. 認知不同

不同人對問題的認知會存在偏差，人都是一個個獨立的個體，尤其互聯網企業，一次團建桌上坐的可以來自五湖四海，都找不到一個老鄉的，這樣的團隊和構成，大家的認知絕對不會相同。不同年紀的人，認知問題也會不同，人生的三大境界，看山是山，看水是水；看山不是山，看水不是水，看山還是山，看水還是水；不同境界人看問題的方式角度都會不同，在一個地方開會討論，能完全認知一樣么？答案顯而易見。不同地域也是一個原因，地域結構不同，文化不同，原生家庭不同，祖傳的各種習慣不通，也會導致各種認知差異。正是這么多的差異，導致在看問題的過程，結果，對人對事的各種差異。

2. 角色不同

每個人在公司都是被角色化的，或者你在團隊里面也都是擔負一個角色的成員，不同角色的人會承擔不同的責任，背負不同的KPI，有時候對方撕你，不是因為他看不上你，而是他的角色就是會這么思考。當然有時候他就是看不上，就是想懟人了，我們另當別論。

產品負責設計，開發負責實現，這種已經確定了基本的對立關系，也存在一定的相愛相殺。測試是守門員，安全第一，必須保證質量，不能放過一個不穩定的因素去到線上。面對不同的出發點，大家思考角度不同。每個項目的負責人肯定關注的自己的項目，每個PO關心自己的資源，每個業務運營關心自己的指標和項目，為了自己的指標，業績開撕都是非常正常的。而產品經理日常工作的必須做的事情就是“一碗水端平”。實在端不平，那也只能一口一口喝了。

3. 目標不同

長掛在嘴邊的一句話，大家的目的是一致的，都是為了把事情做好。實際上也真的是如此的，至少在一定的高度下，在大方向上是如此的。但是落實到了細節，每個人，每個項目的目標真的一致么？是否有量化的ROI去確定目標，有些公司有，有些沒有，有些有ROI也無法追溯和量化，有些業務是看感覺的，定性分析的判斷結果，結果感性的認識與上了理性的分析，土八路遇上正規軍……

有的同學是為了好好工作，有些同學是為了混日子，有些同學是為了挑戰自己，有些憑著責任性和工作操守工作。每個人的目標不完全一致，每個團隊的訴求也不完全一樣，產品在設計的時候，面對不同的用戶需求，最重要的就是挖掘不同的受眾群體的真實需求，探尋本質的能力，也基本確定了一個產品經理的底層能力。如果目標不完全一致的話，對設計的要求就會更加高。有時候不得不ABtest或者幾個方案拍一個做決策。這種情況下，能不撕么！

4. 規則不同

說一個現象，現在都說敏捷，排期，版本，小步迭代，這些在軟件體系演化這么多年的變遷中，已經被非常廣泛的運營了。但是這些都是保護研發的，不是對產品的，一個版本下來，研發的工作是按照點數來估計的，前端5個點，后端3個點，總時間看一看還有多少個點，可松可緊。但是產品不是，如果一個一直在打仗的團隊，或者是業務驅動的團隊，產品的可交付工作量基本都是非常彈性的，松的時候可以無所事事，緊張的時候可以天天加班，“白天開會，晚上寫文檔”這樣的日子太正常不過了。沒了保護傘，所以收到的壓力也會更加大。

還會有很多其他的不一樣，這些差異性導致了在一個需求評審會，或一次次溝通中，往往把產品經理推向了風口浪尖，在一門門重炮之下，習得一身賴以生存的18般武藝，不斷耐撕，不斷皮實。

對年輕的產品經理的勸解：趁著自己能撕逼的時候，就多去撕一撕，等年紀大了，有時候就有太多的顧忌和規則限定，想撕逼都不行了。

二、如何撕逼？

這個話題，似乎就等同于，鄰居家的老李偷了我家的狗，我去和那廝理會一下的意思。至于方法，文的還是武的，先禮還是先兵，先攻還是先守，沒有定論，也沒有答案。一個口若懸河的老兵，被人一招破了武功；一個天天被人“欺負”的小丫頭片子，冷不防絕地反擊一下，滲人的很，也是常有。勝敗是我家常事，不用太過較真。若想多勝少敗，這里也有幾個招，不妨看上一看。

第一招，講道理

關鍵詞：理

這是最基本的招式，也是最難的，80%以上會用到，用的好的，可以不用看下面的方法，當然一般能處理的非常好的，也不會來看本文了，基本上夠應付各路江湖好漢了；

講道理，就是正兒八經的說道理，說通大家，不屑于用技巧的或者對技巧還不是非常熟練的，或者非常熟練的老手，也是肯定要用講道理的，畢竟基礎招式，在一次武林大會上出現的戲份不會少?？梢愿嗟膮⒖籍a品PRD的規范，需求的背景，正確的邏輯推理和解答方式，得出一定的解答，來概述每個產品設計的功能，方案，策劃的目的，技巧。

對于剛剛入門的小伙伴來說，不建議開始就玩技巧，200份PRD之后再玩不遲；基本功要扎實，本文后面提到的方法，也是要給予基本功而定的，所以的目的都是在對事情的正確分析上，得出的有理有據的方案。所以對行業的認知，對產品領域的認知，對軟件行業的認知，對整體體系文化的認知，加上自己的各種十八班武藝，可以得到一個自己的知識體系，解決工作中95%的方案輸出，基本都是在用這一招。

第二招，拖字訣

關鍵詞：拖

為了掌控節奏，按照固定的Roadmap輸出和推進產品的迭代，為了控制團隊的研發節奏，避免代碼沖突，為了需求老不急做，研發來不及做，產品來不及輸出，有些沒有意義的需求不拖上一拖實在對不起團隊。諸如此類，種種場景都會遇到一個字，你需要“拖”。它不一定是不好的，雖然給人感覺是貶義的。但是拖的好，運用的好，也是對團隊的一種保護。對最后結果有正向的作用。有這么幾個辦法：

1. 這個我們已經在思考了，之后就會排期操作；
2. 研發已經在思考了，給出排期之后我們就操作；
3. 還有幾個大項目，我們先做完大項目，再做這個；
4. 已讀不回；
5. 有一個前提條件，等滿足了我們再來做；

特別說明：不要對合理的需求使用，他們就該被正確的對待；

第三招，太極推手

關鍵詞：推

“這個已經不歸我管了”，“這個你找陳某”，“這個需要幾個部門配合”。很多時候，當一個團隊主動或者被動的使用推字訣的時候，要不這個事情不歸他管，要不就是他確實不想做。

小公司基本沒什么好推的，大公司會存在著這樣的問題，很多時候繞一圈，又繞回來了，找了一群人，發現沒一個人管這事的。這種大公司病大家都不喜歡，都不解決問題，但是它存在于現在的環境下。

特別說明：在團隊內部可以立下flag，不允許推給自己人，leader以身作則；

第四招，避免硬杠

關鍵詞：避

評審會上，小產品會遇到幾個詞：“你這個需求不合理”，“這個設計不能滿足我們”，“具體哪里我也說不上，反正就是不合理”…怎么整？！

一般一個正式的評審會，出席的人很多，小的也有7-9個人，在這種場景下，很多不能直接溝通的，或者存在一定的爭執的，都會被放大。所以，我們把線上的溝通提前放在線下，確認好幾個細節，方案過一遍，會上只是走個形式，過一下。也有缺點，增加了溝通成本，但是卻是有效的，可以讓PM對方案的細節溝通的更加清楚，反復確認業務需求，互相補位，保證產研體系效率更高。

第五招，借力打力

關鍵詞：借

誰說只能是“壞人”狐假虎威，電視里面每個出來的壞人都很得瑟，話多，最后死狀慘烈。但是這些招式如果被好人用來，即使沒有主角光環，產品經理也可以輕松推進自己的工作，省去不少溝通的成本。至于是否假傳圣紙，看每個人的道行，風險系數也很高，遇到的機會不太多，高階招式后續我們再議。

借力不只是向上接力，還可以借同伴的力，借中間人的力，借外部的力，總之能實現打擊的都可以用上。

第六招，大廠這么干的

關鍵詞：flag

聽的非常多的一句話，也已經耳熟能詳了，我們XX以前就是這么做的。其實非常有道理，就是大廠已經給大家梳理起了一個標桿了，很多做法都是可以借鑒的。我們不鼓勵抄，要抄也要抄到精華。很多已經被大家采用的做法，不論是B端的還是C端的，已經教育了市場，采用一下的效果也是非常好的。所以，可以直接丟一個flag過去，這樣，開會的時候也可以省去各種口舌。

當然，在一些中型企業，或者有大廠牛人存在的團隊，這樣的做法不一定有效?？梢哉乙恍└蟮膹S^_^，更大腕！看誰腿粗誰腰細。

第七招，扔數字

關鍵詞：數字

用數字說話往往都是非常有效的一種做法。實在無法說服大家的時候，AB吧，用數字說話，哪個方案最后效果好，在一定的環境下，用數字說話。使用的時候特別注意一下，數字可能會說謊！操作的人需要公正嚴明。

第八找，忍

關鍵字：忍

萬般無奈之下，也只能忍了。重要的是，同時做好心理調節，佛系一點，不與SB輪長短。道理和招數都用過了，但是依舊不行，說明不在一個維度上。同時，多考慮是否存在其他的原因，比如是老板的要求，比如是歷史故事的影響。凡事必定有因可探尋，沒有因果的一般比較少。

最后總結一下

產品經理為什么會撕逼，主要是認知問題，角色問題，目標問題，規則問題導致的；產品撕逼基本招式有：講道理，拖字訣，太極推手，借力打力，大廠flag，扔數字，忍。還有其他招式，以后也會和大家繼續探尋。

最后，對手不是死靶子，放在那里讓你打。技巧和招式有很多，但是也需記得活學活用，隨機應變。死招式遇到活人，還看誰的功夫深。

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

本文由 @二師兄 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。