產品經理這一角色承載著將創意轉化為現實的重任，從需求的洞察到產品的推出，他們是如何平衡用戶需求與商業目標的？本文深入探討了產品經理的核心職責、挑戰和成長路徑，帶你一窺這個被誤解但又至關重要的角色。

那在內容開始之前，先問大家一個問題。

產品經理是誰？

who？

在日常工作中，大家是不是經常被問到類似的問題？

每當被問到類似問題時，我常常陷入沉思。

這似乎也變成了一個「永恒的問題」。

每當逢年過節，與親朋好友聚會時，總會遇到這樣的對話：

親友：“你是做什么工作的呢？”

我：“互聯網行業?！?/p>

親友：“哦，那你一定很會用電腦吧！”

我：“… 我是產品經理 … ”

親友：“不錯啊，都當上經理了！”

我：“不是，產品經理并非傳統意義上的‘經理’?！?/p>

親友：“那是什么？”

我：“… …”

每當被外行問及，我總是自嘲地回應：“產品經理嘛，其實就是個‘全能打雜的，或者救火隊長，總之哪里需要去哪里’！”

在日常工作中，產品經理這個角色需要涉獵廣泛，但又不可能做到樣樣精通，行業里也常常流傳著一句話，“產品經理什么都要懂但什么都不精通”。

除了每天各種撕逼外，似乎并沒有一項真正擅長且獨一無二的技能。

而且每個團隊對產品經理的期望和要求也不盡相同。

就導致了一種普遍觀念，認為產品經理無非是鏈接業務和開發的工具人。

–但是

事情并沒有那么簡單。

因為產品經理被要求需要同時具備廣度和深度。

那這個角色就注定了在很長一段時間內都會被人誤解。

先給大家分享一個小故事。

也是一個比較典型的案例。

100多年前，福特公司的創始人亨利·福特先生到處跑去問客戶：“您需要一個什么樣的更好的交通工具？”幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。

— 但

客戶是真的想要一匹很快的馬嗎？

或許吧。

但福特先生卻沒有立馬往馬場跑，而是接著往下問。

福特：“你為什么需要一匹更快的馬？”

客戶：“因為可以跑得更快！”

福特：“你為什么需要跑得更快？”

客戶：“因為這樣我就可以更早的到達目的地?！?/p>

福特：“所以，你要一匹更快的馬的真正用意是？”

客戶：“用更短的時間、更快地到達目的地！”

然后福特就發明了汽車，很好的滿足了的客戶的需求。

嗯！

這個可能是一個很好的滿足了這個客戶以及一群客戶的需求。

如果我們停留在現有客戶所說事物的表面，傻傻去找一匹很快的「馬」，那現在可能就沒有汽車了。

好的，這期內容正式開始。

產品經理「PM,Product manager」，在公司主要負責規劃和管理某一項或某一類產品，主要涉及產品的研發、制造、營銷、渠道等工作。

2009 年360紅衣教主周鴻祎，在媒體上強調自己是產品經理，后來，?化騰也說??是產品經理，喬布斯也在媒體上被強調為產品經理，這三個?重新定義了?眾理解的產品經理;

?家?想起產品經理就是CEO們的形象，大眾會有認知誤區：???，雷軍、張?鳴、王興、張小龍、喬布斯、 PeterDeng等多個知名企業創始?也強調過??的產品經理??。

產品經理需要具備產品思維，以用戶的需求為導向，輸出有用戶價值、商業價值的產品。

同時，包括市場調研、產品定義及設計、項目管理、產品宣介、產品市場和產品生命周期管理等。

Marty Cagan 在他的《Inspired》書中將產品經理的工作描述為“發現有價值、可用和可行的產品”。同樣，我一直將產品管理定義為業務、技術和用戶體驗之間的交集，一個好的產品經理必須至少在一個方面有經驗，對這三個方面都充滿熱情，并且熟悉所有方面的從業者。

從上圖角度出發，定義這三個概念以及三者之間的關系。

用戶體驗「UE/UX,User Experience」是許多人掛在嘴邊的名詞。

但這是一個多維度、相對主觀的概念，它涉及的是用戶對我們提供的服務的整體感知，而非僅限于產品、應用、網站或設備等物理接觸點。

真正的用戶體驗關注的是服務的整體流程，包括但不限于APP頁面之間跳轉邏輯、界面的框架設計和布局、更要從全局思考整體業務流程。

之所以說用戶體驗是相對的、主觀的、片面的，是因為它依賴于個體用戶的獨特感受和認知。

舉個例子。

你去一家西餐廳吃牛排，牛排能不能吃，好不好吃是餐廳所能提供服務的核心，但當朋友們問起這次吃飯的體驗如何時間，你腦中浮現的絕不僅僅是牛排的味道，可能還包括餐廳的門面，店內布置，桌椅擺放，服務人員的態度、響應時間，菜單設計，看單點單流程，上菜的時間和順序，其他客人的用餐狀態，以及買單和離開時的服務等一系列的體驗，構成了你對朋友的回答：好，或不好。

這一系列影響用戶體驗的因素，都存在于用戶腦中，而不僅只在我們作為餐廳運營和管理者的腦中。作為產品經理，你如何定義這項服務中的每個關鍵因素，并圍繞著關鍵點提升 UE ，就體現了你在這方面的專業素養。

01

產品經理用不用懂技術「Echnology」？

這個話題一直存在比較大的爭議。

普遍的共識是：理解技術對于產品經理來說是至關重要的，這不僅有助于更好地定義產品的構建方向，還能在與開發人員溝通時建立更深的信任關系。

其中最重要的幫助就是信任。

產品經理對計算機知識的了解程度和迭代頻率，就像“水”的質量和流動性，了解的越多，越能幫助彼此理解雙方的需求，互相認同。

對于產品經理而言，商業「Business」洞察力可能經常被放在“重要但不緊急”的象限中，這在互聯網行業尤為明顯。

商業的本質在于追求資金增長，通過資本運作和建立關系網絡來規避風險，其深度和廣度往往使得許多人對其保持敬畏，進而不愿或難以深入探討。

要提升在商業方面的認知和能力，最直接的方法便是親身參與商業實踐，通過實際操作來學習和領悟。

除了這些，還可以努力將自己塑造成一個具有商業價值的人，以便在商業環境中更容易被發現和認可。

在日常工作中，將關注點從“業務”或“業務邏輯”提升至更宏觀的“商業”層面，了解自己在公司整體戰略中的位置和貢獻，也是提升商業認知的重要一步。

前不久閱讀了Josh Elman的文章《Let’s talk about Product Management》，其中一句話讓我豁然開朗——“產品經理是幫助團隊發布正確產品的關鍵角色”。這句話精準地闡述了產品經理的核心職責和價值所在。

從產品的角度來看，產品流程主要涵蓋了從項目啟動到項目收尾的各個環節。

但一個項目從啟動到收尾是由多方共同協作的結果。產品經理在其中扮演著“將idea/需求轉化為產品”的角色，十分關鍵，優秀的產品經理在項目中不僅僅著眼于產品本身，還包括與產品相關的人和事兒，因此讓我們從產品經理工作職責內去看看產品經理視角下的工作流程。

常見的產品經理的工作流程，基本是需求管理、產品規劃、項目管理。

實際上，產品經理一上來不是做產品規劃，也不是做需求分析，而是做需求管理。

因為要為用戶服務，為商業服務，就得了解他們的需求和訴求。

收集需求和訴求的過程，需要面對的第一個問題就是溝通。

溝通能力是產品經理需要具備能力中比較重要的能力之一。

• 對內溝通：與部門領導、業務方領導和同事、運營等各側溝通，收集需求；
• 對外溝通：與客戶、用戶溝通，分產品階段了解用戶在用戶體驗流程方面的機會和痛點；
• 線上溝通：通過問卷、社群、社區、線上會議等方式都可以是溝通渠道「有價值的內容往往不易獲取，隱藏在一句話中，抓住重點深挖到底“人性層面”，是有講究的」。

溝通前，要想清楚溝通時主要想解決的問題，有一點思考并能夠陳述出來，隨后與相關人發邀請「郵件、微信等方式」；

溝通中，溝通前先閑聊幾句進入正題，圍繞目標進行溝通，做好記錄，并在會議結束時確認溝通的內容，有條理的確認一遍「對方提出問題，要聽清對方的問題，作出有條理的回答」；

溝通后，總結訪談內容/會議紀要，添加微信、組群、組織交流學習等。

溝通不僅僅是為了解用戶的痛點、癢點、嗨點，也需要了解用戶的期待和目標，也許用戶已經為了解決問題嘗試了一些辦法，也許這些辦法是很可笑的，但還是需要尊重用戶，作為產品經理只是幫助用戶解決問題、更好的解決問題、規?；慕鉀Q問題，在做到這些的同時考慮商業化的解決問題。

產品經理必備的文件“需求池”，需求池是在收集需求中產生的，非常有必要做的一個表格，可以幫助你追蹤、溯源、管理，具體內容如下圖。

可以根據自己的需要建立自己需求池，這個非常重要，希望各位產品人能夠養成使用的習慣

需求池字段包含需求來源、獲取日期、溝通人及聯系方式、需求價值、需求類型、需求描述、問題點、需求優先級、備注等。

將收集到的需求盡可能詳細的記錄在內，盡可能的收集一手需求，刨根問底找到提出需求的那個人，讓需求盡可能的接近原始。

需求的初步的篩選和分類可先按以下方式進行分類，再通過內部需求評審具體的商議定性「類型和優先級」。

1. 按產品屬性劃分

• 新想法「Idea」：創新性的概念或觀點，為產品帶來新的方向或可能性；
• 新增「New Feature」：在現有產品基礎上增加的新功能或特性；
• 優化「Optimization」：對現有功能或流程進行改進，以提升用戶體驗或產品性能；
• Bugfix：修復產品中的錯誤或缺陷，確保產品穩定運行。

2. 按產品職能劃分

• 功能類需求：與產品核心功能直接相關的需求，是產品實現其目標所必需的；
• 運營類需求：與產品運營和推廣相關的需求，如數據分析、用戶增長等；
• 數據類需求：涉及產品數據收集、分析和應用的需求，用于指導產品決策和優化；
• 設計類需求：與產品界面、交互和用戶體驗設計相關的需求。

3. 按產品價值劃分

• 用戶需求：最終用戶對產品的期望和需求，關注解決用戶問題和滿足用戶期望；

• 商業需求：企業或組織對產品的需求，關注商業模式、市場需求等，以實現商業目標。

4. 按產品性質劃分

• 顯性需求：用戶直接表達出來的需求，可以通過市場調研、用戶反饋等方式獲??；
• 隱性需求：用戶未明確表達但潛在存在的需求，需要產品經理通過深入分析和洞察來發現。

5. 按需求層次劃分

根據馬斯洛需求層次理論，產品需求可以劃分為生理需求、安全需求、社交需求、尊重需求和自我實現需求。

這種分類方式有助于理解用戶在不同層次上的需求，從而設計出更符合用戶心理和行為的產品。

6. 按功能性和非功能性劃分

• 功能性需求：產品必須實現的具體功能或業務邏輯；
• 非功能性需求：對產品的性能、可靠性、易用性等方面的要求，如響應時間、安全性等。

明確需求的背景，用戶的畫像，用戶的目標，根據5W2H的結構化思考方法，用Y理論進行分析。

7. 評估新需求對現有功能的影響

• 用戶體驗：新需求的引入需細致分析其對現有功能操作流程的影響，確保不增加用戶操作復雜度，同時評估其是否能提升用戶體驗，如界面直觀性和操作流暢性，并維持與現有功能在界面設計和交互邏輯上的一致性，避免用戶困惑。
• 技術實現：技術實現的難度、對現有技術架構的影響、開發團隊的技術能力和資源，以及新需求與現有功能在技術上的兼容性和可擴展性。
• 產品穩定性風險評估：引入后是否可能增加故障率、降低系統穩定性，評估必要的測試以確保其穩定可靠，并考慮其對現有功能性能的影響。
• 商業化：對產品市場競爭力、用戶粘性和付費行為的提升作用，評估其對長期商業價值的貢獻，并考慮與現有功能在定價策略和市場推廣上的協同效果。
• 對現有功能的優化與整合：是否能提升產品效能、拓寬使用范圍，并考慮在數據、流程等方面的協同整合，以提升產品整體價值。

進行成本評估需要綜合考慮多個方面，包括直接成本，如人力成本「開發、測試、運維等人員的工資和福利」、硬件和軟件成本「服務器、開發工具、第三方服務等」、培訓成本等；以及間接成本，如項目管理成本、溝通成本、風險控制成本等。此外，還需要考慮時間成本，即完成需求所需的時間周期，以及由此產生的延期風險和其他潛在成本。

在評估過程中，可以采用多種方法和技術，例如，用工作量評估法來估算開發團隊完成需求所需的工作量，從而推算出人力成本。還可以使用類比評估法，參考類似項目的成本數據來預測當前項目的成本。

同時，為了更準確地評估成本，還需要考慮一些關鍵因素。如技術的復雜性和新穎性，這可能會影響開發難度和所需時間；團隊的技能和經驗，這決定了工作效率和質量；市場的競爭狀況和需求變化，這可能對產品的定位和功能需求產生影響。

每一個需求，圍繞我們前面說的，都有其緊急重要程度，依次排優先級。

緊急度主要看風險或者損失量，重要度主要看影響和波及面。

重要且緊急的，那我們就要往前排，反之則往后；

如果兩個需求都同樣緊急且重要，那我們就要參考需求處理周期和人力資源成本因素。

不管是產品規劃，還是開發上線，都需要周期，也需要資源配置。

如果周期太長，而用戶需求又迫切，我們就需要找到暫時可替代的方案，或者某個權益之計，或者迭代個小版本，解決最核心問題；

當然，這個過程也不是產品經理一個人決定，往往需要業務「可能包含管理層」、產品、技術一起三方會議。

首先要搞清楚，排需求優先級的目標是為了做好產品版本規劃，版本規劃「迭代計劃」的目的是為了更好的平衡用戶利益和商業利益。

產品需求文檔「PRD，Product Requirement Document」是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，用來承載當前版本的需求背景、產品方案、原型界面等內容的產品說明文檔，通過文字描述每一個功能點每一個要素的數據來源，整個業務流程和邏輯，每一個頁面模塊按鈕的交互效果，方便告訴前端和后端開發人員，最終要達到的根本效果。

寫需求文檔的過程，其實是檢查遺漏或考慮不周的過程。

因為原型圖并不能將所有內容全部呈現，需要文檔進行補全。

同樣，需求文檔中的某些可行性存疑時，也要與開發人員溝通確認。

文檔詳細描述了一個產品的所有面向用戶的功能需求、非功能性需求、性能要求等，為開發團隊提供了明確的開發目標和方向，以供軟件工程師正確地實現所有的用戶需求。

對于商業性和業務性導向的產品，如賦能型產品，需要輸出MRD，因為需要將市場、用戶、業務、商業、競爭的情況說明。

Demo原型設計包括產品界面設計、交互設計等，很少有人知道產品經理還有另一個稱呼「PD，Product Designer」產品設計師，從字面上可以窺見端倪，PD和PM 并不相同，PD更為純粹，PM 則像是在 PD的基礎上多增加了一管理的含義。

這要求不僅能設計好產品，還要管理好產品，為產品負責。

我相信很多人都想成為PD而非PM，夢想著自己設計的產品能夠改變世界，而不是因為管理執行取得成功。

02

在我看來，產品的設計能力和管理運營能力都同等重要。

孰優孰略是一件很難有定論的事情，所以踏上產品經理這條道路那一刻就需要思考來來是想成為 PD 還是 PM，這決定了應該積累哪些能力以及發展的路徑。

如果沒有做好產品定義，不要輕易開始原型設計，因為會被自己設計的原型圖框住思維，繼而忘了本該做什么，或者加入了過多繁雜的體驗設計，而沒有解決真正的問題。

這也是很多產品經理在剛入行時容易犯的錯，當然，也不乏這樣的同行，所以很多小老板會將產品經理描述為“畫圖的”。

Demo需要考慮如何有效傳達給項目相關同學、客戶。

為了讓關鍵頁面有沖擊力，使用高保真方式傳達，可請設計師幫忙；

為了盡快的輸出Demo，選擇更適合的工具「AXURE、墨刀…」，用靜態頁面+規范美觀的交互說明+生動的口述的方式傳達；

為了讓產品更加生動的展示，制作簡短的視頻，介紹產品的核心價值。

原型設計可分為線框圖、原型圖、高保真。

1. 線框圖主要特點

• 呈現主體信息群；
• 勾勒出結構和布局；
• 用戶交互界面的主視覺和描述；
• 線框圖是一種低保真的靜態圖形，它勾勒出布局輪廓，但是缺少細節。

可以把線框圖理解為設計圖的骨干與核心，它承載著最終產品所有重要的部分。

繪制線框圖，重點是「快」，可以使用手繪稿或用相關原型工具進行制作。

主要用于產品前期頭腦風暴或需求溝通討論階段，非正式場合的團隊內部交流等。用來激發思考和討論，收集需求反饋等。

2. 原型圖主要特點

• 包含完整的產品功能與交互流程；
• 能夠模擬最終產品的功能和交互；
• 用于產品開發前期進行用戶體驗測試；
• 原型應該盡可能模擬最終產品，交互則應該精心模塊化，盡量在體驗上和最終產品保持一致。

但是原型背后的邏輯不要依賴交互形式。

減少制作原型的成本，加快開發速度。

常用于做潛在用戶測試。

在正式介入開發階段前，以最接近最終產品的形式考量產品可用性。原型的直觀和易懂倒使它成為最高效的設計文檔。

3. 高保真主要特點

• 表達信息框架，靜態演示內容和功能；
• 幫助團隊成員以視覺的角度審閱項目；
• 視覺稿是高保真的靜態設計圖。

通常來說，視覺稿就是視覺設計的草稿或終稿。在視覺稿定稿前，應與團隊成員進行多方溝通和確認，以免造成溝通不足造成后期的返工。

視覺稿主要用于開發階段收集用戶反饋，同時幫助團隊成員以視覺的角度審閱項目。

無論哪一種，都可以與設計師多交流，如設計規范、歷史項目設計文檔，可以從設計師那里獲取到，是原型設計靈感的來源之一，并且在參考后可以避免一部分設計規范性問題，保證了用戶體驗。

根據產品設計的復雜度和團隊資源情況，制定詳細的項目計劃，組織協調各方資源，確保項目按計劃進行，確定項目的關鍵里程碑、交付物、時間節點等。

常見的項目關鍵里程碑包括項目審批、項目啟動、關鍵項目交付物的完成、重要項目階段的開始或結束日期，以及為項目開綠燈的重要事件等。這些里程碑事件不僅與項目的具體任務和工作內容緊密相關，還體現了項目的整體進展和關鍵決策點。

4. 交付物「以軟件產品的交付物為例」

• 軟件產品本身：這是最主要的交付物，需要是一個完整、可用且功能齊全的軟件產品，滿足客戶的所有需求，并確保其穩定可靠；
• 用戶文檔和操作手冊：需要詳細描述軟件產品的使用方法、操作流程，以及常見問題的解答等內容，旨在幫助用戶更好地理解和使用軟件產品；
• 源代碼和編譯環境：提供軟件開發過程中的源代碼以及編譯環境，這樣客戶就能根據需要對軟件進行二次開發、修改和擴展；
• 技術文檔和說明書：包括軟件架構、設計思路、技術實現、測試記錄等相關文檔，為軟件的后續維護和升級提供了重要的支持；
• 培訓和支持：提供必要的培訓和技術支持，確保用戶能夠順利地使用軟件產品，并解決在使用過程中可能遇到的問題；
• 保修和維護：對軟件產品的質量和穩定性進行保證，提供一定期限內的免費維護和更新服務。
• 知識產權和授權：明確軟件產品的知識產權歸屬和使用授權范圍，確保項目交付符合相關法律法規的要求。

需求評審與確認，首先，將準備好的原型圖和需求文檔同步給相關設計、前端、后端、客戶端開發、測試等人員，并開會將主要效果呈現，確保本次產品設計符合業務需求或用戶需求，并具備可行性。

在評審會中，各方人員會就產品需求的各個方面進行討論和評審，提出意見和建議，以確保產品需求的準確性、完整性和可行性。

然后溝通確認每個環節人員的開發排期時間。并將該時間與相關方同步，協調計劃。

一般公司產品經理兼任項目經理的角色，因此UI設計圖的交付、開發進度、上線的安排，都由產品經理把控。

與開發團隊緊密合作，確保產品按照需求進行開發，可在測試環境體驗產品，對與原型設計不符的地方提出修改意見。

監控開發進度，及時溝通開發人員的問題反饋，并及時給予明確信息和解決方案。

如果開發進度慢下來，需要找到原因，通過溝通或者協調資源，達成既定目標。

如果不及預期，需及時與相關方溝通，尤其是上線時間延后，可能帶來某些業務的計劃不能如期進行。

那在這個環節內，經常會衍生出一個問題。

03

產品經理需要懂技術嗎？

我想聽一下你們的答案，給大家三秒鐘的時間，可以打在下方評論區我看一下。

3、2、1

OK。

這個問題在開篇提了一句。

現在咱么深入一下這個話題。

產品經理需要懂技術嗎？懂到什么程度？

在公司里程序員是互聯網產品經理在工作中打交道最多的人之一。

產品經理提需求給程序員，程序員將需求用代碼實現。

通俗點來說呢。

就是一個提供菜單，一個負責做菜。

互聯網的產品經理基本都是轉行過來的，各個專業背景的都有，大部分產品經理是沒有技術背景的。

也就是說提供菜單的人，很多卻沒有做過菜，更別說提供一份靠譜的菜譜了。

在實際工作中經常會看到產品經理提需求給程序員，程序員卻告訴產品經理做不了或者要換方案。

然后雙方就開啟了Battle模式。

所以業內流傳一句話說產品經理和程序員是相愛相殺。

會發生這樣的原因，其實是產品經理和程序員考慮問題的角度不同。

一個從用戶和業務角度出發。

一個從技術角度出發。

作為產品經理，為了讓需求更容易推進、更容易落地，其實還是要懂點技術，并且學會理解技術。

當然，懂技術不是讓產品經理去寫代碼。

而是了解互聯網的一些基本技術和原理，如接口、MQ、多線程、實時請求、延時加載、異步導出等。

了解技術實現原理是為了評估出所采用的技術方案對用戶或業務是否有感知，是否會影響到用戶體驗。

如異步導出，技術上實現的方式是將導出文件寫入到臨時文件，臨時文件上傳到OSS獲取上傳文件URL路徑，記錄URL文件到數據庫中并刪除臨時文件，再通過單獨頁面查詢導出文件列表，進行下載。

這樣做的好處是避免導出數據量過大時，請求超時。

對于用戶的影響是，用戶進行導出操作后，不會將文件立即導出，可能需要等待一段時間，讓用戶去下載中心進行下載。

那么產品經理就要綜合考慮技術和用戶體驗最終權衡利弊，決策出一個最優解決方案。

學會理解技術要求產品經理有時要站在技術角度了解不能實現原因和難度。

而不是一味地和技術說我就要這么做。

其實，很多需求可能只是產品經理自己YY出來的，需求不做或者進行一定妥協，對用戶、對業務沒有影響，反而能減少開發成本。

所以產品經理要懂點技術，并學會理解技術。

協調測試團隊進行產品測試，確保產品質量符合預期，產品開發過程中，測試需要完成：「TC，測試用例」、「TC，評審」。

產品不必完成全部開發后才進行測試，可基于需求優先級，對完成的部分進行相關測試，如前端的功能和交互。

產品上線前需要進行完整的產品測試「包括黑白盒壓力測試等」，并輸出產品測試報告。

當產品通過測試后，產品經理和設計師需要對產品進行驗收，確保最終效果和產品方案一致。

1. 上線前，需要做好相應準備，比如上線的時間選在用戶不常用的時段，避免出現問題；比如選擇灰度發布，比如選擇A/B測試，比如數據的清洗、遷移，或者建設。
2. 另外，可能涉及與業務或運營團隊的配合，進行產品推廣和營銷活動。
3. 最后上線后，觀測產品運行情況，有問題要及時處理，如果不能處理，就只能回滾版本，收集用戶反饋，對產品進行持續優化和改進。
4. 項目結束后，對整個項目進行總結，分析成功因素和不足之處，持續搜集用戶使用情況，將需求和問題，搜集到需求池，產品不是一步到位、一蹴而就的，而是不斷在實踐中完善的。
5. 推向市場必定會收到用戶反饋，無論是差評，還是建議，或者市場發生變化，都可以讓我們開啟新一輪產品規劃，對產品進行持續優化和迭代。
6. 另外，我們也需要有意識地管理產品的生命周期，確保產品始終保持競爭力。規劃產品的未來發展方向和新技術應用。
7. 分析產品的用戶數據和市場表現，關鍵指標的數據是否提升。識別產品的優勢和潛在改進點，為產品決策提供數據支持。尤其是做某個垂直領域或者某個模塊的產品經理，在工作中會有特別明確的數據指標，這些是過去長期積累下來對月業務增長具有關鍵作用的指標，通常將數據的增長，當做匯報業績的具體成果和呈現。外界也更容易在短時間內了解我們的價值和結果。

以上是產品經理大概的日常工作流程。

除此之外產品經理還需要具備

• 邏輯能力：具備清晰的思維，能夠理解并應用產品、技術、業務和商業邏輯，高效地解決問題和提高協作效率；
• 溝通能力：擅長人際交往，能夠理解并應對個體差異，通過聆聽、觀察、提問和激勵來推動工作進展；
• 分析能力：能夠客觀地搜集和分析信息，具備獨立判斷力，能夠從不同角度和角色進行思考，發現問題的關鍵點；
• 創造能力：具有創新思維，能夠抽象和歸納問題，快速找到解決方案，并愿意不斷嘗試和驗證新想法；
• 規劃能力：能夠清晰地呈現業務和數據邏輯，編寫詳盡的需求文檔和原型圖，以及進行有效的版本規劃，確保產品迭代滿足用戶和商業需求；
• 學習能力：保持開放心態，不斷學習新知識和技能，適應新環境和挑戰，以促進個人和產品的持續成長。

那這些能力其實并不是一朝一夕就能完全掌握的，需要產品經理在日常工作中通過持續的發展、深化、實踐和積累來逐步培養和完善，同時在解決問題的過程中總結經驗，優化自己的能力體系。

在實踐、積累的過程中也可以適當學習并了解一些數據分析中所使用到的一些方法論，這塊往往很容易被剛入行的產品經理忽視，他們往往覺得產品經理只需要會寫需求，會畫圖就行，但其實很重要，例如swot分析法、5W2H、商業畫布、北極星指數、用戶生命周期、用戶增長模型、AARRR、RFM模型等等

需要保持對行業領域的敏銳觀察，了解當前行業的發展態勢、結構性問題以及市場機會，通過深入分析，判斷企業能否彌補行業中的不足或抓住新興機會，評估資源供給是否足夠，市場是否需要進一步教育，以及用戶習慣和需求的變化，在此基礎上，調整產品策略，確保產品既不過于老套，也不過于超前，而是能夠與時俱進，緊跟市場潮流，從而保持產品的競爭力。

并充分考慮法律法規、人文風俗、公司需求、團隊需求以及時空勢，以確保產品既符合外部環境的要求，又能滿足內部的需求。

同時還需要具備主人翁意識，即對自己所從事的工作充滿熱情與責任感，能夠積極面對挑戰，享受創造和協作的過程，對產品的整個生命周期負責。

這種意識源于個人的熱情、開放心態和對提升自我的追求。

不僅能夠提升個人的工作動力和效率，還能夠帶來用戶的喜悅、同事的認可和職業發展的正反饋。

這期內容到這里就已經接近尾聲，給大家介紹一些產品經理常用的軟件工具，涵蓋項目管理、團隊協作、原型設計以及數據分析等多個方面。

• ?業報告：CNbeta、易觀智庫、艾瑞咨詢、億邦動??、天下?商、InfoQ、36?數據、App Annie、百度指數
• 項?管理?具：TAPD、Tower、Teambition、Worktile、Workflow、禪道、Project、SVN
• 在線?檔協作：?墨?檔、騰訊?檔、Notion、語雀、幕布、OneNote、Quip、Trello
• 腦圖 & 流程圖：MindMaster、Xmind、Mindjet、MindNode、ProcessOn、BullMind、百度腦圖
• 原型?具：Axure、Sketch、墨?、Mockplus、xiaopiu
• 素材?站：iconfont、堆糖、花瓣、Pixabay、湯不熱、昵圖?、Pexels、視覺中國
• PPT素材：OfficePLUS、PPTMind、PPT設計教程?、presentationload、變??、優品、51PPT
• 問卷調查：騰訊問卷、問卷星、調查派、問卷網麥克、番茄表單
• 第三?數據分析：神策數據、諸葛iO、友盟、growingIO、?易?數據、GA、極光?數據、百度統計、Talkingdata
• 指數：百度指數、阿?指數、艾瑞咨詢、友盟指數、愛奇藝指數、貓眼專業版、易觀千帆、CNbeta
• App數據：七?數據、易觀數據、騰訊移動分析

另外，近些年出現的AI工具，也非常適合做調研分析。

寫在最后

產品經理的工作，很累。

且不說過程中，收到各種各樣來自不同崗位不同職位的質疑和挑戰，特別是被設計師、被程序員、被運營人員懟到啞口無言，對一些相對玻璃心的人來說打擊可能會比較大。

日常被很多不重要的事情，浪費自己的時間精力，忙忙碌碌但是不知道忙些什么？

關鍵事項的進度條卻一直不推進，干著急，卻毫無辦法。

某個時刻，開始懷疑自己的產品能力，明明做了很多工作，也付出了很多努力。

但得到的回報很少，產品評價依然很差，不理解為什么？

我在工作時，早就發現這樣或是那樣的問題，解決辦法是希望找一個方法或者工具幫我解決這些問題。

曾經研究過各種時間管理的方法，也嘗試了很多，但效果甚微。

時間根本不可能管理，時間管理本質是一個投資游戲。

一個人每天只有24小時，如何合理分配時間才是關鍵。

道理誰都懂。

但是，什么工作是可以舍的或者推遲的？

一些只需要你參與但沒有決策權的會議，就可以舍棄無效會議，讓會議組織者把會議結論同步你即可。

又或者是對你來說沒什么挑戰性的工作內容，而且優先級沒有那么高的事情，可以選擇延期或者尋求產品助理的幫助。

… …

在工作的時候，發現很多牛逼的同事，他們每天會抽空1-2個小時去獨自會議室辦公，或者直接去樓下咖啡廳辦公，當時，我認為他們又去偷懶摸魚了。

但這是一個提高工作效率的高級做法。

可以留給你自己一些思考的時間，也可以減少思考被其他瑣事打斷的概率。

當然，這個方法最好用在氛圍比較寬松的職場環境。

產品經理們都有一個執念「曾經我也有」，那就是希望自己的產品無限趨近于完美理想狀態。

但是，現實卻是一次次的失望。

這時候，你就會產生巨大的落差，最終產生內耗自責的問題。

但是，需要認識到產品或者項目永遠是在范圍、進度和成本這個三角形里跳舞。

每項資源都是有限的，追求滿意即可。

世界上沒有完美的事情，我們應該追求滿足需求的完成，而不是無時無刻的完美，底線是完成可用，其他都是加分項。產品不可能一下子就達到完美的狀態，需要一步一步來。

而這個一步一步可能比你想象的要長，要瑣碎，迭代的次數要多。

但，這是正常的，只能慢慢的逐漸逼近。

到現在為止，我時不時還是有過度完美主義和責任感的毛病，只能逐步勸說自己放下。

有些產品經理有個臭毛病，喜歡指導別人的工作，隨意的提出自己毫無驗證的想法。

說實話，這個毛病非常吃力不討好，費自己腦子，還不被別人認可。

但是，有的人就是控制不住自己，怎么辦？

《被討厭的勇氣》這本書中指出：一切人際關系矛盾都起因于對別人的課題妄加干涉或者自己的課題被別人妄加干涉。

簡單來說，別人的事情，少管，管好自己就行了。

工作上，辨別究竟是誰的工作方法非常簡單，只需要考慮“這個選擇所帶來的結果最終要由誰來承擔？”

對于別人的工作，不要隨便干涉或給建議，避免和別人的事情過多糾纏。

但是，所有人都只關心自己，這個團隊難免有點冷漠和無情。

有兩個場景是可以提出自己意見的：

人家真心希望得到你的建議，這個時候建議的價值是最大的。

如果你看見非常明顯的錯誤，或者存在明顯的大坑。

但是，你也需要知道，你只是建議，采不采納那是別人的事情，和你沒有關系。

不要過多的在這個事情上浪費腦子。

隨著工作經驗的積累，我也在不斷反思自己的職業道路和未來規劃，開始思考自己真正想做的事情、能夠做的事情以及自己的職業目標，選擇一個適合自己的方向并為之付出努力，正如那句老話所說：“在時代的浪潮下，選擇重于改變?！?/strong>