高階產品經理常用的七種思維方式
最近系統的總結了高階產品經理所應當具備的六種思維方式，給小夥伴們也作個參考。
思維方式一：本源思維
本源思維也就是刨根問底、實事求是的思維。高階產品經理要善於思考事物的背後邏輯以及問題的根本原因，不能被表面的現象所迷惑。
我們在很多地方可能都看到過類似的表述：做產品經理要善於獨立思考。——起初我總是不以為然，但等我真正的上手產品工作兩年之後，才發現“獨立思考”真的很重要——在這個人人都自以為是產品經理的時代，是個人都會向我們發表一大堆建議與意見，如果我們缺少獨立思考的能力，就會被他人的言辭以及事物的表面現象所矇蔽。
而獨立思考最核心的就是“透過現象看本質”。 舉個例子：很多使用者都會吐槽“淘寶”APP設計的不夠簡約、過於眼花繚亂，淘寶在購物車頁面、訂單頁面、物流頁面、結算頁面等地方都會新增“你可能還喜歡”的相關商品推薦，實在是有過度營銷的嫌疑。但是作為產品經理我們就要思考了：淘寶這麼做的目的是什麼？它是從哪些維度來思考這個事情的？它到底是有損使用者體驗，還是會提升相關轉化資料？等等——為了搞清楚這些問題，我曾專門請教過一個阿里的資深運營，對方給出的答案是：阿里經過大資料分析發現，使用者在瀏覽某個商品頁面六次以後會大幅度的提升購買意願，所以淘寶才會想盡一切辦法的新增“你可能還喜歡”的商品推薦，目的就是讓使用者儘快的達到六次瀏覽，從而提升產品的購買轉化率。而且實際的資料已經證明這個做法對於提升使用者的購買轉化率非常有效。
本源思維需要經常性的思考以下幾個問題：
1 看到的究竟是事物的現象還是原因？
2 這件事情的原因到底有哪些？根本原因又是什麼？
3 如何確定這是根本原因？
4 如何去建立假設？如何去驗證？如何去優化？用什麼方法？
……
思維方式二：階段性思維
階段性思維可以通用到很多事情上，小到個人的提升、大到國家的發展都需要分清楚階段。在不同的階段需要做不同的事情，有些事情在某些階段做是正確的，但是跨越了這個階段去做就可能變成了錯誤的。
傳統的產品生命週期理論將產品大致分為了四個階段：啟動階段、成長階段、成熟階段和衰退階段。到了網際網路時代，可能部分產品並不會進入“衰退階段”，而是演化成了“生態系統”（比如微信、QQ、支付寶等）。弄清楚自己產品當前所處的的階段，才能搞清楚當前階段的重點、做事情才能有的放矢。
很多初創團隊的產品經理喜歡尋找對標產品，有時候會誤把一些國民級的產品拿來和自己對標，讓人啼笑皆非（我就聽我家程式員說過，他上家公司的產品經理在開發一個新的閱讀產品時，要求他們照抄”微信閱讀“，這一決定直接激怒了所有程式設計師，最終遭到程式設計師們的聯合抵制）。要知道支付寶、微信、淘寶、高德地圖等等國民級的產品會精細化的打磨每一個體驗細節，這是因為這些產品已經進入成熟期和穩定期，產品本身的需求已經被驗證、且使用者體量非常大，細節的打磨對於提升產品資料也非常的重要。而創業團隊的產品大多處於啟動初期，這個階段的主要目的是進行需求的驗證，花大量時間和精力在產品的打磨上就有點本末倒置了。所以我們當然可以去研究和分析一些國民級的產品，但是不分階段的去效仿和照搬，就是真愚蠢了。
階段性思維具體需要我們思考以下幾個問題：
1 當前產品處於什麼階段？
2 當前階段的目標是什麼？
3 當前階段的重點是什麼？非重點是什麼？
……
思維方式三：顆粒度思維
顆粒度不同東西，可能是不同的事物。舉個例子：我上初中時，QQ空間特別風靡，當時QQ空間的說說、日誌等產品，限制的字數大概是10000字。同時期的新浪部落格，限制字數是20000字。——通過這些字數限制可以推斷出當時的產品更強調內容表達的完整性和連貫性。後來隨著網際網路的快速發展以及移動網際網路的興起，人們沒有那麼多時間和耐心去寫長內容了，碎片化的“微博”就應運而生，字數限制是140字。可以看到，同樣是內容的傳播，不同的字數限制（顆粒度）就是不同的產品，其目標群裡、傳播度可能就完全不同了。
作為產品經理也有必要思考自己所負責產品的顆粒度，因為顆粒度和產品的嘗試成本是相關的，寫一篇10000字的部落格，需要我們靜下心來，找個安靜的地方梳理思緒，甚至還需要打個草稿。但是微博的140字就非常簡單了，隨時劃開手機就可以發表。
就拿我說從事的心理諮詢服務行業來說，通常的線下心理諮詢服務都是50分鐘/次，開始我做產品時也是堅守的50分鐘/次的設定，後來為了降低嘗試成本、啟用需求，在經過廣泛的調研和分析後，我把產品的首次嘗試時間改為了15分鐘/次，願意嘗試的使用者比例瞬間就擴大了1倍以上。——這告訴我們，同樣的內容，顆粒度變了可能產品的本質就變了。
顆粒度思維需要我們具體思考以下幾個問題：
1 你所處的行業當前有哪幾種顆粒度的產品？
2 你所做的產品的顆粒度是什麼？
3 如何通過變化顆粒度改變產品的形態？
……
思維方式四：精確化思維
稍微觀察一下，我們就會發現：日常生活中，人們普遍喜歡使用概括性的詞彙：比如“好好工作”、“能力還不夠”、“體驗需要更好點”、“設計感不是那麼強”等等。人們為什麼這麼喜歡”概括性的表達“了？我分析原因大概有以下幾點：1、空泛性的詞彙所需要的思考成本較低、表達難度較小；2、空泛的詞彙更容易以偏概全、讓人站在道德制高點上，產生優越感；3、我們從小都是在空泛的詞彙中長大，潛移默化的形成了這種溝通的模式。
作為產品經理，我們會收到來自各方的資訊，這個時候就必須用精確化的思維對資訊進行分析和確認。舉個例子：運營向我們反饋“XX使用者登入不APP，需要讓技術解決一下“。這個時候我們就應當詢問什麼時間登入不上的？使用者的是什麼手機型號？手機型號的系統版本？軟體的版本？登入不上是直接閃退還是有錯誤提示？等等。只有把問題搞清楚了、定義清楚了，再去解決問題，才會比較高效。
在表達的時候，我們也應當儘可能的做到精確，我發現很多人在表述的時候為了強調自己的觀點會用“誇張”的手法去描述，這樣不僅不利於實際問題的討論、也會給人形成一種不太靠譜的印象。
精確化思維需要我們從以下幾個維度去思考問題：
1 問題的具體定義是什麼？
2 問題的描述時、個人的表達時是否做到了足夠的精確？
3 他人向你傳遞的資訊是精確的嗎？其中有誇張的成分嗎？
4 在討論時是否是精確的就事論事，而非空泛的以偏概全？
……
思維方式五：最小化產品思維
最小化產品的概念是矽谷創業家Eric Rise在其著作 《精益創業》中提出來的，後被網際網路公司廣泛的接受和應用。這可以說是產品經理的基礎性思維之一，適用於很多種情況：雙方針對產品的某些方面爭執不下時；自己有了某些靈感或者想法，但不知是否應當進行大規模推行時；老闆給了指令，自己有反對意見，但又不得不執行時……都可以進行MVP嘗試。
尤其是當我們身處於創業團隊，時間成本是很高的，這時我們更應當有最小化產品的思維，在很多產品的功能上進行小步快跑、快速迭代、蒐集反饋、驗證假設，而儘量避免閉門造車。這種思維在很多文章裡有相關的論述，我就不再展開講了，作為產品經理，如果你的大腦中還不具備這種思維方式，你應該好好反省了。
思維方式六：系統性思維
系統性思維就是從整體的角度對事物進行全面的、多維度的、深入的分析，這是高階產品經理必須掌握的一種思維方式。教育心理學在對“專家”和“新手”的對比研究時發現，他們兩者的本質區別是：專家的思維方式是系統性的、全面的，而新手的思維方式則是零散的、片面的。我們作為產品經理，是整個產品、甚至可以說是整個行業的專家，也應當建立自己極強的專業性。
舉個例子：我打算把平臺上某個產品的品類價格進行上漲，普通的人可能僅僅考慮到”價格上漲後對使用者購買行為的可能會產生負面影響“這個層面就夠了。但是作為專家，我們應當有自己系統化的、結構化的思考：該品類價格上漲對平臺收益的影響？對商家收益的影響？對平臺整體價格政策的影響？是否對競品產生了有效打擊？對其他臨近品類的影響？對新使用者購買行為的影響？對老使用者復購行為的影響？調整後資料產生負面變化時的應對策略？是否需要先進行灰度測試？……等等。
高階產品經理務必做到系統的、全面的、深入的思考和分析。我通常用到的系統性思維的方法是“因素分析法”，因素分析法是指將一個複雜的事物拆解成不同的因素，然後通過分析該事物在每一個因素上的情況，進而得出整體性的結論（我自己的定義，不理解的可以查詢一下相關文獻）。
系統性思維需要我們具體思考以下幾個問題：
1 這個問題可以拆解為哪些因素？每個因素需要考慮的層面又有哪些？
2 你在考慮問題時，相關的維度是否考慮全面了？
……
思維方式七：共識思維
在產品之路上走的越久就越讓我意識到“共識”的重要性——一個專案的成功絕不是一個人的單打獨鬥，而是一個團隊各司其職、通力合作的結果。而是否有明確的產品共識——會從根本上影響到整個團隊的工作效率。
很多時候我們說自己提出的方案其他部門不配合或者不支援，主要原因可能也在於相互之間沒有達成共識。可能你理解的行業是一回事，他理解的行業又是一回事，之間有大量的分歧和不同點。這就導致表面上我們好像都在朝著一個方向走，實際上對於道路的選擇和發展的路徑有著完全不同的認知和理解，簡直就是同床異夢。
我們每個人的生活經歷、工作經驗都是不同的，這也就導致我們對於同一個事物會有不同的看法和觀點。我們不要一開始就期待共識——很多共識的形成不是一個結果，而是一個過程，大家在理性的討論中反覆的加深思考、進行多種嘗試和驗證，才有最終共識的形成。
比如在我們公司老闆很喜歡干預產品設計，我剛來公司時大概花了接近兩個月的時間去和老闆溝通一個觀點：管理層決定產品行業和商業模式，設計師和產品經理決定產品互動和體驗細節。大概兩個月之後，這一點才真正的形成團隊內部的共識，此後管理層再也沒幹預過產品的細節，設計師的積極性才被真正的調動起來。
又比如很多產品經理和技術溝通的內容都是功能如何實現、技術方案如何選擇，但是針對於為什麼這麼做、有沒有更好的方案以及行業的動向是怎樣的、使用者的反饋是怎樣的，這些方面產品經理基本上不和技術溝通（可能很多人認為技術不懂這些，沒必要對牛彈琴）。但是隨著產品工作經驗的增多，我會越來越花時間和技術溝通這些內容，把一些問題也拋給他們去思考，最後再經過討論達成共識，這樣會從根本上提升開發的一些效率和對需求的接納程度。讓技術人員不僅僅的去做，而是帶著思考、帶著想法、帶著共識去做。
實際中我們會發現，很多事情就算我們充分溝通、充分討論，也未必會形成共識。這裡需要注意一個點：共識的目的不是為了證明自己是對的，而是為了更好的做事情。 在討論的時候儘可能的以開放的心態去溝通，避免過於堅持己見。在一些需要形成共識的事情上，不要一上來就給出結論，這樣會顯得自己過於強勢，也降低了他人表達觀點的意願。可以先把問題丟擲來，相互的討論和溝通，最後才是達成共識。
那麼如果一件事情未形成共識，我們到底是做還是不做呢？實際上還是要做的，因為產品的發展本身就帶有很多的不確定性，我們的原則是儘可能的達成共識，但並不追求完全的意見一致。
好了，熬了幾個晚上寫了上面一堆話，就是希望把自己的經驗和總結分享出來，儘可能的幫助到其他小夥伴。產品經理的工作中有相當大的一部分時間都是用來思考的，希望我上面所寫的內容對小夥伴們有啟發，也歡迎大家和我一起討論。
旺仔九號，人人都是產品經理專欄作家。心理學碩士，微訊號：Jackaniy（新增請說明來意）。