聊聊敏捷的產品經理

鼎叔發表於2024-03-22

這是鼎叔的第九十三篇原創文章。行業大牛和剛畢業的小白,都可以進來聊聊。

歡迎關注本專欄和微信公眾號《敏捷測試轉型》,星標收藏,大量原創思考文章陸續推出。

這篇聊聊我對產品經理這個崗位的看法,以及產品經理如何擁抱敏捷,產品和技術如何形成高效協作的團隊。

部分內容參考了《敏捷產品 - 不確定性的思維革命》一書。

產品經理的專業修煉

我一直認為,產品經理的崗位很特殊,好的產品經理是一個創業者,或者微型的 CEO。這個崗位在大學裡很難匹配到合適的專業,因為學校無法提供給產品經理刻意練習的環境,不像軟體工程師有很多刻意練習的專案 參考聊聊刻意練習 - 天才並不存在。更不用說,產品經理需要修煉的跨專業內容很多。

產品經理的專業培養也缺乏定論,博大但不規範,沒有大學的學科儲備。行業充斥著一戰成名的傳說,但是否戰戰必勝?

在網際網路業務過去突飛猛進的二十年,產品經理的校園招聘崗位,成為了一個大批次群面篩選的崗位。大公司招入的產品經理往往是帥哥美女,因為候選人的背景、邏輯和表達都很不錯,最後脫穎而出的往往是顏值高的…(開個玩笑哈)。

產品過程有很多具體的選擇取捨,由於蝴蝶效應,細微的選擇會導致最終上市的成果產生極大的差異。網際網路業務的風口導致了資本投入盲目的快,如果一定時間沒有成功就撤換團隊。

但這並不符合敏捷組織的觀念,快速失敗指的是 “專案” 而不是 “團隊”。

這種撤換還會導致團隊不能安心試錯和成長,造成公司培養資源的浪費,也導致盲目的年輕化(年齡歧視)。

在某個大型集團的年輕化變革中,我能感受到負面的變化是:隨著資深員工的流失,有深度的思考碰撞在減少。被快速提拔起來的年輕人,往往沒有經歷過足夠多的硬仗,且人品素質也沒有經過充分的檢驗。

產品的敏捷原則

和敏捷測試的原則一樣,敏捷原則同樣適用於產品設計,最重要的就是:動態規劃,小步快跑;擁有長期願景,但聚焦眼前交付。具體展開:

健康頻繁的個體互動,最重要的是尊重每個人的價值,資料和行為透明,誠實交流,彼此信任,投身於共同目標。

有建設性的衝突對團隊有益,鼓勵過程改進的吐槽和有益於思考碰撞的異議。

建設輕量級產品文件,儘可能和程式碼保持一致,包括:原型圖,使用者旅程,用例場景思維導圖等。

客戶協作勝於合同談判,客戶分為外部和內部,對內就是和研發經理的上下游矛盾,做多和做少的矛盾。

擁抱變化,因為客戶永遠要變化。尋求變化和計劃的動態平衡,平衡就是產品經理的藝術所在。所以,產品經理是一個藝術大於科學的崗位,需要掌握正反辯證態度。

敏捷產品設計和敏捷研發是一個融合閉環,最終目標是建立能自我管理的敏捷團隊。

敏捷不承諾找到產品的成功戰略方向,因為產品失敗是大機率事件,敏捷更強調團隊建立長期的執行紀律,從失敗中學習,把 “潛規則” 變成 “明規則”。

相反,偽敏捷的表現就是產品過早細化,過早具象。產品應該是需求的組織者,需求要簡約可協商,避免文件浪費,落實真人交流。

和技術側一樣,敏捷產品的視覺化有利於用研和高層更早介入,早提修改意見。

使用者思維

網際網路時代的使用者體驗評價更加重要,因為使用者遷移成本幾乎為零,產品的死亡率極高。

產品經理要有使用者思維,應該怎麼做?

大的方面,是有差異的產品定位(聊聊定位 - 如何佔領使用者心智)(戰略),小的方面,有制度來激勵和使用者互動的員工,建立容忍失敗和從產品失敗中學習的文化,有各種打動使用者的設計細節,再把好細節的方法論變成組織規範。

產品經理要有產品價值觀,價值觀是做什麼不做什麼的過濾器。產品經理還要有專業激情,儘量爭取到團隊共識,而不僅僅是上傳下達的角色。

所有需求的精益求精都在成本約束下才有意義,新需求務必要增加使用者的價值才應該做,這個價值也包括這個時代流行的情緒價值。‍‍‍‍‍

需求可以改變,但帶來的使用者價值要大於相關產研投入,大於做其他需求的機會成本。

窮盡路徑思考,是通往精益求精的唯一之路,從各種思考路徑中再聚焦成本可控的最佳路徑。

拿產品需求直接進行開發,沒有驗證容易產生浪費,和開發給測試驗證是一個道理。使用者研究和可用性測試就是給需求做驗證的方法,但它們首先是研究痛點,而不是給出需求。這個驗證效益更高,能夠減少浪費但不是創造價值。

敏捷產品的驗證鼓勵全員參與。定性比定量好 ,被訓練過的產品經理是最好的調研者,他更熟悉業務邏輯。最好的驗證是在使用者使用產品的現場。

我們之前介紹的使用者畫像,其目的是提醒產品經理不要把自己的需求當做真實使用者的需求。

我們可以從不同使用者群體調研中繪製關係圖,一張圖是看不同使用者群大小和潛在價值,另一張圖是看使用者問題發生的機率和痛點價值。痛點大小應該和解決方案匹配。

打造學習型的產品研發團隊

培養多樣化的學習型組織很重要,它對產品決策會帶來更全面的真知灼見。我比較喜歡產品工作坊形式,幾個月一次,這種深度研討匯談可以提高參與感和視覺化。

產品人員自己的思辨非常關鍵,思辨要慢,行動要快。對研發團隊能說清楚產品的功能目標和情感目標。要想說服工程師接受,需要提前準備量度和調研,以及解釋隱喻手法。

注意:使用者也在不斷升級,之前習以為常的情感對策可能效果很差了。這是更需要引入跨職能團隊來一起藝術創造。不過有時解決方案的難度超過團隊能力太多,必然失敗。

產品設計的方法論是對產品經理的高階要求,它重於個人的具體產品經驗。方法論能對抗世界的隨機性、機率性。產品結果雖然簡單,但過程複雜。

產品過程管理有一個著名的五層模型,從下到上分別為:策略層,解決方案層,資訊結構層,框架層和視覺層。不同崗位角色之所以發生協作問題,是因為在不同的層次上思考產品實現,缺失了重要的底層意圖視角。

敏捷產品的創新

敏捷產品同樣遵循三要素:優秀的交付品質,優秀的交付效率,優秀的人。優秀的人是對抗產品被友商抄襲的核創新武器。

產品的創新,顛覆性創新可遇不可求,更多我們見到的是微創新(除了功能複製外)。兩者並非涇渭分明,很多時候大家津津樂道的顛覆性創新是在多個已有創新的肩膀上往前走了一步的結果。

微創新讓產品不會大起大落,但是符合敏捷價值觀:不可能一次就做對,根據反饋來漸進式改進。

產品經常被外部詬病抄襲,那借鑑和抄襲的區別是什麼?

核心差別就是能否理解別人的解決手段是否適合自己團隊,如何解決了自己使用者的痛點,還有沒有融合改進的空間。

這背後需要刻意主動學習,尋找靈感,耗費大量體力和精力。創新靈感可以被激發,但需要先休息,加班無助於創新。

創新失敗的原因,往往是過於樂觀,或者不得不樂觀,團隊成員會高估自己的掌控能力,低估專案實現的難度,對判斷過於自信。另外一個原因是沒有準備驗證時間。只有儘早釋出才能緩解這些風險。

越是不確定的市場,越要擁抱敏捷的產品觀。

產品的資料運營

產品運營的資料驅動非常重要,但很多產品對指標值理解狹隘,比如留存使用者的指標意義不等價於流失使用者的指標。

很多情況下,低成本的統計抽樣就能知道結論,不一定要花費昂貴代價的全量資料。

驗證產品的指標如果沒有指名方向,是不會有效果的。敏捷並不鼓勵大量試錯,而是聚焦降低試錯成本。

MVP 就是這類實踐,其目標是低成本的快速驗證和學習,只看是否滿足基本功能,驗證基本盤使用者,不掛鉤 KPI。對於顯著創新的 MVP 產品,客戶能夠容忍一些缺陷,只要滿足了他一個關鍵需求。

做運營指標分析,可以深入參考系統思考理論聊聊學習型組織的五項修煉(上)。各種要素元件對結果產生了正向、逆向或延遲的效果,需要深入觀察,相關性不等於因果,利用小系統的資料降低系統複雜度。通常,定性的指標比定量指標更有益處,成本更低,我們可以利用金字塔原理讓拆解後的指標能窮盡和正交,邏輯有效。

資料工程師和產品通常不在一個部門,對彼目標互不理解,給出結果的時效也跟不上,這時需要一個獨立負責人明確交付紀律。未來對於產品經理的數學能力也會有更高預期。

優秀的產品團隊儘量多使用者手段,反對濫用運營手段,這樣會浪費可以糾錯的機會。

網際網路運營活動的本質和傳統行業一樣,不能依賴曇花一現的新奇玩法,這些所謂的小點子會帶來低效的工作模式,讓員工沒有足夠時間錘鍊團隊方法論。

補充一句,運營推廣的態度應該是左右腦平衡的,左腦理性驅動,右腦感性驅動,光靠創造噱頭不利於記住品牌本身。真正超出對手品質才能產生社會化營銷。

產品自組織團隊

敏捷組織希望在企業建立獨立的細胞組織。細胞組織中的專案經理有用人權,有利於多樣性培養,他需要被授權激勵,按團隊交付價值來區分績效,自己承諾交付目標。細胞外部的管理者可以設立規則,但不強制干預。

自組織團隊的人員相對成熟,而傳統職能部門有利於以老帶新的培養氛圍。

一個產品自組織團隊也同樣要有共同的願景認同,氛圍是包容開放的。團隊透過專案回顧會,聚焦要優先解決的問題(不超過三個)。

自組織團隊透過迭代建立情感信任非常關鍵。不信任他人,通常是因為過低估計他人和自己公司,過高估計自己和對手公司。鼓勵團隊成員提出建議,但尊重對方專業性。異議是多樣性團隊的動力,把 “多樣化思維” 和 “統一性決策” 融合在一起。

結語:

AI2.0 時代,產品經理更容易在小而美的公司取得勝利,但是自身素養要求也會大幅提升,普通的產品經理技能,技術工程師能借助大模型就搞定了。

暫無回覆。

相關文章