產(chǎn)品經(jīng)理心得總結(jié)

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

問題1：慎用設(shè)計手段解決需求問題。

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

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

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

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

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

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

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

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

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

　　問題5：別忽視技術(shù)骨干的產(chǎn)品建議。

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

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

　　問題6：運營驅(qū)動產(chǎn)品的本質(zhì)

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

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