• <fieldset id="82iqi"></fieldset>
    <tfoot id="82iqi"><input id="82iqi"></input></tfoot>
  • 
    <abbr id="82iqi"></abbr><strike id="82iqi"></strike>
  • 環球即時看!張小龍:人人都是產品經理是一句口號

    最近我寫了一篇話題:如何去選擇一個產品經理的好書。

    如何選擇一本產品經理的書?

    得到了不少朋友的共鳴。


    (資料圖片僅供參考)

    最近剛好我在看《微信背后的產品觀》,這本書是一本非常小而美的書籍 。

    閱讀后你發現他實際上是龍哥公開微信發布會的歷史演講合集,也包含了現場的觀點講解和提問互動。

    當我今天閱讀這本書的結尾,其中一個現場朋友向張小龍提問道:

    “人人都是產品經理這個詞特別火,怎么成為一個特別的產品經理,或者在騰訊如何成為一個特別的產品經理?”

    我感觸特別深的是,張小龍的回答:“我更認為人人都是產品經理是一句口號,而不是真的人人都是可以做產品經理,這是不可能的。”

    人人都來做產品經理有效嗎?

    其實我們在真正的研發流程里,是非常鼓勵這種方式的。比如產品團隊有多個產品經理負責同一款產品,我們一定會有產品組的周會,用來評審需求去攔截所謂的垃圾需求。

    我們在開發過程中,每個人都可以像用戶一樣對產品提出意見,這種口號方式是一件好事,可以避免閉門造車。

    團隊內部的成員至少相比用戶更加清楚我們的短板和劣勢,往往提的需求更容易被采納,而用戶提的就有可能是完全方便了個人,逃脫了群體來思考。

    什么是垃圾需求?

    恰好我在“Kevin和他的產品朋友社群”里看到一張趣圖,就貼切的形容了垃圾需求,是真的會存在。

    這張圖的設計方案,如果團隊有多個同學參與去思考產品設計方案,那就不會有這樣的地獄方案了。為了過濾這種垃圾設計方案,我們會有產品團隊內部的需求評審和上線前的交叉測試。

    交叉測試,什么意思呢

    字面意思就是把測試同學負責的測試模塊進行 相互交換測試。比如原來A同學負責a模塊,B同學負責b模塊;那么在一輪測試之后,A同學負責b模塊測試,B同學負責a模塊測試。

    我非常鼓勵團隊測試這樣去輪訓,畢竟現在的互聯網產品研發不可能是一個功能模塊就結束了項目,隨著用戶量新增和外部的環境變化,短期總是有新功能要增加,測試人員要不斷熟悉新的業務,才能從整體去評判功能的操作使用情況,做出測試建議。

    所以人人都做產品經理的口號,自然讓產品得到了更多的關注度,使用的人多了才可以發現一些深藏不漏的BUG,就像我們捉迷藏一樣,1個蒙著眼睛人去找大家和10個人蒙著眼睛去找,后面更容易找到。

    尤其是產品在沒有足夠用戶的時候,產品的設計人員、研發人員等內部員工就是早期用戶。

    產品經理的主人翁意識可以輸出給團隊

    我以前在大廠做產品工作的時候,發現很多產品經理都是需求來了就馬上開始埋頭做原型,周一剛給的需求任務,周三原型就出來了。

    開發都特別討厭這種產品經理,源源不斷的開發任務,都沒有考慮到底有沒有效果就馬上去做。沒有考慮到產品現在到底做的好不好,有沒有什么優化項,以及方向到底對不對。

    我一直告訴自己帶的產品經理會把產品的價值給團隊輸出,即使是負責開發的同學們,也能夠產生共情。而不是冷冰的下發一個又一個需求,這種產品研發的方式沒有人愿意去做產品的產品經理。

    這特別像流水線那些工人,他們在做任務的時候,是一臉無表情的去完成自己當下任務,至于這個產品到底合不合格,其他人做得好不好他不關心。

    每個人都是完成任務的做產品這樣是只能做出一款產品,但是做不出優秀的產品,因為沒有去產品的價值觀,做產品的意義是什么,以及個人成就會帶來什么,好的產品經理往往最直接的現象就是和團隊打成一片。

    人人都是產品經理的口號,讓產品經理壓力山大

    有不少朋友特別討厭“人人都是產品經理”這句話,他們會因為這句話讓很多門外漢來做產品經理,玷污了這個職業。

    實際上他們只是曲解了人人都做產品經理的本質意義并不是自己去做產品經理的工作,就像張小龍說的,這是一個團隊口號,大家要有產品主人翁意識,能夠勇于去對產品提出建議。

    可是人人都是產品經理的口號,如果一旦發起,會馬上給產品經理帶來工作的多余挑戰,比如這個需求為什么要做?為什么不用其他方案?就會陷入多次爭論中,而產品經理要做的是一定要PK到最后,因為只有這樣你的需求才是完整的,通過團隊檢驗的。

    我見過很多產品經理都和開發的關系處不好,甚至有的老板為了推動研發和團隊氛圍,會刻意找女性產品經理來做調節(女生好說話)。

    所以面對開發,需求文檔里的《需求背景》這一版塊就特別重要了,講清楚功能的目的和價值,那么相信任何產品的功能都是可以開發的,就是復雜度和實現成本的區別,和開發敵對的工作方式遲早最后要么就是研發離職要么就是產品換部門。

    我支持這句口號

    我的角度是支持的這句口號,因為人人都去做產品經理,至少你的產品關注度和使用人數提升了,你才知道是否有效。

    尤其是對于判斷自然增長曲線來說尤其重要。

    今天的分享都在這。

    本文來自微信公眾號 “Kevin改變世界的點滴”(ID:Kevingbsjddd),作者:Kevin改變世界的點滴,36氪經授權發布。

    標簽: 產品經理 設計方案 模塊測試