產品經(jīng)理心得總結

好久沒有認真總結最近的產品心得了。積累了很多主題，都在高強度的工作節(jié)奏中磨沒了。連書都不看的懶人，如果再不養(yǎng)成總結的習慣，就TMD的完蛋了，就變成垃圾產品的產品經(jīng)理了。

問題1：慎用設計手段解決需求問題。

發(fā)現(xiàn)產品中出現(xiàn)的問題之后，產品經(jīng)理的作用，最起碼應該是把這些問題背后的需求發(fā)掘清楚，翻譯給大家和自己。交互設計師的作用，則應該是根據(jù)需求層面對該問題的解釋和衡量，提出對應的解決方案。但真實情況是什么樣?有時候，項目緊張，沒有條件和時間做完整的用戶調研或測試，幾個人一起拍腦袋決定，幾個拍腦袋的人卻都不靠譜。有時候，需求模棱兩可，競品分析一下其他幾個產品的做法，然后東施效顰，幾個被拿來分析的產品卻都不靠譜。

這些都不可取?？扇〉氖?，要么，最終以百分之百的理由說服自己;要么以低成本、低耦合的方式進行快速試錯。要清楚的跟進，不能糊里糊涂的上線。

這里有一種誤區(qū)，千萬別被看上去還行的設計方案蒙蔽了自己。若需求都沒想清楚，再貼切的設計方案，也是一種陷阱，造成功能越做越做的陷阱之一。

　　問題2：別為少數(shù)用戶浪費太多精力。

聽到的用戶聲音，基本都是那部分很喜歡主動反饋問題的少數(shù)派。大致聽一聽就行了。讓不可替代的技術資源，去解決大部分用戶需要的功能。至于如何判斷某些反饋是否是大需求，產品經(jīng)理的能力問題。

　　問題3：別因為華而不實的功能而忘記核心體驗。

如果是一個郵箱，再NB的容量和網(wǎng)盤功能，也比不上郵箱收發(fā)速度。如果是一個相冊，再NB的相冊模板，也比不上圖片上傳速度。先把核心體驗做到極致再說，別被競品花里胡哨的輔助功能嚇到。

　　問題4：數(shù)據(jù)有時候不是那么重要。

如果不是電商或千萬級用戶量的產品，就不能拿數(shù)據(jù)來左右自己和團隊的產品動作。一個深諳需求的合格的產品經(jīng)理，對一個發(fā)展初期、相對簡單的產品，應該擁有基本的判斷力，來自產品經(jīng)驗和對該領域的直觀感覺。數(shù)據(jù)應該發(fā)揮應有的合適的作用。

　　問題5：別忽視技術骨干的產品建議。

雖然技術男看上去基本上都窩在自己的電腦前，渾渾噩噩的拍著代碼。但靠譜的技術，最解產品背后的數(shù)據(jù)結構和實現(xiàn)邏輯。產品經(jīng)理將需求翻譯成功能、提交給開發(fā)之后，最有可能節(jié)省時間成本、降低實現(xiàn)風險的環(huán)節(jié)，是跟技術之間的討論。討論新功能如何融入現(xiàn)有邏輯、以后是否拓展新需求進去。經(jīng)常有眼前一亮的技術建議，讓功能更加富有邏輯美感、更加節(jié)省實現(xiàn)成本。

換句話說，懂更多的技術、培養(yǎng)技術思維，產品經(jīng)理就更容易NB和靠譜。我特別享受這一過程，跟工程師討論技術實現(xiàn)方式的過程。

　　問題6：運營驅動產品的本質

真正靠譜的產品動作，來自于最前線的用戶需求。用戶需求不是靠用戶自己喊出來的，是要有人泡在用戶里面去發(fā)現(xiàn)才行。產品經(jīng)理就得干這活兒，去運營。一個脫離運營，只做功能的人，基本是還只是交互設計師。

恬不知恥的說，這活兒也只能由產品經(jīng)理來干，純粹的編輯、運營，也沒辦法從運營中抽取和翻譯出靠譜的需求，亂七八糟的1.0媒體、門戶類產品就是典型反例。