產品經理如何快速決策 , 拒絕選擇困難？

上一次分享了產品結構創建的流程以及結合思維導圖提高效率的思路，今天我們就要解釋另一個問題，就是產品功能創建以后，制定產品結構的決策是怎么定的。

一、產品的決策難點

上文提過產品要經過前期的調研、分析，才進入規劃的階段，即構建產品框架的階段。而構建產品框架從功能起步，再到定義產品的信息和具體結構。

它們三者都是結合前期調研、分析后做出的決策。比如電話亭產品功能中的課程模塊，包含了直播課、免費課、系統課、訓練營四個大類，都是根據業務上的需求得出，是比較直接的轉換，對我們決策的負擔并不重。

但只從業務角度出發制定功能，往往是不夠完整的。一方面常規產品都會包含一些基礎的通用功能，如賬戶系統、三方登錄、推送通知、應用設置等，產品經理需要考慮添加他們的必要性。

另一方面，產品經理自己或者團隊、用戶都會提出一系列對產品發展或用戶體驗有益的功能點，我們統一稱它們為主觀想法，產品經理就需要考慮是否采納他們。

并且，一個大的功能點，必然是由若干小功能點組成的，而這在前期調研分析中很難完整覆蓋。

比如一個直播功能，直播前有幾種預約形式，預約怎么通知，直播中要不要包含聊天、禮物、截圖、連麥等功能。這些功能點做不做，都要看產品經理如何決策。

再到信息地圖，一個對象可以添加的數據字段，那可就太多了。

比如產品用戶，從他們的基礎信息、生辰八字，到在應用內產生的各項數據，都是產品經理可以制定的字段，隨便想都可以想出百八十個出來。

想出來不難，但這些信息顯然不會全部用上（數據冗余和開發成本），那應該保留哪些，就是選擇困難癥的噩夢，也是產品經理必須要做的決策。

功能和信息內容的制定，都是在前期調研分析基礎上展開的獨立決策。而進入產品地圖階段，則要同時結合調研分析和功能、信息的要素做決策。

比如電話亭應用中，核心的功能模塊包含課程、社區、知識庫三個，直接把它們放在底部導航上加上用戶組成四個選項，這河貍嘛？

雖然能用，但明顯感覺不太對勁對吧？這和傳統應用的做法差異很大，而且每個頁面下級要放什么內容，其它基礎頁面（如首頁、探索等）、功能服務（如通知、日程等）要不要放，放哪里也成為問題。

作為產品經理，在這個階段就要組織頁面結構框架，將所有的功能合理分配到不同的頁面中去，并為它們填入前面制定好的有效信息。

一方面產品地圖的決策數量遠高于前兩者，另一方面每個決策都要有對應的理由，這就導致產品地圖創建過程的難度直線上升。

之所以困難，是因為產品決策解決的不是 1+1=2 這種有推導邏輯和標準答案的問題，而是充滿了不確定性和沒有標準答案的問題，產品得在一堆可選項中做出最終決策。

想想每天午飯/晚飯叫外賣的糾結，現在每規劃一個模塊，就要面對幾十上百個這樣的抉擇……

二、產品決策的依據

決策很困難，就是因為每個決策的結果都存在大量的不確定性，近的包括需求評審階段能不能通過，遠的包括上線后的實際效果，產品經理都需要對這些決策負責。

上線的結果怎么樣另說，產品首先要面對的是評審的壓力，也就是你要用拿沒有標準答案的決策成果，去說服其他人認同你的方案。

而想要別人認可你的方案，就需要對每個決策給出充分的理由，也就是建立因為…所以的邏輯推導過程。而這個過程并不只是用來應付其他人的，得是你自己也形成這種思考邏輯，用他們思考問題，最終結果才有說服力。

而接下來，我們就要針對每個決策形成的過程，做進一步的拆解。

還是以上面的案例為例，我定義的產品結構大致如下所示：

其中，登錄后底部導航的選項有四個，分別是首頁、課程、消息、我的。

首頁是個聚合頁，展示推薦內容，以及可以通過快速入口進入不同課程分類，以及社區、知識庫下級頁面中。下方則是課程推薦和聚合信息的瀑布流，用戶在進入主頁后可以直接向下劃查看感興趣的內容。

導航第二個選項是課程，有個獨立頻道頁面，而另外兩個主要功能社區和知識庫，卻只能從首頁進入。這種分配當然是不平衡的，而這種不平衡也是考慮后的結果。

雖然主要功能模塊有三個，但是我對課程權重的定義是更高的，是我認為用戶使用這個產品的核心價值點，而知識庫、社區只是輔助功能。且在前期階段，產品中不會有那么多知識庫內容以及社區內容，進去也沒多少東西能看，那它們就更沒有在 Tab 中露出的必要。

而第三個選項使用消息，是因為正在看的課程、直播課、知識庫如果更新，需要盡可能讓用戶能感知，以及用戶上的系列課/直播課時在臨近上課前也需要有通知和記錄。

在框架的定義中，決策的依據各不相同，且每個決策也有各自的優缺點。這就要進一步探討，決策的形成過程，用一個簡單的圖形做拆解如下所示：

關注重點，就是解決問題的依據。比如導航底部放不放功能模塊這個問題，我主要關注的重點是功能的權重，是由產品階段目標決定的。

而應對方案就是把第二個選項放課程，其它模塊入口從首頁進入。做這樣的方案必然會產生優點和缺點，優點就是課程模塊更顯眼更容易被發現，缺點是三個主要功能模塊有落差，社區、知識庫太深不好找，很難有人主動去點。

形成最終決策的考量，就是基于關注重點對優點和缺點做出比較，當優點大于缺點的時候，那么這個決策就有做的價值。當缺點遠遠大于優點時，那就應該考慮別的方案了。

關注重點是這個體系中最重要的因素，不同項目、場景、功能關注的重點可能截然不同。比如上方我關注的問題重點是產品發展目標（讓用戶多關注課程模塊），但也可以是別的因素，如：

1. 技術可行性：基于技術可以實現的角度來做產品決策
2. 用戶體驗：基于哪種做法更符合用戶習慣和體驗做產品決策
3. 實現成本：基于哪種做法做起來更簡單花費時間更少做產品決策
4. 增長目標：基于實現數據增長目標所制定的產品決策
5. 上級要求：基于客戶、領導、老板的偏好或直接要求做的產品決策
6. 市場競爭：基于面對競品獲得競爭優勢或不落下風所做的產品決策

每次決策的重點五花八門，找到正確的關注點，才能有效地解決問題，而錯誤的關注重點只會導出無效的結果。

比如做活動引導時，產品目標是短期內增加產品流水，那我們關注的重點應該是優先提高活動曝光和轉化，而不是關注用戶體驗做個能提升體驗的功能出來。以前者為重點就可能做出直接打擾用戶的彈窗、廣告，粗暴但是有效。而以后者為重點就可能要設計有趣的互動和隱蔽的提示，不會讓用戶太反感，但效果不好預測，大概率不好。

同理，還可以用這個思路去逆推產品的決策，比如拼多多底部導航第二個選項變成視頻，那我們不是站在用戶角度開始冷嘲熱諷，而是站在產品的角度理解他們這么制定決策的關注點是什么。

多分析真實產品，我們就能熟練的解構線上產品形成當前狀態的原因，以及背后的考慮，而這對我們自己做產品決策也有巨大的幫助。

決策是產品經理崗位最重要的工作之一，因為產品本來就是一個做決策的崗位，其他人負責執行。邏輯越清晰的決策越有說服力，也能形成越好的結果，而這也是產品思維的重要組成部分。

結尾

產品經理是要承擔足夠大責任的，所以大家越能正視這種責任，對決策的思考就會越重視、越清晰，而不是逃避糊弄，讓團隊其他成員或項目本身承擔惡果。

多把決策的關注要點、方案、優缺點記錄下來，是培養這種思考方式的最佳途徑。

歡迎關注作者的微信公眾號：「超人的電話亭」