高級產品經理常用的七種思維方式

本源思維

我們在很多地方可能都看到過類似的表述：做產品經理要善於獨立思考。

起初我總是不以為然，但等我真正的上手產品工作兩年之後，才發現“獨立思考”真的很重要。

在這個人人都自以為是產品經理的時代，是個人都會向我們發表一大堆建議與意見，如果我們缺少獨立思考的能力，就會被他人的言辭以及事物的表面現象所蒙蔽。而獨立思考最核心的就是“透過現象看本質”。

本源思維也就是刨根問底、實事求是的思維。

高級產品經理要善於思考事物的背後邏輯以及問題的根本原因，不能被表面的現象所迷惑。

舉個例子：

很多用戶都會吐槽“淘寶”APP設計的不夠簡約、過於眼花繚亂，淘寶在購物車頁面、訂單頁面、物流頁面、結算頁面等地方都會添加“你可能還喜歡”的相關商品推薦，實在是有過度行銷的嫌疑。

但是作為產品經理我們就要思考了：

淘寶這麽做的目的是什麽？

它是從哪些維度來思考這個事情的？

它到底是有損用戶體驗，還是會提升相關轉化數據？

等等。

為了搞清楚這些問題，我曾專門請教過一個阿里的資深運營，對方給出的答案是：

阿里經過大數據分析發現，用戶在瀏覽某個商品頁面六次以後會大幅度的提升購買意願，所以淘寶才會想盡一切辦法的添加“你可能還喜歡”的商品推薦，目的就是讓用戶盡快的達到六次瀏覽，從而提升產品的購買轉化率。而且實際的數據已經證明這個做法對於提升用戶的購買轉化率非常有效。

本源思維需要經常性的思考以下幾個問題：

看到的究竟是事物的現象還是原因？

這件事情的原因到底有哪些？根本原因又是什麽？

如何確定這是根本原因？

如何去建立假設？如何去驗證？如何去優化？用什麽方法？

……

階段性思維

階段性思維可以通用到很多事情上，小到個人的提升、大到國家的發展都需要分清楚階段。

在不同的階段需要做不同的事情，有些事情在某些階段做是正確的，但是跨越了這個階段去做就可能變成了錯誤的。

傳統的產品生命周期理論將產品大致分為了四個階段：啟動階段、成長階段、成熟階段和衰退階段。

到了互聯網時代，可能部分產品並不會進入“衰退階段”，而是演化成了“生態系統”（比如微信、QQ、支付寶等）。

弄清楚自己產品當前所處的的階段，才能搞清楚當前階段的重點、做事情才能有的放矢。

很多初創團隊的產品經理喜歡尋找對標產品，有時候會誤把一些國民級的產品拿來和自己對標，讓人啼笑皆非。

我就聽我家程式員說過，他上家公司的產品經理在開發一個新的閱讀產品時，要求他們照抄“微信閱讀”，這一決定直接激怒了所有程式員，最終遭到程式員們的聯合抵製。

要知道：支付寶、微信、淘寶、高德地圖等等國民級的產品會精細化的打磨每一個體驗細節，這是因為這些產品已經進入成熟期和穩定期，產品本身的需求已經被驗證、且用戶體量非常大，細節的打磨對於提升產品數據也非常的重要。

而創業團隊的產品大多處於啟動初期，這個階段的主要目的是進行需求的驗證，花大量時間和精力在產品的打磨上就有點本末倒置了。所以我們當然可以去研究和分析一些國民級的產品，但是不分階段的去效仿和照搬，就是真愚蠢了。

階段性思維具體需要我們思考以下幾個問題：

當前產品處於什麽階段？

當前階段的目標是什麽？

當前階段的重點是什麽？非重點是什麽？

……

顆粒度思維

顆粒度不同東西，可能是不同的事物。

舉個例子：

我上初中時，QQ太空特別風靡，當時QQ太空的說說、日誌等產品，限制的字數大概是10000字。同時期的新浪部落格，限制字數是20000字。

——通過這些字數限制可以推斷出當時的產品更強調內容表達的完整性和連貫性。

後來隨著互聯網的快速發展以及移動互聯網的興起，人們沒有那麽多時間和耐心去寫長內容了，碎片化的“微博”就應運而生，字數限制是140字。

可以看到，同樣是內容的傳播，不同的字數限制（顆粒度）就是不同的產品，其目標群裡、傳播度可能就完全不同了。

作為產品經理也有必要思考自己所負責產品的顆粒度，因為顆粒度和產品的嘗試成本是相關的，寫一篇10000字的部落格，需要我們靜下心來，找個安靜的地方梳理思緒，甚至還需要打個草稿。

但是微博的140字就非常簡單了，隨時劃開手機就可以發表。

就拿我說從事的心理谘詢服務行業來說，通常的線下心理谘詢服務都是50分鐘/次，開始我做產品時也是堅守的50分鐘/次的設定，後來為了降低嘗試成本、激活需求，在經過廣泛的調研和分析後，我把產品的首次嘗試時間改為了15分鐘/次，願意嘗試的用戶比例瞬間就擴大了1倍以上。

——這告訴我們，同樣的內容，顆粒度變了可能產品的本質就變了。

顆粒度思維需要我們具體思考以下幾個問題：

你所處的行業當前有哪幾種顆粒度的產品？

你所做的產品的顆粒度是什麽？

如何通過變化顆粒度改變產品的形態？

……

精確化思維

稍微觀察一下，我們就會發現：日常生活中，人們普遍喜歡使用概括性的詞匯：比如“好好工作”、“能力還不夠”、“體驗需要更好點”、“設計感不是那麽強”等等。

人們為什麽這麽喜歡”概括性的表達“了？

我分析原因大概有以下幾點：

空泛性的詞匯所需要的思考成本較低、表達難度較小；

空泛的詞匯更容易以偏概全、讓人站在道德制高點上，產生優越感；

我們從小都是在空泛的詞匯中長大，潛移默化的形成了這種溝通的模式。

作為產品經理，我們會收到來自各方的資訊，這個時候就必須用精確化的思維對資訊進行分析和確認。

舉個例子：

運營向我們反饋“XX用戶登錄不APP，需要讓技術解決一下“。

這個時候我們就應當詢問：什麽時間登錄不上的？用戶的是什麽手機型號？手機型號的系統版本？軟體的版本？登錄不上是直接閃退還是有錯誤提示？等等。

只有把問題搞清楚了、定義清楚了，再去解決問題，才會比較高效。

在表達的時候，我們也應當盡可能的做到精確，我發現很多人在表述的時候為了強調自己的觀點會用“誇張”的手法去描述，這樣不僅不利於實際問題的討論、也會給人形成一種不太靠譜的印象。

精確化思維需要我們從以下幾個維度去思考問題：

問題的具體定義是什麽？

問題的描述時、個人的表達時是否做到了足夠的精確？

他人向你傳遞的資訊是精確的嗎？其中有誇張的成分嗎？

在討論時是否是精確的就事論事，而非空泛的以偏概全？

……

最小化產品思維

最小化產品的概念是矽谷創業家Eric Rise在其著作《精益創業》中提出來的，後被互聯網公司廣泛的接受和應用。

這可以說是產品經理的基礎性思維之一，適用於很多種情況：雙方針對產品的某些方面爭執不下時；自己有了某些靈感或者想法，但不知是否應當進行大規模推行時；老闆給了指令，自己有反對意見，但又不得不執行時……都可以進行MVP嘗試。

尤其是當我們身處於創業團隊，時間成本是很高的，這時我們更應當有最小化產品的思維，在很多產品的功能上進行小步快跑、快速迭代、搜集反饋、驗證假設，而盡量避免閉門造車。

這種思維在很多文章裡有相關的論述，我就不再展開講了；作為產品經理，如果你的大腦中還不具備這種思維方式，你應該好好反省了。

系統性思維

系統性思維就是從整體的角度對事物進行全面的、多維度的、深入的分析，這是高級產品經理必須掌握的一種思維方式。

教育心理學在對“專家”和“新手”的對比研究時發現，他們兩者的本質區別是：專家的思維方式是系統性的、全面的，而新手的思維方式則是零散的、片面的。

我們作為產品經理，是整個產品、甚至可以說是整個行業的專家，也應當建立自己極強的專業性。

舉個例子：

我打算把平台上某個產品的品類價格進行上漲，普通的人可能僅僅考慮到”價格上漲後對用戶購買行為的可能會產生負面影響“這個層面就夠了。

但是作為專家，我們應當有自己系統化的、結構化的思考：

該品類價格上漲對平台收益的影響？對商家收益的影響？對平台整體價格政策的影響？

是否對競品產生了有效打擊？對其他臨近品類的影響？對新用戶購買行為的影響？對老用戶複購行為的影響？

調整後數據產生負面變化時的應對策略？是否需要先進行灰度測試？

等等。

高級產品經理務必做到系統的、全面的、深入的思考和分析。我通常用到的系統性思維的方法是“因素分析法”，因素分析法是指將一個複雜的事物拆解成不同的因素，然後通過分析該事物在每一個因素上的情況，進而得出整體性的結論（我自己的定義，不理解的可以查詢一下相關文獻）。

系統性思維需要我們具體思考以下幾個問題：

這個問題可以拆解為哪些因素？每個因素需要考慮的層面又有哪些？

你在考慮問題時，相關的維度是否考慮全面了？

……

共識思維

在產品之路上走的越久就越讓我意識到“共識”的重要性——一個項目的成功絕不是一個人的單打獨鬥，而是一個團隊各司其職、通力合作的結果。

而是否有明確的產品共識——會從根本上影響到整個團隊的工作效率。

很多時候我們說自己提出的方案其他部門不配合或者不支持，主要原因可能也在於相互之間沒有達成共識。

可能你理解的行業是一回事，他理解的行業又是一回事，之間有大量的分歧和不同點。這就導致表面上我們好像都在朝著一個方向走，實際上對於路線的選擇和發展的路徑有著完全不同的認知和理解，簡直就是同床異夢。

我們每個人的生活經歷、工作經驗都是不同的，這也就導致我們對於同一個事物會有不同的看法和觀點。

我們不要一開始就期待共識——很多共識的形成不是一個結果，而是一個過程，大家在理性的討論中反覆的加深思考、進行多種嘗試和驗證，才有最終共識的形成。

比如：

我們公司老闆很喜歡乾預產品設計，我剛來公司時大概花了接近兩個月的時間去和老闆溝通一個觀點：管理層決定產品行業和商業模式，設計師和產品經理決定產品互動和體驗細節。

大概兩個月之後，這一點才真正的形成團隊內部的共識，此後管理層再也沒乾預過產品的細節，設計師的積極性才被真正的調動起來。

又比如很多產品經理和技術溝通的內容都是功能如何實現、技術方案如何選擇，但是針對於為什麽這麽做、有沒有更好的方案以及行業的動向是怎樣的、用戶的反饋是怎樣的，這些方面產品經理基本上不和技術溝通（可能很多人認為技術不懂這些，沒必要對牛彈琴）。

但是隨著產品工作經驗的增多，我會越來越花時間和技術溝通這些內容，把一些問題也拋給他們去思考，最後再經過討論達成共識，這樣會從根本上提升開發的一些效率和對需求的接納程度。讓技術人員不僅僅的去做，而是帶著思考、帶著想法、帶著共識去做。

實際中我們會發現，很多事情就算我們充分溝通、充分討論，也未必會形成共識。

這裡需要注意一個點：共識的目的不是為了證明自己是對的，而是為了更好的做事情。

在討論的時候盡可能的以開放的心態去溝通，避免過於堅持己見。在一些需要形成共識的事情上，不要一上來就給出結論，這樣會顯得自己過於強勢，也降低了他人表達觀點的意願。

可以先把問題拋出來，相互的討論和溝通，最後才是達成共識。

那麽如果一件事情未形成共識，我們到底是做還是不做呢？實際上還是要做的，因為產品的發展本身就帶有很多的不確定性，我們的原則是盡可能的達成共識，但並不追求完全的意見一致。

總結

好了，熬了幾個晚上寫了上面一堆話，就是希望把自己的經驗和總結分享出來，盡可能的幫助到其他小夥伴。

產品經理的工作中有相當大的一部分時間都是用來思考的，希望我上面所寫的內容對小夥伴們有啟發，也歡迎大家和我一起討論。

———— / END / ————