好久沒有認真總結最近的產品心得了。積累了很多主題，都在高強度的工作節奏中磨沒了。連書都不看的懶人，如果再不養成總結的習慣，就TMD的完蛋了，就變成垃圾產品的產品經理了。
完蛋問題1：慎用設計手段解決需求問題。
發現產品中出現的問題之後，產品經理的作用，最起碼應該是把這些問題背後的需求發掘清楚，翻譯給大家和自己。交互設計師的作用，則應該是根據需求層面對該問題的解釋和衡量，提出對應的解決方案。但真實情況是什麼樣？有時候，項目緊張，沒有條件和時間做完整的用戶調研或測試，幾個人一起拍腦袋決定，幾個拍腦袋的人卻都不靠譜。有時候，需求模稜兩可，競品分析一下其他幾個產品的做法，然後東施效颦，幾個被拿來分析的產品卻都不靠譜。
這些都不可取。可取的是，要麼，最終以百分之百的理由說服自己；要麼以低成本、低耦合的方式進行快速試錯。要清楚的跟進，不能糊裡糊塗的上線。
這裡有一種誤區，千萬別被看上去還行的設計方案蒙蔽了自己。若需求都沒想清楚，再貼切的設計方案，也是一種陷阱，造成功能越做越做的陷阱之一。
完蛋問題2：別為少數用戶浪費太多精力。
聽到的用戶聲音，基本都是那部分很喜歡主動反饋問題的少數派。大致聽一聽就行了。讓不可替代的技術資源，去解決大部分用戶需要的功能。至於如何判斷某些反饋是否是大需求，產品經理的能力問題。
完蛋問題3：別因為華而不實的功能而忘記核心體驗。
如果是一個郵箱，再NB的容量和網盤功能，也比不上郵箱收發速度。如果是一個相冊，再NB的相冊模板，也比不上圖片上傳速度。先把核心體驗做到極致再說，別被競品花裡胡哨的輔助功能嚇到。
完蛋問題4：數據有時候不是那麼重要。
如果不是電商或千萬級用戶量的產品，就不能拿數據來左右自己和團隊的產品動作。一個深谙需求的合格的產品經理，對一個發展初期、相對簡單的產品，應該擁有基本的判斷力，來自產品經驗和對該領域的直觀感覺。數據應該發揮應有的合適的作用。
完蛋問題5：別忽視技術骨干的產品建議。
雖然技術男看上去基本上都窩在自己的電腦前，渾渾噩噩的拍著代碼。但靠譜的技術，最解產品背後的數據結構和實現邏輯。產品經理將需求翻譯成功能、提交給開發之後，最有可能節省時間成本、降低實現風險的環節，是跟技術之間的討論。討論新功能如何融入現有邏輯、以後是否拓展新需求進去。經常有眼前一亮的技術建議，讓功能更加富有邏輯美感、更加節省實現成本。
換句話說，懂更多的技術、培養技術思維，產品經理就更容易NB和靠譜。我特別享受這一過程，跟工程師討論技術實現方式的過程。
完蛋問題6：運營驅動產品的本質
真正靠譜的產品動作，來自於最前線的用戶需求。用戶需求不是靠用戶自己喊出來的，是要有人泡在用戶裡面去發現才行。產品經理就得干這活兒，去運營。一個脫離運營，只做功能的人，基本是還只是交互設計師。
恬不知恥的說，這活兒也只能由產品經理來干，純粹的編輯、運營，也沒辦法從運營中抽取和翻譯出靠譜的需求，亂七八糟的1.0媒體、門戶類產品就是典型反例。
總的來說，產品經理又不是超人，不可能躲過這麼多陷阱、克服這麼多問題。所以一個產品組，幾個默契的產品人一起把關，比較穩妥。