經驗分享 | 關于產品經理的十個坑

編輯導語：產品經理是一個項目的主要推進者，在一個項目中起到很大的作用，也是團隊的管理者以及推動者；產品經理需要有強大的專業素質，并且有著較準確的判斷能力，以及不斷積累的經驗；本文作者分享了關于產品經理在日常工作中可能會遇到的坑，我們一起來了解一下。

不知不覺在產品這條職業道路上已經走了近三年，雖然常聽說人人都是產品經理，似乎是個人都可以做產品設計，但從自身的工作實踐來看，現實并非如此。

產品經理所需要具備的一些專業素質不可忽視，目前在正規高等教育體系中尚且沒有相應的專業設置，大部分從業者都是在工作中慢慢積累和自我領悟。

一、缺乏業務建模能力

產品經理常常需要接受不同角色的人提出需求，但受限于專業和認知水平各有差異，他們也許不能對需求本質的表述一步到位。

面對這樣的情況，就需要產品經理具備良好的業務建模能力，通過業務建模完成業務邏輯閉環，并思考和挖掘業務中潛在的需求風險和阻塞點，在思維上與業務方達成認知共識，確認需求方案。

在業務建模過程中，我常常借助的工具是流程圖和思維導圖，這兩種工具并不需要每次都使用，要視具體情況而定。

若在構建全新的項目需求時，我會先使用流程圖構建業務的主體流程和分支流程；然后使用思維導圖構建整個項目的主體框架（一二或三級結構）。

若面對的是一個系統中的部分模塊需求時，大概率只需使用思維導圖或流程圖二選一就足夠，通常我會選擇流程圖更多一些。

當面對的是影響范圍較小的小需求時，則不需要輔助工具，只需自己在大腦思考明白，可以給人表述清楚意思即可。

業務建模的過程其實就是產品經理深度思考和梳理需求的過程，這個過程尤其重要。理論上應該占據需求處理周期80%的時間，剩下20%的時間用于需求原型和文檔的輸出；流程圖和思維導圖是產品經理對業務建模的直接產物；文檔和原型是產品經理處理需求的結果產物。

二、思維缺乏邏輯性

作為產品經理，在日常工作中一項重要內容是與人溝通，比如對外有老板、運營、銷售、財務、采購、客服、人事、客戶等，對內有后臺開發、前端開發、測試、設計、運維同事等，他們都可能跟你所負責的產品有關聯性。

不同角色崗位的人，對相同的一個問題的思考和認知可能都各不相同，存在主觀片面性。只有產品經理最可能是對產品認知最完整，理解最透徹的人，產品經理通常被認為擁有產品的最專業解釋權；產品經理如果做不到這一點，可以說是不合格的。

當其他人對產品有疑問時，會優先向產品經理尋求解答，這就要求產品經理在解讀產品時，必須要做到思維有邏輯性，表達要清晰，讓聽者跟得上思維，理解產品經理所解釋的每一個產品邏輯。

產品經理在處理每一個需求時，理應遵從哲學上的靈魂三問原則：從哪里來？要做什么？到哪里去？

這三個拷問其實代表著一個需求的完整邏輯鏈條，從業務上看，意思是一個需求要看它背景是什么，要完成哪些業務操作，最終實現什么業務目標；從產品上看，意思是一個功能要知道它每一個字段來源于哪一個數據表，要操作哪些系統功能，最終得到什么數據結果。

當產品經理基于靈魂三問原則處理需求時，便可以非常簡潔明了地表述明白需求的來龍去脈，使聽者快速理解相關產品邏輯。

三、原型、文檔描述不全面

在處理需求的過程中，產品經理有兩樣最常見的工作產物-需求原型、需求文檔。一些新入行的人，常常會錯誤地理解這些工作產物的本質意義。需求原型，是產品經理構建產品時的模型設計，是對需求理解的具體體現；需求文檔，是產品經理構建產品時的邏輯解釋，是對需求邊界的具體界定。

需求原型，早些年只能在紙上畫草圖，之后逐漸在軟件上用線框圖+連接線示意，現在隨著原型工具軟件越來越智能，產品經理可以使用帶有交互效果、更逼真的工具軟件輸出一定程度的保真效果原型。

需求文檔，是產品經理因為不能通過原型完整地體現產品的邊界邏輯時，需要用文字進一步詳細描述；有些產品經理寫的需求文檔不僅要包含業務邏輯，異常情況界定，字段解釋以外，還要寫很多的交互邏輯，文檔內容顯得特別冗長，對閱讀者來說會非常難受。

其實需求原型和需求文檔是相輔相成的，當產品經理向業務方做產品演示或者和研發團隊做需求評審時，通常只需演示需求原型即可；有時候也會用到流程圖和思維導圖，便于抽象的業務解釋。

需求文檔通常在具體的功能開發和測試階段用到，便于研發人員和測試人員對功能的字段數據界定有清晰的結論參照，同時也為了對相關的功能邏輯和需求結論留檔備份，以便日后有需要時可查找。

由上文的表述，可以認識到產品經理在輸出產品的原型和文檔時，一定要特別注重完整性和簡潔性。

我個人認為產品經理在原型輸出上應該盡量追求產品保真度，頁面交互盡量做完整，一方面可以更直觀地感受和體驗產品模型，快速驗證和評估產品功能的可行性，另一方面可以讓對應的需求文檔更精簡，減少閱讀者的閱讀量。

四、對產品沒有owner意識

前文已說到，產品經理要做到對產品認知最完整，理解最透徹，解釋最專業。簡單來說，產品經理要定義自己是產品的創造者，擁有對產品的最直接決策權，因而產品經理應當要具備有owner意識。

一個業務需求，當它轉化成具體的產品功能，在需求評審時可能存在多種實現方案，這時作為產品經理，應當主動結合各方的建議和意見，最終給出一個確定的方案結論；比如從深圳到北京，可以選擇做火車、動車、飛機或是自駕等，選擇什么交通工具會對旅途時長有影響；產品經理可綜合各方的意見和訴求，取最大公約數，選擇大家都普遍都可接受的交通工具（比如高鐵）。

也許有時候會覺得自己不具有話語權，常常被老板、業務方或者研發部門刁難；但我認為，產品經理要通過對產品的專業性去爭取話語權，爭取產品的決策權。

其實在實際中，我見識過一些產品經理，當別人希望他做決策時，總是缺少勇氣，畏首畏尾，這是非常糟糕的表現，會嚴重影響自身作為產品經理在團隊中的身份認同。

五、不懂決策權歸屬

前文說到，產品經理對產品要有owner意識，要努力爭取產品的決策權，勇敢參與決策。

實際工作中難免還是會遇到一些自己不能輕易做決策的問題，但這時候產品經理不能讓問題一直懸而未決，而要明確清楚誰可以做最終決定，誰對結果負責，找到對應的對接人，落實決策結論。

產品經理主要對產品負責，事關產品的任何事項，產品經理都應當積極推動執行，否則若是最后出了差錯，產品經理是要負主要責任的。

所以產品經理在日常工作中， 涉及到產品需求的任何事，一定要認清自己是第一責任人，越是重大的需求，越是要積極主動推動它，不管需求最終是被研發部門拒絕，還是需求提出人放棄，產品經理都要落實到位，并將需求結論同步到各個相關方。

六、缺乏產品規劃能力

每一個產品都有生命周期，分為出生、成長、成熟、衰落、死亡五個階段。通常我們所參與的產品項目處于出生期和成長期居多，畢竟多數人不會愿意參與一個正在走下坡路的項目。當產品經理接手一個產品項目時，他便成了這個產品的主導者，要像一個匠人般慢慢去打磨它。

在宏觀上，產品能體現一家企業的商業模式和企業文化；在微觀上產品能體現締造者的思想和意志。

作為產品經理，當我們接手一個項目時，在熟悉業務的同時，我們需要捫心自問一個問題：這個產品，你真的愿意投入時間和精力去做好嗎？

人生短暫，只有內心認可了，才會舍得投入心力去做事情。

所謂的產品規劃，其實是對產品的生命周期做計劃，以目標為導向解決產品每一個階段所面臨的各種難題和困境。 在規劃產品時，產品經理要考慮清楚產品的遠景目標是什么？需要切分幾個階段完成？每個階段要解決哪些問題？……

有時候在公司的戰略層，也許老板會提出一個比較宏觀的發展方向，比較抽象，作為產品經理需要在戰略層的方向上去做更具體，更能落地的產品規劃，層層拆分細化，把大目標拆成小目標，小目標轉化成具體明確的產品需求，推動研發團隊逐步去實現。

就好比說一個小孩子，父母在其成長過程中會有一些期待，希望小孩將來成為某些方面的優秀人才；然而要成為一個優秀的人不是一蹴而就的，需要慢慢培養，做人生規劃；不同年齡階段完成相應的訓練和成長，每一步都做好做扎實，最終才能達到目標。

在我看來，一個好的產品經理，一定是能夠做產品做規劃的，不能做規劃的要么是產品經理不認可該產品，要么是自身能力欠缺。

做產品的規劃（以B端產品為例），我覺得可以根據從幾個方面做思考：

• 考慮產品mvp版本的構造，即產品的主線業務流程要順利走通；
• 考慮繼續填補完善產品的次級業務流程；
• 考慮在產品的數據分析能力方面做更多的發力；
• 考慮產品在用戶體驗、優勢服務上進一步增強；
• 考慮產品的跨平臺連接能力，使產品在行業市場上更具柔性和生命力。

七、無團隊協作能力

產品經理與研發團隊在日常協作是最緊密的，可以說是一個鍋里吃飯的戰友。產品經理名義上有“經理”的頭銜，但是也僅僅是對產品負責，沒有任何的行政管理職權，與研發團隊共事十分考驗產品經理的協作能力。

跟程序員接觸多了就會發現，他們的世界觀是非常清晰的，任何問題只要邏輯能夠解釋清楚，就可以通過技術實現。

他們對產品經理的反感之處主要在于兩點，一是產品經理常常提出一些邏輯不能自洽的需求，叫做不合理的偽需求；二是產品經理經常對需求變更實現方案，導致開發需要返工，費時費力。

作為產品經理，一方面要針對上面兩點常常自省和加強學習改進外，另一方面要多留心觀察不同人的性格和表達方式，以對方易于接受的方式進行溝通，常懷同理心。

面對研發團隊，妄圖靠所謂的小恩小惠或者私交情去對接工作基本是沒有希望的，唯一的好辦法就是對每一個需求方案都做得足夠細致，思考到位，在需求評審會中讓人家看到自己的專業性，產品經理才能在團隊協作中建立真正的影響力。

八、業務調研能力弱

產品經理在處理產品需求時，常常會無意識地犯一個錯誤，即做需求時思考過于主觀，缺少必要的需求調研過程，或者說需求調研的深度還不夠，沒有探索到需求的本質。

對于業務方來說，通常他們在提出需求時，常常因為當下在使用產品功能時遇到了困難，然后給產品經理提過來一個具體的解決方案，即“能不能實現……”“能不能做到……”等等，如果不細究追問，就不會知道他為什么需要這個功能，即需求的產生的背景是什么，也不會知道做了這個功能后最終能滿足對方什么期待。

我以為，當業務方提出需求時，不要輕易地答應對方且以對方提的方案作為產品需求方案，要多溝通盡量詳盡地了解情況，也許最終只是他們的操作方法不對；也許還有其他更好的方案可解決問題；也許那本身就是一個不可實現的偽需求，等等。

九、不做會議紀要

產品經理與其他業務部門對接需求，或者是與研發團隊開需求評審會時，一定不能忘記做好會議紀要。做會議紀要最重要的是記錄下在會議溝通中大家共同認可的問題/需求結論，以及會后需要相關責任人進一步跟進的事項。

尤其是超過半個小時以上的會議，切記不要妄圖靠腦子記憶；如果覺得當時記錄來不及的話，可以考慮會議前打開手機的錄音功能，會后再過錄音回放提取要點記錄下來，并公布給大家。

特別地，產品經理在跟研發團隊開需求評審會時，研發人員（研發組長）常會對需求方案提出一些細節問題，需要產品經理會后做補充調整。

產品經理最好是先記錄問題點，會后再做跟進處理，而不要把評審會變成頭腦風暴會，占用其他同事的工作時間。

有效地把控好需求評審會的時間節奏，研發同學們會發自內心感謝你的，相信我！

十、產品需求不分級

在做產品的過程中，產品經理不可避免地會接到各種各樣的需求，而且研發資源短期內也可能不會有更多投入。

面對日漸繁多的需求，產品經理需要對需求進行分級處理，通常按照重要且緊急、重要不緊急、緊急不重要、不重要不緊急四限象進行劃分；即使是重要且緊急的需求居多，也要做好區分，根據研發資源酌情處理，否則產品的迭代計劃就是一團亂麻。

需求分級，一是為了對了解業務方對需求滿足的渴望度以及產品的迭代預期；二是根據實際情況合理分配研發資源，重視ROI。

對需求合理分級也是產品經理綜合能力的一種體現，需要對需求有足夠的理解、對產品迭代有清晰的規劃、對研發資源有合理的判斷預期。

十一、總結

產品經理這個職業，表面上沒有什么突出的硬件要求，卻在軟實力方面有較高的無形門檻。絕大多數人即使入了行，也總是停留低水平領域止步不前，究其原因，可能連上文提到的十項能力還遠遠不足。

其實仔細想想，產品經理這個職業，很像是工匠傳承的師徒制；很多時候沒有辦法通過統一的教科書進行規范式教學，更多只能在產品實踐中，前輩以傳幫帶的形式帶領著后輩成長，在一個個具體的產品項目中摔打磨練，總結經驗教訓，慢慢成為相關領域的行業專家。

能夠走上產品經理職業道路的人，多數都是倍感幸運的！因為除了能在工作中獲得諸多成就感以外，更多在于產品思維和習慣的養成，對個人生活上也有諸多正向激勵，受益良多。

愿常懷感恩心，用心做好產品！

 

本文由@稻田 原創發布于人人都是產品經理。未經許可，禁止轉載

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