編輯導語：初級產品經理在工作過程中，可能會遇到許多問題。本篇文章中作者結合自身經驗，從六個方面敘述瞭產品經理應該如何提升產品能力。感興趣的小夥伴們快來一起看看吧，希望對你有所幫助。

產品經理容易有這樣一個現象：看過很多的產品文章，學過一些產品課程，瞭解很多高大上的模型理論，每天關註互聯網資訊，你跟他聊天的時候發現他什麼都懂一點，但一上手就是不出活，暴露各種基本功不紮實的問題。

為什麼看瞭那麼多大咖的分享總結、方法論的文章，依然做不好需求？

結合我自己的經歷，我把原因總結為兩方面。

一方面，看的文章寫的內容泛泛而談不夠幹貨，或者說通用性不強，僅適用於作者自己的項目和工作，難以進行學習模仿。

另一方面是你隻是略讀一遍，像看新聞一樣，沒有深入理解其中的精華，在實踐的時候也沒有運用上。

本文的主要內容是初級產品經理工作過程中各環節的技巧總結，我寫的時候盡量是從現有工作內容中抽離，沒有涉及到我的具體業務，因此不同細分領域的產品經理都可以通用。

為瞭區分什麼是技巧、技能、能力，我這裡做瞭如下定義：

技巧：是為瞭快速提升技能的手段，是技能的一部分，是可以學習復制的

技能：是具體的、全面的，是為瞭做好一項工作而需要具備的內容，是可以學習復制的

能力：是技能內化後的結果，是舉一反三的驅動力，很難復制，需要靠自己總結提煉

由此可見，要提升產品能力，可以先從學習技巧開始，再掌握全面的技能，最後提煉出通用的能力，如此循序漸進。

本文主要內容：

初級產品經理必備素質

需求收集和過濾

產品方案設計

項目管理

溝通技巧

方法論建設

一、初級產品經理必備素質

處在職場的不同階段，聚焦點是不一樣的。作為初級產品經理，需要明確自己的定位和目標，練好基本功，切勿好高騖遠。

1. 清晰的自我定位

初級產品經理一般完整的負責一個功能模塊或一個系統，首先，需要對自己負責的模塊充分的熟悉然後瞭如指掌，讓所有需要跟這個功能對接的人知道，有問題隻要找你就解決瞭，這也是逐步建立影響力的過程；

其次，熟悉瞭模塊之後，再深入思考該模塊不同競品做的怎麼樣，自己產品所在哪個檔次，距離最好的產品差距有多少，如何基於公司的業務提高該模塊的競爭力；

最後，在掌握瞭自己負責的內容後，以點帶面，不斷完善加深對公司產品和業務的理解，才能獲得更多機會承擔更重大的項目。

以上三個過程是一個遞進的關系，也是初級產品經理在不同工作階段的不同定位。

2. 明確的工作目標

對於剛工作的前兩年，對於個人能力的提升目標方面，應該著重關註執行力、溝通力、項目管理能力三大塊，其中執行力包含瞭需求分析、產品設計、推進項目開始到上線過程的方方面面，這三大塊內容是作為產品經理最基本的基本功。

二、需求收集和過濾

1. 需求池管理

產品經理對需求的管理就像廚師對食材的管理，廚師在眾多食材中挑選合理的組合，加工成美味，產品經理在眾多業務方提出的需求中進行組合設計，加工成產品功能。

好的需求池管理不僅是對需求進行過濾，也是對工作內容的精細化記錄和總結，有利於有條不紊的項目管理和後期的復盤。我將對需求池的管理內容總結為三大部分：

判斷並記錄需求的真偽、重要性、緊急度、實現難度、業務價值、關聯方

記錄當前每個需求的項目實現狀態

追蹤需求實現後的用戶及數據反饋情況

至於需求池的表格模板，我認為每個人的實際需求和習慣不同，也沒有必要照搬別人的，隻要覆蓋瞭以上三大塊內容，起到瞭需求池管理的作用即可。

2. 優先級判斷

一般剛入行的初級產品常常直接執行領導分配的任務，但並不代表優先級判斷這件事對於初級產品不重要。需求優先級判斷這個話題，網上一搜產品文章一大堆，各種四象限法、卡諾模型等等。

但每個人處於工作不同的時間狀態，對公司及行業產品的理解層次是不一樣的，所以就算你學完瞭背熟瞭產品課程中所有的需求分析方法論、或者優先級判斷模型，你的判斷的合理程度很難跟你的領導相比。

優先級判斷屬於洞察決策層面的高級能力，不是工作技巧，它的變量太多，需要多方權衡，比如業務重要程度、緊急程度、工作量、性價比、是否匹配系統當前所處的階段、對系統的影響大小，甚至領導強勢程度等等，不同行業不同公司情況，用一套模型和公式是無法解決的。

我這裡想強調的是，不必拘泥於具體的判斷方法和公式，而是一開始就養成對自己需求池進行優先級判斷的習慣，也許一開始判斷的結果並不準確，會踩過一些坑，但隨著對業務和行業的逐漸熟悉，判斷會越來越準確。

所以我建議忘掉別人總結的公式，建立自己的判斷標準，並不斷調整優化這個標準。

三、產品方案設計

我將產品規劃設計粗暴的分為前端頁面設計和後端產品設計，這裡的後端其實不是真正意義的後端產品經理才關註的，也會包含很多前端功能邏輯層面的設計。

凡是屬於用戶可見可操作界面的部分為前端設計，不可見的邏輯及系統設計則為後端設計。

1. 前端頁面設計

交互設計領域人機交互大師雅各佈·尼爾森博士，在1995年提出的尼爾森十大可用性原則，對二十多年後今天的互聯網產品設計仍然影響深遠。

對於軟件類著重頁面設計的互聯網產品來說，我提煉瞭其中4點：

（1）簡單易理解

包括瞭文案的簡潔明瞭、功能玩法的易理解，在單個頁面內減少過多不必要的信息。

（2）操作有反饋

當用戶進行某個操作後，以合理的形式向用戶反饋目前的狀態，可能會發生什麼。

（3）操作可回退

用戶走的每一條路都不能是死胡同，應該都能讓他回到原點。

（4）功能一致性

不同位置的相同功能保持一致，保證瞭產品設計統一，用戶更易學習。

前端設計我隻總結瞭以上4點，比較適用於產品原型的交互設計，但卻是任何一個優秀的產品必不可少的核心設計原則。

2. 後端產品設計

後端設計的細節太多，沒法像前端設計原則一樣進行高度歸納，我這裡也是根據自己大大小小的項目經驗逐條進行總結，內容不夠系統，可以當做幾個關鍵點設計的參考。

（1）MECE原則，相互獨立，完全窮盡

這個基本原則相信每個產品經理都知道，它是一個能讓產品方案條理有序、不遺漏、不重復的重要標準。我這裡主要強調一下它具體體現在瞭什麼方面。

產品方案對標業務需求：

我們假設這裡的業務需求都是相對合理的需要實現的。那設計的產品方案需要對應滿足這些業務需求，不能遺漏任何一個，同時也不能讓產品方案內部出現重疊的功能，而是剛好完美的滿足瞭業務需求，也使開發的系統內部達到軟件工程上的最優解，這就叫滿足MECE原則。

需求文檔的書寫：

落實到具體的執行，需求文檔中描述功能時也需要盡量滿足這個原則。首先做到描述不遺漏，充分考慮異常流、特殊邏輯；然後需要語言精簡客觀，對同一功能和模塊不必重復贅述，對於有耦合關系的模塊，用語言上的邏輯因果、時間先後來進行描述。

（2）強化對狀態的認知

對於一個後臺系統，狀態無處不在，靈活多變的業務需求是靠一張張數據庫的表在記錄的，除瞭業務數據的記錄，狀態是非常重要的基礎。

訂單必須有狀態，用於區分不同業務環節；一個上線的活動必須要有狀態，是進行中、已暫停、還是已下線；一個員工賬號也要有狀態，是啟用中、禁用中還是已註銷。

設計一個功能或系統通常需要先繪制流程圖，而流程圖中一個個狀態的連接支撐起瞭整個功能設計的骨架，然後才是具體細節的設計。

如何正確的強化對狀態的認知和理解，我大概總結以下幾點：

狀態的獨立互斥：

這點與上面說的唯一判斷字段有點類似，但實際不是一回事。因為狀態是用於描述不同業務節點的，每個狀態要與實際業務的關鍵節點進行一一對應，狀態之間不能出現二義性，否則會出現多個狀態對應同一個業務關鍵節點，不但會造成理解混淆，還可能使系統做具體判斷時出問題。

狀態在時間維度上是穩定的：

這點其實也很好理解，一個具體業務的發展是有階段性的，而狀態就是在每個階段取一個值，各個值連接起來就串聯的業務，但如果狀態的值取在各個階段的臨界點，這就很不好描述業務瞭。

比如一個運營活動，可以用“進行中”和“已下線”兩個狀態來區分發生和不發生兩個階段，這是合理的，但如果狀態叫做“下線中”，這就不是處在一個穩定的狀態，而像一個瞬時態，到底是上線還是下線，我們從狀態命名中就感覺很模糊。

註意子狀態和組合狀態：

當業務相當復雜時，一個狀態下面還可以設置子狀態，比如單據的撤銷狀態，可以包括用戶主動撤銷、系統撤銷、人工撤銷，用於區分具體是怎麼被撤銷的。

而組合狀態的意思是在用戶側展示的狀態不單是訂單表裡存的狀態名稱，而是一個組合狀態，比如在用戶側顯示“已發貨”，其實包含瞭訂單狀態為“創建成功”、支付狀態為“已付款”、物流狀態為“已出庫”。

像比較復雜的保險訂單狀態，還會包含訂單狀態、支付狀態、續保狀態等，因此不能用一維的線性的來看待狀態。

狀態機的流轉路線：

狀態機圖的確定，基本確定瞭系統和功能主體結構，各狀態之間的起點終點、流轉路線、判斷條件決定瞭功能的玩法和限制，狀態機圖是梳理並對照實際業務的必備工具。

當業務有功能拓展時，首先查看狀態機圖是否滿足，如何調整才能滿足，已經涉及到哪些相關調整，都需要用到這個圖。

合理的狀態有利於數據統計：

當狀態的設計都按照上述原則進行，狀態與狀態之間非常清晰，這對數據統計是非常有益的，因為很多的數據統計都強依賴對狀態的定義，如果你在做數據統計的時候發現很難準確的提需求，或者發現無法按照業務需要的維度來進行統計，可以反思下系統的狀態是否合理。

3. 預留拓展性邏輯

我之前經常遇到一種情況，當我做一個功能上線之後，業務方有時會再提一個與這個非常類似的需求，有時候僅僅隻是改動很少的內容。

如果在第一次設計時並沒有預留可能的拓展性，就算隻是很少的改動，還是要排期開發和測試，特別是有的功能還需回歸測試，非常浪費開發資源，而且影響迭代速度。

這時就考驗在設計之初能否大概看出可能有的拓展性，在開發工作量幾乎不變的情況下預留一些類似的邏輯，這樣會非常便於類似功能的迭代。

舉個例子，對於一個人工審核的結論頁，有多種狀態，每種狀態下結論頁的不同模塊的元素、文案、以及對用戶的觸達文案，都是首次開發時配置好的。

首次開發時業務方提出有三種狀態，上線之後業務方說要再加一種特殊的狀態，如果事先在狀態機中預留瞭待定的狀態，隻需要把該待定狀態下頁面的元素、文案、對用戶的觸達進行設置即可，改動的工作量很小，可以快速的上線。

不過值得註意的一點是，在預留拓展性時盡量保證首次開發的工作量影響很小，如果為瞭暫時使用不到的預留需求消耗過多開發資源，就有點本末倒置瞭。

最好的針對復制一份代碼、預留一個狀態這種相似功能進行考慮。

4. 對變量的抽象

對變量的抽象是一種模塊化思維，能夠減少很多重復的工作量，提高後期的開發效率，我將分成兩種情況來描述。

一種是當多個頁面都用到同一個內容時，該內容應該被抽象為公共變量，供各頁面調用。

比如一個常用聯系人組件包含姓名、證件類型、證件號碼、性別、出生日期這五要素，那麼可以把這五要素設置成一個公共變量模塊，在不同產品下單需要用到時直接調用即可。

如果有的產品下單時隻需要用到姓名、證件類型、證件號碼三要素，則可以把五要素的變量模塊拆細為五個變量元素，這樣可以達到最大自由度的組合。

另一種情況是兩個頁面絕大部分內容相同，隻有幾個元素有差異時，這幾個有差異的元素應該抽象為配置變量，做成一個配置文件或者管理後臺，這樣在調整該配置時就不用再寫代碼。

有的同學可能對配置文件不太懂，它可以理解為一段未被編譯器編譯的配置代碼，是對一個軟件運行時狀態的本地儲存形式，可以實現對軟件靈活的實時調整。

比如同樣一個商品的詳情頁需要在A平臺是紅色背景，有評論模塊，在B平臺是綠色背景，不要評論模塊。

如果事先將背景色、有無評論模塊這兩個變量做成配置項，隻需要更改配置文件或在管理後臺做相應勾選即可。

5. 時刻考慮系統的靈活性

講完兩種基本的變量抽象方式，我再講講整個系統的靈活性。

比如一個普通的商品詳情頁，如果隻給你1天時間從0到1來做這個頁面，你會把頁面的所有元素、邏輯寫清楚，找到前端後端開發按照你的邏輯進行實現，然後發佈上線。

如果你想修改一個banner圖，必須要找前端開發從代碼層面幫你換圖，然後再發佈，這時我們認為這個頁面是非常不靈活的。

因此你把banner、標簽、價格、尺碼分類等等都抽象成瞭配置變量，就可以在管理後臺靈活的調整這些內容，無需再發佈，看起來非常靈活瞭。

但是當這個頁面需要對不同商傢顯示不同商品時，你就需要再把這整個頁面做成配置項，對每一個商傢可以單獨配置一套商品詳情頁。

接下來業務需求再進一步演化，每個商傢想要自己去配置自己的商品詳情頁，這時你還需要把商品詳情頁的配置功能做成一個商傢管理後臺，讓商傢自己去靈活設置，這時候單是這個商品詳情頁就已經很復雜瞭。

如果每個商傢還要對自己的員工分別配置權限，有的員工隻能修改banner圖和名稱，有的員工可以修改商品sku、價格等等，那你還需要把這個商傢的商品詳情頁配置功能結合賬號權限再細分配置，讓商傢自己靈活勾選什麼員工可以操作什麼權限。

我這裡隻是簡單的描述瞭一下電商平臺商品詳情頁的配置演化路徑，就可以看出，當業務需求越來越細化，對系統靈活性的要求就越來越高，也意味著系統的復雜程度越來越高。

為瞭盡可能充分的滿足業務需求，我們需要時刻註意系統的靈活性，在每一版迭代的時候避免太多寫死的邏輯。

6. 總結遇到的異常流

每做一個項目，在上線之後可能都會遇到反饋的線上問題，特別是一些在設計時考慮不全的異常邏輯，會在用戶真正使用的時候暴露出來。

做完項目遇到這種情況並不可怕，因為人無完人，產品經理不是神，設計之初漏掉一些異常流是很正常的，但如果每次項目都漏掉一些，或者同樣的異常問題多次出現，這就是產品經理的問題瞭。

我們可以認為，在業務拓展沒那麼快的情況下，軟件層面的設計的異常流是很有限的，隻要遇到一個就把它解決掉，總會消滅幹凈的。

產品經理每天的工作時間，可能會有一部分都是在處理自己留下的坑，但在填坑的時候我們能否不僅僅隻為瞭填坑，能否思考是怎麼漏掉這些異常流的，並一一總結出來，這樣也許能大大提升產品設計的完整性。

四、項目管理

項目管理之前應該先判斷該項目的類型，不同的項目推進和管理的方式區別很大，根據項目大小與任務並行程度，我分為以下三類：

1. 周期較長的大項目管理

對於單個部門內部開發周期較長的項目（超過2周），我總結有以下項目管理的關鍵點：

（1）提前溝通開發方案

一般較大項目功能比較復雜，因此整體方案設計時需要預先跟開發人員溝通，明確一些關鍵限制因素和影響點，避免需求評審時方案不可行，或者調整太大，在評審會上難以達成一致。

（2）關註功能先後順序

提前關註項目中不同功能的相互依賴性以及對外部系統依賴性，根據功能依賴的先後順序確定項目的排期節奏，提高排期銜接程度，避免一個功能開發完很久之後還不能與其他功能聯調，浪費開發資源。

（3）對項目的強推動力

每日跟進關鍵點的結果，盡早發現風險（日報、周報、晨會等形式）。

（4）項目復盤總結

項目完成後回顧項目過程中哪些過程效率有待提高、哪些過程安排的不夠合理，如何避免在下一個項目中繼續出現。

2. 跨部門跨公司合作的項目管理

跨部門和跨公司合作的項目，開發量不一定很大，但由於牽連方較多，比起團隊內開發有瞭更多的不確定因素，項目容易延期，因此在上述大項目的管理基礎上需要額外關註這幾點：

（1）找到合作關鍵點

不管是跨部門還是跨公司合作，首先要明確對雙方的關鍵利益點，並強調合作對對方的好處，才能獲得對方的積極支持，否則很容易被踢皮球。

（2）書面確認詳細事項

跨部門和跨公司合作，一般都是遠程電話溝通，因此對會議上達成一致的點需要書面記錄郵件至對方，對達成一致的點也需要記錄並積極跟進對方的最新答復。

這一點主要是為瞭提高需求的確定性，明確雙方職責，避免因為溝通沒有記錄影響項目開發進度。

3. 多個小項目並行的項目管理

對於互聯網的敏捷開發模式，超過兩三周的大項目少有，多個小項目並行才是更常見的狀態，這裡的小項目其實是單個很明確的需求，粒度比較小，這種狀態下產品經理一周可能同時在跟進十多個需求在開發狀態，這對多項目並行的考驗很大，我總結瞭以下幾點：

（1）更合理的排期節奏

由於項目太多，為瞭避免同一天過多需求同時在開發或者在測試，在排期的時候盡量均勻的分佈，這樣保證在一些需求已經進入測試或已發佈，另外的項目剛進入開發，避免某一天的事情太多。

（2）每日tips跟進每個項目的狀態

首先需要實時記錄這些並行的需求的開發狀態、開發人員，然後每天早晚跟對應的開發人員跟進需求狀態，及時解決相關問題。

（3）小需求歸檔

小需求上線一時爽，後期維護痛苦不已。每個小需求在開發過程中是獨立的，但對於整個產品來說它是一個個的迭代，隻有及時將這些迭代歸檔到對應的功能模塊，才能後續方便的瞭解查詢當前線上的產品規則是怎樣的。否則後期連自己都忘瞭到底最新的迭代是什麼，這個坑誰踩過誰就知道有多苦。

五、溝通技巧

與項目管理類似，溝通之前我們要對溝通的對象進行分類，不同溝通對象需要註意的事項是不一樣的。

1. 與合作方溝通

（1）溝通方式的合理選擇

一般與合作方很難面對面溝通，大多是電話和在線溝通，因此對於不同的事項要選擇合適的溝通方式。

比如首次確認合作內容，需要電話詳細說明合作細節，然後書面記錄達成共識的事項；確認完合作內容後，有小的疑問點可以在線溝通。

（2）催進度也有技巧

有依賴合作方確認的事項或開發進度時，催進度是最頻繁的事。但是催進度需要包含幾個關鍵因素才能起到好的效果。

首先是良好的態度，對對方的尊稱是必須的，就算對方態度比較冷淡也需要保持著熱臉貼冷屁股的熱情，因為在工作中，合作的順利完成才是最重要的，這也是職場人的必備素質。

其次是明確具體內容和時間點，比如當希望對方對某個點反饋結果時，反面教材是這樣的“請問你們這個功能可以快一點開發嗎？”、“麻煩盡快確認下XXX這個點哦”，這樣的詢問都沒有明確時間點，對方感受不到壓力，催進度的效果不明顯。

正確的方式是“請問某某負責人，針對這個三點事項（一一列舉），您可以在今天下午5點之前確認嗎，麻煩您瞭”。

再次是要找對關鍵人確認，比如你一直跟對方的一個開發人員催進度沒什麼用，需要直接找到對方的產品或項目負責人，甚至是對方領導。

2. 與需求方溝通

（1）搞清需求方的本質訴求

需求方可能是運營、銷售、客服，他們會根據自己當前遇到的問題直接跟產品經理提需求。

大傢都知道快馬和汽車的故事，需求方需要一匹快馬，我們是直接按他說的給他快馬，還是思考他提出這個需求的本質訴求是什麼，能否轉化成另一個需求，是否還有更合理的解決方案？

如果來一個需求就做一個，缺乏對需求背後的思考，這不叫產品經理，叫需求實現師。

（2）明確產品和需求方的邊界

當與需求方長期合作時，需要形成一個良好的溝通模式，明確各自的職責范圍和邊界。

比如與運營合作上線一個項目，哪些內容是運營需要明確的，哪些內容是產品可以有施展空間的，這個過程中，產品不能隨意修改運營確認的規則，但也不能放任需求的不斷變化，不能讓運營直接幹涉產品系統層面的影響。

優雅的把握好邊界，相互尊重彼此的工作內容，能夠減少很多扯皮，讓合作效率更高。

3. 與開發溝通

對於初級產品經理偏重於項目執行，日常溝通的對象最多的一定是開發人員，如果溝通太少，要麼是你需求文檔完美無缺（幾乎不可能），要麼是你不夠主動。

（1）跟開發大佬和開發小弟溝通的區別

開發大佬就是某條線的技術負責人，在有重大功能迭代的時候，可能會需要先跟他對方案。

與開發大佬溝通時最好是提前想好靠譜的方案，而不是偏差太大的天馬行空，這樣避免浪費雙方時間，也能提高大佬對你的信任。

開發小弟就是除瞭大佬之外的開發同學，與他們溝通的核心技巧是要建立利益共同體，因為他們是具體做需求的人，你需要把需求的背景、實現後的價值講給他們，以及上線之後的效果也要多同步給他們，提高他們的自豪感。

開發小弟也需要成功的項目來體現自己的價值，讓他們感受到你們是一條線上，他們也會盡心盡力幫助把系統做的更好，開發過程中改點小需求也就不在話下瞭。

當然，這些技巧是要建立在需求文檔質量合格的前提下。

（2）預期管理

產品立項時、項目開發過程中，對開發人員的預期管理是很有必要的。

有的開發覺得這個項目不是很重要，重視程度不夠，最後導致延期；

有的開發對這個功能上線期待很高，最後上線後效果並不理想；

有的開發在立項時認為這個項目開發這些功能需要2周，但中途你又加瞭幾個小需求導致開發時間壓縮，開發人員非常不滿。

這些都是實際的情況與開發人員預期情況產生較大不一致造成的。因此一些關鍵的事項，需要跟開發人員預期保持一致，我主要總結以下幾點：

項目目標和價值：

比如一個非常重要的項目，需要在2周內上線，預計可以獲取新增用戶10萬個，這些明確的項目目標和價值需要在立項時及時同步給開發人員，有時候你的重視程度會影響開發的投入程度。

關鍵時間節點：

開發時間、轉測時間、上線時間，幾個關鍵的節點要時刻強調，建議直接寫在項目群公告中，避免有的開發同學遺漏忽略。

風險和備用方案：

項目可能產生的風險和備用解決辦法，在立項時也應該跟開發同學保持同步，一些外部的不可控因素可能會產生什麼影響。

比如一個項目可能臨時更換合作方這種突發事項，提前同步可以讓大傢心裡都有底，不至於發生時產生太多不利於合作的情緒。

（3）跟開發的工作氛圍建設

除瞭工作中，工作之餘與開發同學經常一起玩，開開玩笑，建立良好的工作氛圍和私人關系也很有必要，會讓工作的合作效率更高。

也許一個小需求對於關系一般太嚴肅的開發來說需要排期才能處理，但關系融洽的開發可能隨手就幫你解決瞭。

六、方法論建設

1. 建立自己的能力模型

產品經理從第一天開始工作起，基於自己的工作內容和所在領域，就可以開始規劃自己的能力模型，並不斷的完善，這樣一個能力模型既與工作內容相關，又是獨立於當前的工作內容，是抽象出來的通用的能力模型，這樣才能保證自己在產品經理這個崗位中的競爭力。

關於如何建立自己的能力模型，可直接查看我的這篇文章。

2. 註重思維方式的迭代

根據我個人建立的產品能力模型，相比於各種經驗技巧方法論，我認為最底層的是思維方式，優秀的思維方式可以讓你在面對不同工作內容時舉一反三。

而產品經理到底要具備哪些思維方式？

這個問題我建議你也不要看別人直接輸出的結論文章，我給出兩點建議：

閱讀經典的評分高的思維方式書籍，相比於產品同行寫的產品思維的文章，優秀的思維方式書籍的含金量更高且內容更系統，更有利於對思維方式的學習。如《思考，快與慢》、《窮查理寶典》、《用理工科思維理解世界》。

根據自己實際的工作經歷，復盤做得不好的項目各個環節欠缺哪些思考，回頭看如何思考可以做得更好。而對於做得好的項目又是怎麼思考的。以此進行演繹，形成自己認為重要的思維方式。

本文由 @拾二 原創發佈於人人都是產品經理。未經許可，禁止轉載。

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