塗鴉筆記|空降的部門主管帶領產品團隊的經驗與反思

這是 2017.12.8 我參與悠識舉辦的主管講座:「空降的部門主管帶領團隊的經驗與反思」做的快速筆記,聽聽過去也是設計師背景、前獵豹移動產品專家的 Ivan,如何帶領產品團隊的經驗談。只要你是一個團隊的領導者,就算不是 PM 的角色,在這堂課也會有很多收穫。

講者 Ivan 的職涯從平面設計師、GUI、UIUX 設計師到轉變成產品經理,有非常多角色轉換,此堂以在獵豹科技/雪豹科技帶領過的 Photogrid、Security Master 兩個產品案例做分享。

先說明本文接下來的 PM 指的都是「product manager 產品經理」,並非「project manager 專案經理」,兩者定義與任務不同喔(想了解差異,可以看數位時代的這篇文章)。

我自己今年開始嘗試塗鴉筆記方法,練習當場邊聽邊用圖像轉譯的方式幫助自己紀錄,未來也更好喚醒自己對於這堂課的學習內容。塗鴉筆記的重點,並非記下「最完整」的聽講內容,而是我主觀聽見的,偶爾也會加入我自己的心得註記。因為整理成文章,圖片會重新編輯過,希望讓大家更好吸收。讓我們開始吧!

原始的塗鴉筆記

獵豹團隊的產品開發模式:五天到七天的敏捷循環

當 CEO (或其他人)提出一個風口,公司可以立即籌組一個 4–5 人小組(就像一個小創業團隊),PM 1 位、研發 1 位、設計 1 位、工程師1–2位,由這個小組自己提出目標、要如何達成,然後就開始進行為期 5–7 天的敏捷開發。

需求的開展方式:

  • 觀察用戶場景(透過使用者調查等)
  • 時事熱點
  • 產品數據洞悉等

循環模式為:

  • 週一需求評審會議:決定產品要做哪些需求
  • 週二修改需求
  • 週三需求凍結 Freeze (不可以再更改需求)
  • 週四-週一開發
  • 隔週二上線提測

關於時事熱點,Ivan 舉了一個例子,去年某款 App 遊戲爆紅,有許多輔助玩遊戲的工具一一上線。當時的一位高管請團隊因應此遊戲風潮,開發產品帶來流量與用戶,Ivan 協助產品經理用半天的時間,進行需求調研,直接透過內部訪談同事確認需求,第五天開發出一個外掛工具,本以為五天已經夠快,沒想到最後還是上不了 google play,原因是當時已經出現太多這個遊戲的外掛工具,google 的審核變得相當嚴謹。(所以如果需求觀察來自時事熱點,速度必須要更快啊!)

從設計師轉換成產品經理,是一種認知的升級(與衝擊!?)

過往身為設計師、設計團隊的主管,都算是接收需求方,拿到 PM 的需求後開始設計規劃,最在乎的便是設計是否符合使用者體驗、畫面是否美麗,然後如期交出設計稿即可。

加入 photogrid 擔任產品經理後,他拿到的目標是「日收入透過產品達到多少錢」,要看的便是 OKRs、KPI、功能開啟率、轉化等,過去身為設計師,最不喜歡 PM 給設計師「這個按鈕想要大一點!」「這個變成紅色!」這樣的指令,但作為一個 PM 就是要不斷的根據 AB Test 數據結果優化,為了要達標拼命測試修改,沒想到這些話變成是自己在跟設計師溝通(所以是一種衝擊)。當變成一個 PM,看的角度完全不同。

Ivan 提到自己過去身為 Design Team leader 時,偶爾會給設計師一些試錯空間,但是變成 PM 後,因為 PM 承擔整個產品的成敗,若他覺得設計不行,會直接告訴設計師「這個行不通」。在與設計師的溝通上,因為角色不同,在乎的也不一樣。

Ivan 開始帶領產品團隊、甚至帶領 PM 作為 PM Lead 後,還有哪些挑戰以及如何解決呢?

挑戰 1 : 若招募 PM 的標準沒有建立,則有些 PM 缺乏獨立思考與獨立運作能力

如果招募 PM 的標準是尋找「毫無疑問貫徹上頭指令的執行者」,則團隊中某些 PM 的需求決策容易只根據這兩種方式:「老闆的指令」與「直接複製競品作法」,其中複製競品的盲點,在於我們沒有競品的真實數據,並不知道競品的某些新穎功能成效是否好,若真的看到就直接複製,成效有可能不彰。

而缺乏經驗的 PM 若不熟悉交互原則的知識,會花很多時間在來回修改需求稿,無法加速團隊開發。

如何教練這些夥伴?Ivan 提供兩個方式:

  • 意願 (Will) -能力 (Skill)」教練矩陣
  • 樹立標準
透過「意願 (Will) -能力 (Skill)」矩陣去觀察夥伴是屬於哪種類型,給予不同的互動方式(這個方法,我認為只要你是領導者都適用)。
既然 PM 重點工作是出需求稿幫助團隊釐清目標,那麼自己就建立需求稿的標準範例。從格式、內容的清楚規劃、必須包含哪些東西項目,讓其他 PM 知道水準在哪裡。

回到源頭,你若是負責招募 PM 的領導者,要謹慎思考你想要與什麼樣的人工作,他需要具備哪些能力、標準應該在哪裡?

挑戰 2 :若沒有目標意識,則 PM 會提出不明確需求,執行成果缺乏亮點

Ivan 曾經觀察到敏捷開發因為是每週迭代的超快速度,也會有 PM 出現「為提需求而提需求」的狀況,背後並不理解真正目標為何,最後就算執行了這個需求,成果也缺乏亮點,可惜浪費了時間。

解決辦法便是一開始便讓 PM 知道遠大的目標是什麼,並且訓練 PM 的獨立思考能力。也透過「三隻猴子」的故事去提醒大家,有些人的決策理由是「他人過去是這樣決策」卻不清楚其脈絡,無法解決問題。

挑戰 3:若團隊協作者認為自己無法影響決策,則投入度不高

有些 PM 會害怕每次檯面的討論會拖慢決策速度,所以選擇檯面下、少數人決策,若造成資訊與認知不同步,這樣的資訊不一致容易讓團隊中的夥伴覺得自己只是「聽話的執行者」,那麼投入度會下降。

所以,產品領導者必須時刻同步所有資訊,減少資訊落差,並且打造共同參與空間,讓所有人都感受「我是重要的」一份子。

透過積極溝通、時刻同步資訊,讓大家感受「我是重要的」

我自己認為,偶爾偶爾還是會有少數人做決策的時機(畢竟真的無法每個決定都要所有相關人參一腳,討論會沒完沒了),重點在於決策後的傳達,不是上對下的布達指令,必須清楚說明決策原因,並鼓勵大家參與貢獻回饋其他解法,不能只單純的提出批評,如果今天大家能夠有自由發言空間但只會提批評沒有解法,無法幫助團隊真正前進。

One more thing:若領導者想建立團隊高標準,同時又能關注夥伴個人狀態,還可以怎麼做?

除了確保產品的推進、要讓產品達標,Ivan 在凝聚團隊上,還有三個作法,去踏實的了解、關心團隊夥伴,同時建立 PM 的高標準。

  • 建立 one on one 一對一聊天時間,去關注夥伴的狀態、遇到什麼困難及如何解決,接下來的目標
  • 刻意練習:強烈要求需求文件格式、週報格式(確保讓所有人同步所有資訊,並讓 PM 刻意練習思考每個需求背後的 OKRS、KPI 目標及其策略)
  • 嚴格制定流程與執行(敏捷開發的關鍵節點,需求會議、凍結時間、提側時間、Beta 上線時間)

做一個好的領導者,最重要的是什麼?

好的產品經理標準是什麼?如果你想朝向產品經理前進,以下是 Ivan 給的建議:

  • 能為團隊提出明確方向
  • 能針對目標提出相對應策略
  • 能協同運作組織
  • 能凝聚團隊共識

最難但也在持續練習的是什麼?是為團隊建立一致的價值觀。

我想,這就是看不見但深深影響團隊工作風格的「文化」。你希望你帶領的團隊是什麼樣的文化?這的確很不容易,因為每個人的價值觀不相同,領導者要如何將單一個人的價值觀與團隊的價值觀做連結,讓大家望向同一個方向,一直是最花時間,但最重要的。

謝謝悠識舉辦這樣的講座,也謝謝 Ivan 無私的分享(Ivan 的Medium 也有非常多經驗分享,點我去 Ivan 的 Medium)。關於產品的開發領導,從學習到實作總是會有一段距離,需要不斷調整,但能聽到實務的經驗借鏡非常寶貴,能夠幫助自己思考如何對應到自身的團隊,如何引導團隊開發產品,期許自己能夠朝卓越的產品領導者前進,帶來更巨大的影響力。

只有相信你做的是偉大的工作,你才能獲得真正的滿足。只有熱愛你的工作,你才能做出偉大的工作。- 史帝夫·賈伯斯
我是女人迷的服務設計師,如果你想知道女人迷的產品設計開發故事,歡迎 Follow 女人迷設計實驗室|womany PHD Lab 關注 PhD Lab 的各種學習筆記!
我喜歡學習、閱讀並將所學實踐在生活上,最近給自己的研究題目是 Growth Hack 與產品開發領導,這個題目上我是初始學習者,希望把自己的學習記錄成筆記,分享給更多對這個題目有興趣的人,如果你對這個題目內容有興趣,歡迎給予多點掌聲 XD!