對於“思維模式”這一充滿重要性與玄學的概念來說，如何定義、如何將其轉化為真實可感的事物呢？文中，筆者將結合自己的觀察與思考，聊聊他眼中的大佬是如何理解這一概念的。
什麼是思維模式？
1. 關於這個思考的起源
從事產品經理這個職業已經有了相當一段時間，帶產品團隊也有一段時間了。從剛開始做產品經理，到現在帶團隊，“思維模式”這個詞一直被反覆提及。剛開始是自己經常被老闆說“你的思路不正”，現在也經常把類似問題扔給自己的團隊。
- 先想清楚你的目標是什麼？
- 你到底要解決什麼問題？
- 能不能關注問題的本質？
想必也有很多同行和我一樣經常遇到這個問題。
我曾經遇到的困擾是：講了一大堆，老闆說沒聽懂。或者是老闆扔給我這個問題，然後我去整理了一下回來老闆還是說聽不懂。
就在上個月，我和團隊一起做覆盤總結，我們試圖定義“思維模式”，希望能夠有清晰的路徑和方法論進行參考，以便快速的進步。但我們卻發現我們仍然無法準確的說出——什麼是思維模式？正確的思維模式到底是怎樣的？該怎麼做？
2. 我的理解
這的確是個艱難的問題。
我們也經常看到網絡上各種以“思維”為標題的文章，用戶思維、商業思維、競爭思維等等等等。總覺得還是沒有那個“味道”，都很有道理，但似乎還沒有解決我的問題。
我也跟我的老師做了交流，但我發現在他跟我的討論中，他並沒有反覆的跟我說用戶、商業、競對這些產品經理經常要面臨的具體問題，他表述的更多是關於如何發現、定義、驗證、解決一個問題的本質邏輯。他推薦我去看的書不是《結網》、《人人都是產品經理》，是《思考的技術》。
所以，目前得出一個讓我覺得有點不好意思寫出來但又認為正確的結論：產品大佬的思維模式，是“返璞歸真”的“解決問題的思維模式”，用研、競調、商業模式都只是手段。
這也讓我想起來近期比較火的“演員請就位”中的現象：
陳凱歌、李少紅、趙薇這些“大佬”級別的導演，在點評或討教的時候，不會大篇幅地去說表演的理論、模型，反而是“你不在這個情緒中”、“經歷了那些事情…你此刻應該是…你的肢體…”這些非常具象的事情。
而郭敬明更多的是引用一些理論，作為觀眾的我反而聽的雲裡霧裡，演員們似乎也無法準確的知道問題在哪裡。
那麼問題又來了，所謂的“返璞歸真”的“解決問題的思維模式”，又是什麼？
3. 這篇文章的內容結構
（1）大佬思維模式第一步——從問題出發的思維
這個道理似乎在很多文章中也提過，但我發現很多人（包括我自己）對這個道理的理解常常停留於表面。
我認為核心的原因是很多人把現象、原因、結果、解決方案這四個不同的事物搞混了，想要從問題出發，但往往無法描述清楚到底是什麼問題。
（2）大佬思維模式第二步——歸納思維，讓思維聚焦
當我們理解了項目的現象、原因、結果、解決方案的區別之後，如何真正的做到？
一方面，我們接觸的信息量太多了，從用戶調研、邏輯推演、競調我們會獲取很多的認知，如何對這些認知進行高效的梳理？
另一方面，我們常常會犯一個錯誤——過於發散。一次想解決的問題過多，不夠聚焦。
我將提供一些基本的方法論幫助你解決這兩個問題。
（3）一個項目FRD的參考框架
大佬思維最直接的體現是一份高質量的FRD（或MRD）。
最早我們的團隊是沒有寫FRD的習慣的，腦子裡蹦出一個需求或者從用戶那邊抓到，稍微一商量就去幹了。
現在開始搞FRD以後，感覺這個環節必不可少。
FRD是去敘述你的方案目標、價值、驗證過程、方案核心點的過程，可以讓你自己和相關團隊清晰的知道這個項目到底解決什麼問題？什麼價值？多大價值？方案的難點在哪裡？
強烈建議還沒有這個習慣的產品團隊，在客觀條件允許的情況下啟動FRD評審。
我們在啟動後也一度遇到不會寫、寫的質量差的問題，所以這裡結合本文的內容給到一個參考的框架。
到這裡也羅裡吧嗦一大堆了，也是我個人還沒有解決的壞習慣，希望上面的文字都不算廢話，接下來進入正文。
Part1：現象、原因、結果和解決方案
這個部分從產品經理最常遇到的靈魂拷問開始：
- 你到底想解決什麼問題？
- 老闆到底問的是什麼？
- 在產品大佬的耳中，他又是如何解讀這個問題的？
先提供一個模型：
然後我們來逐一解釋：
1. 你希望對現在的“結果”帶來什麼改變？
這個問題是最關鍵的問題，你必須知道你的項目最終能為用戶、公司帶來的“結果級”的改變是什麼。
請注意，這裡的關鍵詞是“結果”。
很多產品經理在回答這個問題的時候，會回答：
- “我想縮短一下這個操作的路徑，用戶對這個地方吐槽很大”
- “我想新增一個模塊解決用戶的這個場景”
這都不是結果，“縮短操作路徑”是解決方案（手段），“用戶吐槽很大”是“現象”，“解決這個場景”是過程。
- 縮短操作路徑之後的結果是什麼？是體驗提升？是轉化率提升？能提升多少？
- 用戶吐槽少了的結果是什麼？是客服諮詢量減少？是口碑上升？減少多少？上升多少？
- 這個場景對用戶意味著什麼？是提升成就感？是帶來收入？多大成就感？多少收入
一般來講，如果你認為你的項目價值很大，那麼這個結果一定是和用戶的“活躍”“付費意願”，公司的競爭、銷售亮點直接相關的，那麼你務必要拿出具有絕對說服力的邏輯和證據，來說明這一點。
如何說明呢？
基於你對現象的整理、對現象背後原因的剖析。
2. 拿出經過驗證的“現象”和導致這個現象的“原因”論證你的結果
“現象”和“原因”是對“結果”的解釋。
基於對已經客觀存在的“現象”的分析，我們認為導致這個“現象”的“原因”是XXX、XXX，針對“原因”我們給出“XXX”、”XXX”兩個解決方案，可以如何如何改善這個“現象”，從而得到“XXX”的“結果”。
我們常常說，“要看到問題的本質”。
什麼是本質？
- a. 你看到的“現象”意味著什麼“結果”，“結果”是好還是壞，有多好，有多壞。
- b. 這個“現象”背後的原因是什麼？
我是做B端產品的，這裡提供我近期遇到的一個案例，來深度說一下“現象”和“結果”的區別。
（1）“現象”
在我們的需求庫中，收集到大量的需求，希望我們在我們為用戶提供的宣傳頁製作工具中，能夠讓宣傳頁內嵌的表單填寫信息更加靈活，支持自定義。
看到這裡你會做什麼？提供字段自定義的功能？
那麼你並不知道做了這個功能可以帶來什麼好的結果，唯一的結果就是用戶不再大量反饋了，但你根本不知道為什麼。
我們是怎麼做的？
（2）“現象”背後的“結果”
我們很好奇，先去探究了“他們要自定義是要拿來幹嘛”。
於是我們發現在我們的用戶日常經營的過程中，他們有很高頻的活動用來拓客或者調查問卷來維護已有的客戶。
在拓客中，他們非常迫切的希望能夠收集到他們的客戶更為豐富的信息，因為在他們後續長期的客戶維護和客戶續約中，對客戶有充分的瞭解是至關重要的。
在日常維護中，他們會邀請用戶參加一些客情維護的活動，也會有滿意度的問卷調查，他們也希望對這些過程信息進行整理和歸檔，用於後期續費或其他客情維護場景時使用。
現在我們知道了，我們如果解決“客戶希望增加報名表單自定義”這個“現象”，我們可以帶來“為用戶的經營中續費、客情維護的關鍵事項提供有力的信息收集工具”這個“結果”。
（當然，這個結果僅僅是從用戶價值深度層面給出的，如果要完善還要考慮用戶範圍、對公司的競爭價值）。
分析這個有什麼用呢？這決定了在你向老闆介紹項目的時候，你是否能讓老闆“動心”，也決定了你自己的項目落地的時候，項目價值的天花板。
（3）“現象”背後的“原因”
如果從剛才說的案例出發，現象背後的原因似乎一目瞭然，因為他們要搞續費搞客情維護，所以要這個功能。
但實際上，我們還會想“用戶現在是怎麼解決這個問題的？”為什麼偏偏提了這個需求而不是其他需求，沒有采用其他解決方案？
我們發現用戶有的用紙質的表單或excel。但這種方式搞來信息難以統一管理，查詢調用不方便。用戶收集到信息後還要給銷售團隊、售後團隊做分配，用紙質和表單就很難清晰的進行處理了。
或在網絡上找其他的表單工具。但是這些工具自定義程度很高，由於我們的B端用戶處在一個較傳統的行業，我們的用戶反而不太會用。
這是原因。
（4）現在可以做最終總結了
- 結果：用戶有“對客戶建立完善的信息檔案以促進續費和客情維護”的目標。
- 原因：用戶當前的各種解決方式存在各種弊端。
- 現象：最終有了，用戶希望我們能夠對既有工具做優化提供“表單字段自定義”這個現象
我們最終的解決方案並不是在我們提供的宣傳工具上增加表單字段自定義的功能，而是單獨開發了表單插件，並做了諸多其他針對性的設計，這裡就不透露了。
（5）小建議
最初級的產品經理，常常把“解決方案”當成“你到底要解決什麼問題”的回答，我要做一個某某功能。
進階的產品經理，常常會因為思考邏輯不清晰，區分不清楚結果、原因、現象之間的差別。也會因為思考深度不夠、全面性不夠只看到了部分的現象、部分的原因。
要做好這一點，我採用的解決方案是“寫下來”+“討論”。
當寫下來以後，我可以更清晰的看到自己的邏輯，從而優化邏輯。
找同事、用戶、相關人員做討論以後，我會發散自己的思維，避免自己只是管中窺豹，或者只看到了表象。
這個還需要多多訓練，多多捱罵。“思路正”，是可以通過學習快速建立框架然後加以練習的，“思考深入、思考全面”，可能就需要不斷的磨礪摔打在實戰中成長了。
Part2：歸納——讓思維聚焦
我經歷過這樣的階段——思路感覺已經清晰了，但是自己說不清，經常被吐槽“廢話太多，沒有重點”。
最常見的現象是：
- 項目的目標有多個
- 列舉的現象、解決方案有一堆，且相互之間關聯性很差。經常會說“我們這樣做，既可以，同時也可以，還可以…”
我覆盤了出現這個情況的原因：
- 我們通過各種渠道獲取到的認知太多了，沒能對問題進行歸類、總結。
- 步子邁的太大，想要的太多，不夠聚焦。
關於前第一個問題，推薦《金字塔原理》和“麥肯錫的MECE和歸納演繹法”相關理論。
核心步驟是：
- 是對所有可能性進行窮盡，確保“沒有遺漏”
- 覆盤所有可能性，對相同的進行合併，確保“互不交叉”
- 對所有可能性進行歸類總結
- 對歸好的類別進行演繹，從原因、現象、結果的邏輯建立金字塔結構，確保邏輯融洽
相關的文章有很多，這裡就不深入講了。
關於第三個問題，也非常簡單，只要做到一個點。
一次解決一個問題，不同問題分不同項目解決。一個問題甚至也可以拆成不同項目解決。
（這一點“知易行難”，需要刻意練習）
Part3：一個項目FRD的參考框架
Step1：項目來源
儘管不少產品項目最初的起源可能都只是產品經理一時的靈感暴擊甚至只是意淫，但是當你要進行FRD的時候，請務必進行相關的驗證工作。
在一開始，說明項目需求是從哪來的，有哪些準備工作（數據分析、電話調研、訪談），不用詳細講過程，一句話帶過，至少讓參會的人知道你的結論都是有實際依據的，而不是自己意淫。
Step2：做什麼，能帶來什麼結果
一句話說清楚，可以和Step1一起說，例如：
- （開門見山）我們在需求庫中發現很多用戶希望我們做“信息收集的表單工具”。
- （你的依據）我們對此做了XX家用戶訪談，也對比了XX、XX等競對。
- （結果-用戶拿來解決他的什麼問題）發現用戶為了更好的續簽和客情維護，需要表單工具來對儘量全面的收集他們客戶的信息。
- （結果-這個問題有多重要，覆蓋到多少用戶）這在絕大部分用戶的經營中都是必不可少的一環，但現在市面上的工具都很難解決他們的訴求。
第一分鐘，就要讓老闆動心。（讓老闆動心是其次的，關鍵是這體現了你的思考夠深）
Step3：描述現狀和現狀存在的問題
用戶的實際場景是…..三大類場景
他們在這三類場景中目前是通過….等手段來解決的
這些手段存在的共性問題是…..等問題
未能滿足用戶的….等關鍵訴求
Step4：競對情況
在行業中XXX已有相關解決方案….我們可以效仿的部分是，可以進一步解決的問題是….
XXX、XXX還沒有相關方案
如果我們做了會為我們帶來XXX的競爭優勢
Step5：項目價值總結
用戶價值：
- 和用戶的續費、客情維護關鍵訴求直接相關（價值深度）
- 絕大部分用戶都有訴求（價值廣度）
對公司的價值：
- 滿足一個新的用戶高頻場景，增加用戶的使用粘性
- 建立競爭優勢
Step6：項目方案核心點
最後一步其實很難，關鍵點在於能夠結構清晰、重點清晰的說明方案的核心點。很多人常常做成粗淺的頁面表述或者功能結構表述，未能提煉出關鍵點。
好的項目方案核心點總結，首先一定是和用戶的核心訴求、競品未滿足的訴求能對應的，其次一定能給參會的技術同時一定的參考，讓他們提前預知到方案的核心開發難度在哪裡。（當然，部分方案的核心點可能在方案上線之後的運營策略、或是方案的視覺設計）。
Setp7：需求清單和優先級
結語
關鍵點總結
- 區分清楚現象、原因、結果、解決方案
- 確保目標明確、聚焦，一次解決一個問題
- 利用好歸納法，歸納之後理解才深刻
- 利用好演繹法，演繹之後邏輯才通暢，思維誤區更少
- 反覆練習，不管大小項目。可以充分利用日常的小事情。
比如，我今天寫這篇文章之前去看了電影，電影院的區域劃分是A01~A07，然後是B08~B13。為什麼不乾脆用1號-13號來命名，或A01~A07和B01~B06。
- 原因1：電影院13個廳分在兩個不同區域，區分A\\B看電影的人能夠清晰的知道自己的影廳在哪個區域。
- 原因2：電影院內部員工進行溝通或管理時，影廳數量不多，對A、B區域很熟悉，直接從1到13號的劃分更便於日常溝通。如果按A01~A07和B01~B06的方式來命名，如果A01著火了，就得大喊“A01著火啦”，不如按A01~A07，然後是B08~B1的方式命名，大喊“1號廳著火啦”更爽。
當然，這些小事情如果你不是非常有興趣，可能不需要真正花太多的時間和精力去弄清楚，自己邏輯自洽就可以了。
最後，寫完之後並不是非常滿意，感覺還沒有非常清晰直接地將一些關鍵點總結出來。也是我希望繼續去提升的點。
不管怎樣，希望對各位能有一定的參考價值。
感謝。
本文由 @LostInReal 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
