這篇文章，其實是寫給所有人看的，無論是工作人、學生黨，還是不需要工作的人，但凡需要解決問題，就需要這個技能。

但話說回本行，在2016年一整年的工作中，不斷感覺到一個至少到目前為止我認為是事實的觀點，那就是：產品經理的最重要或者說核心工作還是：協調資源，在合適的時候安排合適的資源在合適的地方。

這個說法在我兩年前沒畢業的時候，我就看到過，那時候僅僅覺得表面文字看起來好像很有道理的樣子，其實并不重視。直到兩年后，才從實踐中慢慢感受到其中的分量。有關于這個想法的感受，之后有機會也可以寫一篇文章來回顧一下吧。

那么，從這個角度來看，如何有效率的思考就成為了產品經理最重要的能力，沒有之一的那種，因為有效率的思考決定了后面是否有效率的做。

當然，什么叫有效率的思考，肯定是仁者見仁，智者見智了，我將結合編撰的例子梳理下自己的看法。

核心一：抓住本質去思考

這一點，是我認為在遇到問題后第一要蹦跳出腦中的思維。任何浮于問題表面的思考所帶來的解決方法，也許可以暫時解決問題，但終究不是長久之計。

舉個例子吧：

老板說：“我們做一個“猜你喜歡”的功能吧，我看別人app里有這個挺好的?！?/p>

 

（1）老板說要做？那就妥妥做唄！

產品經理吭哧吭哧找研發搗鼓出該功能……

 

（2）老板說要做？可以呀，先問問為啥，理由靠譜再做。

我：“老板，你為啥想做這個功能??？想先了解下您的目的?！?/p>

老板：“因為首頁推薦位置太少了啊，我希望能多發現一些東西，讓用戶多停留一下，多點選擇?！?/p>

我：“喔，原來是醬紫啊，感覺說的很有道理。那行，我們下個版本做這個吧?！?/p>

產品經理吭哧吭哧找研發搗鼓出該功能……

 

（3）老板說要做？沒問題，先找出核心需求來，看情況做。

我：“老板，你為啥想做這個功能??？想先了解下您的目的?！?/p>

老板：“因為首頁推薦主題的位置太少了啊，我希望能多發現一些東西，讓用戶多停留一下，多點選擇?！?/p>

我：“您是覺得現狀尋找更多的內容很不方便嗎？”

老板：“恩，是這樣的?！?/p>

我：“那您想找的內容是符合你個人興趣的，還是說平臺出的新內容呢？”

老板想了一下，然后說，“平臺出的新內容?！?/p>

我：“這樣啊，那您看把原本放在頁面最下方的最新主題部分提上來放在合適的位置上是不是就解決您的問題了呢？”

老板又想了一下，“好像是的?！?/p>

然后產品經理結合之前的用戶反饋，同時考慮頁面的內容框架主次，把最新主題的入口放在了首頁合適的位置。既滿足了用戶已有的抱怨以及老板的需求、還避免了后端開發，僅需要前端調整下頁面架構即可。

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

看起來好像做法c 優于 做法b 優于 做法a，而實際上做法a和b的差別是不大的，都沒有去進一步探尋問題的本質。

而這個會帶來的直接結果就是拉上了設計、開發、測試為你的思考方式買單；長期結果就是不斷被要求加入各種產品功能上的需求，最后自己變成寫邏輯、寫需求分析、畫原型圖的工具。最殘忍的是，不了解為什么做，如何能寫出簡約的邏輯、畫出簡約的交互呢？

上面的例子還僅是產品經理在處理產品功能上的需求時的不同的做法，還沒有涉及到技術本身、運營、內容、商務、第三方合作等上的需求呢。如果再加上這些，不挖掘本質思考問題的產品經理們，你覺得你能應付的了多少需求呢？

那么，如何抓到問題本質呢？

• 明確問題的描述，根據描述做問題的拆解；
• 根據問題拆解，對每個拆解點做求證和判定；
• 直到無法拆解，做最優的組合。

不斷拆解算是比較初級的做法，相當于慢慢打怪沖關直至終點；高級的做法是本身對問題的經驗，相當于直接一個通關卡。當然，人不可能對所有東西都很了解，因此，一般會結合問題拆解+經驗綜合使用。

核心二：圍繞如何解決問題去思考

這個是繼抓住了問題本質后，需要馬上重視的第二重要的。

舉個例子：

老板說：“我們目前的版本有個比較大的問題就是用戶主動尋找平臺內其他內容的路徑不理想，我們需要今天討論出更合理的推薦內容的方法?！?/p>

a說：“我覺得這個問題明顯就是用戶太蠢，找不到推薦的入口，沒啥好討論的?！?/p>

b說：“老板，我覺得這個跟產品沒關系啊，都是內容的鍋，應該讓內容更好的推薦內容才是?！?/p>

c說：“??？有這個情況嗎？老板你怎么感覺出來的？”

d說：“我覺得老板說的這個是客觀情況，雖然不排除運營有推薦內容的合理性問題，但是確實也是功能上有欠缺的地方，日常的用戶反饋以及客觀埋點數據都說明了這一點?！?/p>

e說：“我贊同b的說法，關于這個我已經有一些想法了，大家可以聽聽看這個幾個方案，然后balabalabala…”

然后d、e、老板三個人開始討論了起來，最后他們找到了一種改動小、可能見效快的方案來改進功能。

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

以上例子中：

• a、b為“推鍋型”：遇到問題第一反應是“都是別人的錯，撇干凈自己再說”；
• c為“懵逼型”：對問題沒有認知；
• d、e為“客觀實干型”：對問題有認知的同時還付出行動；

一般來說，提出問題或者出現問題的原因可能會有很多種類型：

• 有主題無范圍無需立刻有結果的頭腦風暴集思廣益；
• 有主題有范圍無需立刻有結果的解決方案征集；
• 有主題有范圍有特定對象需立刻有結果的解決方案征集；
• ……

無論表面看起來多不一樣，它的本質目的都是被解決。當然，解決方案、解決程度等等都可能非常不同，這個時候，就要根據問題本身去做不同判斷了。

那么，如何圍繞解決問題的角度去思考呢？

• 分析問題現狀，抓住問題核心；
• 找到問題目的；
• 撇除其他因素，只考慮問題本身，窮舉解決因子；
• 組合解決因子，找到合適的方案。

另外，值得補充的一點是，如何解決問題其實有兩個考慮緯度：問題本身、涉及考慮問題的參與者。參與者的態度以及想法，更多的是一種工作人的工作風格問題，這里就不多展開，但是不可避免的，參與者本身的風格會決定如何解決問題。

以上即是我認為思考問題的兩個核心步驟，下面我來列舉一下圍繞思考兩步驟的一些表象思維體現。

1、一個目的，多種解決方案

我覺得這個是屬于大家都知道，但是在解決問題的時候，會習慣性困在問題牢籠里的一點。

而究其為啥想不到的原因，我覺得還是上文說的第一大點，因為沒抓到問題的本質和核心，因為沒有抓到重點，所以思維會局限在特別區域內。

舉個例子：

問題：我們需要用更加簡短明確的路徑讓用戶發現更多好的內容，比如首頁推薦位更多一些。

 

那么，可以有的做法是：

 

1. 調整首頁的布局，把類似內容分類、內容排行榜放在明顯的位置；
2. 調整首頁的布局，再加入單獨推薦的模塊，例如；“猜你喜歡”、“今日最佳”等等；
3. 調整首頁原本推薦模塊的呈現形式，例如從一頁一頁輪換的輪播圖變成橫欄出現一個半推薦的形式；
4. 在用戶高頻使用的頁面以合適的方式在合適的位置加入關聯推薦；
5. 用運營活動的方式推薦著重的內容；
6. 記錄用戶行為，用短信、推送的方式推薦內容給用戶；
7. 在契合的產品中植入推薦；
8. ……

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

不要因為例子中的“比如首頁推薦位更多一些”的話，而把自己限制在產品的首頁、限制在產品功能本身。

達到同樣一個目的，方法千千萬，但是有些簡單有些復雜，有些代價小有些代價大，這就需要經驗以及拆解來細致分析啦。

2、拆解

不知道自己在這篇文章里出現過多少次這個詞了，它就是辣么重要。

為什么要拆解呢？舉個例子：

餓了么、美團、百度糯米大家熟悉吧？互聯網人必備點餐app，紅包也一定搶過吧？紅包的種類特別多吧：

1. 分享紅包：行為型紅包，成功購買后分享出去才能得到，有滿用金額限制、失效時間；
2. 天降紅包：活動型紅包，有滿用金額限制、失效時間、（品類限制、使用時間段限制）
3. 品類紅包：活動型紅包，有品類限制、滿用金額限制、時效時間；
4. 新人紅包：活動型紅包。

紅包類型比較多、可控制的字段也比較多，作用也比較不同。重點是，紅包可以直接抵扣訂單的金額，也就是跟錢有關系，不僅是平臺自己的錢，還有商戶的錢。

 

這個時候，你說你是根據當前需要先做一個類型的紅包呢還是一股腦兒的把整個系統給做了呢？

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

那么，拆解到底能拆什么？

• 把整體方案拆成一個個小方案，一階段只做一部分；
• 把最優方案拆成基礎方案＋各個優化，先能運行起來再優化；
• 把大問題拆成一個個小問題，各個擊破；
• 把大問題拆成主要問題＋其他小問題，先解決主要問題再說；
• 把復雜問題拆成簡單問題，優化解決方案；
• 把整體拆成局部；
• ……

至于怎么拆，由于影響拆解的因子太多鳥，還是要視情況而定才可以，就不詳細展開惹。（主要是特么篇幅已經太長鳥～）

3、靈活變通

靈活變通的本質還是跑不過思考的兩核心：抓住本質做分析，從解決問題的角度去多種情況考慮。

舉個例子：

這個版本移動端的需求已經很多了，時間很緊張，但是，客觀事實是，運營想做app內發放紅包的活動，需要技術力量配合。

這個時候該怎么辦呢？

時間不夠我也沒辦法，運營們自己想辦法吧；

app內紅包功能是肯定來不及的了，邏輯規劃、設計、開發、測試一連串的新增。
運營們最終目的是希望通過優惠券的方式來降低用戶購買的門檻，讓用戶先嘗下鮮。那是不是可以做成活動h5的形式，結合后端開發呢？

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

學會抓住目的去擴寬思路，不要被局限在小小界限內。這跟“一個目的，多種解決方法”講的其實是一件事。但可能，這里更加突出的是時間上的緊迫性。

產品經理在日常工作中，特別容易“被臨時”：發現了個bug需要解決方案、運營臨時提出個活動需求、商務臨時給你插了個合作方案等等，這個時候，最需要的是一顆理性分析＋靈活變通的頭腦。

說起來簡單，但其實還是蠻難的。這個，我覺得只有不斷的去實踐“被臨時”，處理多了臨時情況后，才能慢慢提高經驗值。

4、全局

這個不用多說惹，流經產品經理這里的信息其實最多，也最考驗全局的能力。

舉個小小小例子：

新版本上線幾天后，突然發現一個bug：自然升級的用戶無法獲取到新版本某個功能的某些數據，這些數據是由后端傳給移動端的，可是移動端在代碼處理上漏考慮自然升級的情況。

背景是，距現在15天后又有一個新版本要上線。

這個時候，解決方法可以有幾種：（排除在線修復的情況）

1. 移動端修改代碼，然后再上線一個新版本；
2. 后端簡單改下api的寫法，例如一秒刷一次，暫時先解決線上的bug，直到下個版本上線再改回去；

如果是你，會怎么選？

1. 選擇上線版本吧？測試／投放人力和時間成本、審核時間成本、線上bug無法馬上解決、新版本遷移過渡頻繁、版本埋點數據無效等等問題會出現；
2. 選擇改后端寫法吧？不是長久之計、萬一臨時出問題怎么辦；

（例子的編撰僅為了說明某個問題，也許從另一角度來說就不對了，請不要細糾例子。）

全局思考的考驗每天都會出現，產品經理們需要不斷從決策中積累經驗。

好像由思維核心延伸的表象思維也說完了，最后說一下常見的幾個思維誤區好了。

常見的幾個思維誤區

1、純因為自己擅長什么，就推崇什么

舉一些“一般來說”的例子吧（誤傷請不要認真）：

• 開發喜歡走開發主導的路線、產品喜歡走產品主導的路線、運營喜歡走運營主導的路線；
• 有些產品無視產品本身特點，喜歡把產品往社交、內容或者其他之前做過的、自己熟的方向上帶；
• 有些運營無視產品本身特點，喜歡按照自己之前用過的運營方法去推廣產品；
• 有些開發習慣了用自己的編程語言，一味抵制學習、接受新的語言，沒了解就覺得其他語言都是垃圾；
• ……

大到產品方向、開發語言、運營宗旨的選擇，小到小問題的不同處理方式，都容易出現這樣的問題。

不要覺得這個問題好像你沒遇到過，我不！相！信！

對于這種情況，我覺得其實沒啥特別好的處理方法，只能希望團隊中的人們都是理性、客觀的人兒惹吧。

還有一種絕對方面的情況，那就是：純因為自己不擅長什么，就反對什么。日常中這種例子也比較多，大家可以細心感受一下，我就不多說惹。

2、脫離目的的試圖證明自己更對

我覺得這個和性格有很大關系吧，最容易在考慮如何解決問題的時候發生。

舉個例子：

問題：用戶如何在淘寶上找到自己曾經買過的店鋪，重新進去買東西？

 

a說：“我看到靠譜的店鋪會收藏啊，直接從收藏的店鋪進去就好了?！?/p>

b說：“我一般都在購買過的訂單列表里找那家店，然后進去?！?/p>

c說：“我靠，乃們居然不是從首頁直接搜索店鋪進去的？！”

d說：“只有我特么是從購物車里進去的嗎？”

……

以上的問題大家發現沒有，其實本身就沒有標準答案，因為這和每個人的行為習慣有關系。沒有對錯，只有程度的差別。

另一個明顯的例子就是辯論。在辯論中，兩方都會對題目設定一些邊界、前置條件，從而來試圖表明自己的觀點更正確。

對于類似這種無對錯的討論，其實根本無法證明自己的思路更正確，即使通過一些數據去證明了，也在很大可能性上對解決問題沒有幫助。

意識到以上這點，在思維碰撞的時候，就容易減少和他人的無謂爭論。當然，這也是需要修煉的。

#專欄作家#

killifer，微信公眾號：killifer，金融資訊&工具類產品經理。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。

本文原創發布于人人都是產品經理，未經許可，不得轉載。