編輯導語：群思陷阱指的是群體中出現的這樣一種現象：群體成員追求“和諧一致”的愿望導致了一個非理性的決策；本文作者分享了關于產品開發過程中遇到的“群思陷阱”的分析，我們一起來了解一下。

“群思陷阱”極易產生不惜一切代價達成一致的傾向，每個人以團體的立場為自己的立場，不同意見被隱藏起來，或者被置之不理，因而群體表現出高度一致。為了和諧一致，人們甚至忘了群體本來的目標。

在日常工作生活乃至新聞上，“群思陷阱”都以不同的展現形式出現過：大學里，很多人都是以寢室為單位，成群結隊的活動，當室友都開始賴床、逃課、熬夜時，自己也極易被影響，一方面躺平生活總是充滿著巨大的誘惑，另一方面高度追求和諧團隊氛圍、不孤僻也是大部分人所；因此寧愿浪費時間也不愿意提出進步的訴求，最終只會導致團隊內的所有人虛度光陰。

而在回顧大量集體犯罪的案件中，當團隊成員在犯案時，往往會因為某一“意見領袖”的臨時起意而放棄自身的道德與底線，做出違背法律甚至殘忍至極的事情；其本質不僅有領導人行事專斷，滿足一己私欲的因素在，很大程度也因為成員生怕案后受到團隊的疏遠，最終成為案件升級的助推器。

而在產品開發過程中，也經常因為各種原因導致整個團隊都陷入了群思陷阱中難以自拔。有些團隊里，領導人行事專斷，自以為是，往往要求團隊根據自己的喜好開發內容，導致產品上線后數據一塌糊涂；有些團隊各成員之間溝通少，交流不暢，甚至存在個體孤立狀態，做完才發現每個人的理解都不同，呈現的效果也南轅北轍；甚至有的團隊里因不注重個體的自由表達，導致研發人員習慣性低頭寫代碼，不考慮產品的實際效用，如此惡性循環……

作為產品人，不論是掌握統籌大權的產品總監乃至CEO，還是略顯工具人的“產品助理”，在開發過程中，都需要學會并引導團隊其他人一同逃離“群思陷阱”，避免偏離產品目標。

一、追求和諧的團隊氛圍時，也需要注重個體的表達自由，鼓勵創新

不可否認團隊內和諧氛圍的重要性，如果產品和開發同學經常相互爭吵、指責、質疑，會給團隊內部造成極大的溝通成本、無意義的資源與時間的浪費，最終的產出物質量也可見一斑。但我們在追求團隊內友好氛圍時，也需要積極的表達，甚至可以是激烈的討論。產品可以對開發的實現方式、響應速度、架構擴展性發表自己的建議；開發也可以針對產品功能的目的性、價值性、交互方案表達自己的想法。

曾經在一個產品版本中，關于文件重名時的判斷與交互方式，我在產品設計中制定了若重名則展示提醒確認的二次彈窗，交由用戶選擇更名保存、替換上傳的操作；但在開發過程中，客戶端研發提出是否可以通過系統自動添加數字后綴的方式上傳文件，一來可以同時滿足分頁/不分頁的效果，二來也可以相應減少運行壓力。

雖然在用戶體驗方面，我仍然認為產品不應該直接給用戶做決定，尤其是在遇到問題時，更應該告知用戶并提供相應的解決方案；但經過雙方的溝通以及征求產品總監的意見想法后，最終決定在第一期通過簡單的添加數字后綴解決重名問題，并在上線后根據實際用戶使用的文件數量與可承載的數量對比確定是否合適增加重名判斷提醒功能。

最終雙方都獲得了各自滿意的答案與解決方案，各自表達了不同視角的合理觀點，團隊氛圍也并沒有往惡性發展。

二、防止所有個人拍腦袋的決定，學會“say No”

我一直認為，CEO、產品、研發乃至運營在本質上思維都是可以互通的，并不會因為職位的高低和職位的不同產生極其巨大的差異。只要是人類就會犯錯，只要是人類，他的思想認知就會有偏差有局限，因此，當作為產品，接受到拍腦袋的奇怪決定時，需要學會用于拒絕，用自己的三寸不爛之舌與數據事實防止生產出奇怪的產品功能。

我剛進入企業協同領域時，對于純B端產品的認知度還很低，加之公司產品實際仍為初創，很多理念、想法都還僅限于一些簡單的個人認知基礎和競品的處理方案，因此對于自己的一些產品邏輯其實并沒有太大的自信。曾經因為沒有把握自己的判斷一定是正確的，也不愿在大家面前暴露自己的“無知”和“固執”，未能表達自己的真實想法，壓制自己的良心和理智，釀成大錯。

在一次內部溝通會中，運營提出有不少個人用戶也想通過協同產品來完成與外部聯系人的溝通的現狀，希望產品可以增加個人版已獲得用戶增長。因此我在版本設計中新增了注冊時的用戶類型選項區分個人版與企業版（類似于WPS的個人版與企業版的區分）。

但在產品內部評審會時，老板提出更改選擇為默認創建個人版，若需要注冊企業版可通過個人版升級實現，理由是產品還在初期，即便是企業想要使用也會先通過試用的方式體驗，個人版即可滿足相應需求。作為新人的我在表達了個人觀點后并未能改變想法，最終硬著頭皮改了方案。

結果，版本上線后，運營開始接收到各種用戶對于登錄注冊流程的吐槽，想要體驗的企業負責人也因為默認注冊的個人版沒有企業人員管理相關功能而不再深入了解產品，導致了大量的新用戶流失。從這個版本后，我才真正明白了所有功能點都需要經過仔細推敲與數據支撐，純粹拍腦袋的獨立專行的決定都是作為產品經理所應該避免而杜絕的。

三、增加團隊內的溝通，提高團隊內部的價值輸出

在產研團隊，不同的崗位承擔著不同的責任也面對著不同的“世界”，作為接觸用戶、市場第一線的產品，所掌握到的信息往往要明顯多于開發組的同事們，也就造成了有時候產品為了實現用戶需求而引發了開發們的一致炮轟與質疑，其深層原因還是開發對于產品功能的價值點的不清晰與未來方向規劃的迷茫性，此時的產品經理需要在版本開發過程中持續的進行價值的灌輸，不僅能讓研發人員放心，也能激發人的積極性。

我負責的一款會議室管理系統是公司協同產品中的一條重要的獨立分支，主要服務于企業內部的會議室管控與改善的解決方案。

在項目成立初期，我便在評審會上首先做了產品線前景說明，大概介紹了目標客戶、已有客戶、潛在客戶的相應內容，并大致介紹了產品的商業目標，獲得了極好的反饋；在后續產品開發過程中，團隊內的不少成員根據自身已有的經驗與理解提供了大量的優秀建議并成功落地；而在開發過程中，每當獲得一份新的合作合同乃至意向時，我也會在產品線的項目群內發布公告，每次公告發布我都能看到群內成員的活躍度與積極性有了明顯的提高，最終的產品落地效果也比其他項目高出一大截。

防止出現成員之間的信息交流不暢，避免個體處于孤立狀態是作為產品負責人需要實現的，不論是小公司的傾其所有進入開發還是大廠的球爹求媽式地申請資源，只有大家獲得有效的信息以及一致的目標時，產品開發才更有利于步入正軌，超額完成。

四、不甩鍋，敢擔責

除了前文說的不想成為另類、害怕表現出無知外，沒有人愿意承擔責任，不想為此負責也是團隊陷入群思陷阱的原因之一。我們常說產品需要有主人翁精神，除了對產品有個人認同感、積極主動性，也要勇于承擔責任。責任不僅包括自身的調研問題、產品設計缺陷，也包括開發方案、開發進度、對外宣傳效用等。

“甩鍋”一詞其實經常可以在產品與研發中體現，雙方經常因為一些原因各自甩鍋，產品說是開發沒有理解需求、技術能力弱；研發反駁是產品設計缺陷、邏輯混亂。

我個人認為不論是什么原因，產品首先得承擔起責任，不造鍋也不甩鍋，必要時接起別人的鍋，只有這樣團隊內部才能有更正向的發展，產品經理自身也可以獲得更好的成長。

相信甩鍋的案例大家都有過很深的親身體會，在此就不再舉例。

最近在自己的產品開發過程中陸陸續續遇到了不少問題，因此特別想寫一些跟思維、團隊、項目相關的內容，分享的同時也希望自己和大家都能夠引以為戒，做到更好！

本文由@碌碌無為的阿栓 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議