產品團隊組織劃分- Product Organization Structure


  • 文章發表於 2020-07-12

文/ Peter Su, Product Manager at Facebook

1. 何時該劃分產品團隊組織

Google Ventures 合夥人 Ken Norton 在他的文章 Product Manager Zero 提到產品團隊由小到大分成五個階段:

  • PM Zero — Product Founder/CEOCEO 或創辦人就是產品經理。
  • PM One — First non-founder product manager:招募第一位非創辦人出身的產品經理。
  • PM Two — Multiple product managers:少數幾位產品經理,直接回報給 CEO,尚未有產品主管的配置。
  • PM Few — Nascent product organization:產品組織已有規模,多位產品經理,回報給產品長(CPO)或產品副總(VP)。
  • PM Many — Mature product organization:大型產品組織,有多個不同產品線,有更多職級例如產品總監(Director)與產品部門主管(Group PM)等角色。

在第三階段,大多公司仍然沒有制定產品團隊的負責範圍,而是按照資源及時程來分配專案。絕大多數第四階段以後的公司,因為規模較大,原本分配專案的模式可能會出現愈來愈多的衝突,溝通難度也增加,一定會遇到如何劃分產品團隊負責範疇的問題。劃分產品團隊負責範圍的好處有三個,第一是讓產品團隊能更深入了解該領域的問題,累積該領域的專業,提供更好的解決方案。第二是如果劃分得宜,能減少掉球的可能性,比較不會有問題在那但不知道是誰負責。第三是讓團隊培養 Ownership,形成更自主(Autonomous)的團隊。

知名科技公司惡搞版組織示意圖

2. 常見的產品組織劃分方式

以下介紹幾種常見的產品團隊劃分方式:

  • 客戶族群區分:按照不同客戶族群來區分,例如以雙邊平台為例,可能是消費者端或商家端。如果是 2C 2B 單邊產品,可能是不同的用戶族群,例如中小企業(SMB)或大型企業(Enterprise)。按客戶區分的好處是不同客戶的需求不同,這樣區分可深入了解目標族群的問題,並為他們提供相對應的解決方案。而挑戰是不同的團隊的解決方案可能有重疊的狀況,因為即便需求不同,但解決方案可能類似。因此,這種區分方式比較適合目標客戶與解決方案有明顯差異的產品。
  • 使用者流程區分:按照使用者旅程區分,例如以電商前台為例,可能區分為搜尋、商品資訊、結帳流程、物流等。這個區分方式的好處是容易對應到產品的頁面與功能,挑戰是若有新的使用者流程,則需要變動團隊負責的範疇。這種區分方式比較適合使用者流程清楚且相對穩定的產品。
  • 目標區分:按照目標劃分不同團隊,以電商前台為例,可能有訂單量、轉換率、客訴率等不同目標,不同團會負責不同目標。而目標也可能是較為短期的、策略性的,例如要符合法規、在地化而成立的團隊。這個區分方式的好處為團隊目標明確,挑戰是因為沒有界定明確的目標客戶與使用者流程,不同團隊的解決方案也可能會重工或互相影響,例如不同團隊會想對相同的目標客戶或頁面做調整。這種區分方式比較適合彼此之間合作與溝通順暢的團隊。知名數據分析產品公司 Amplitude 就是按照目標來劃分產品團隊,可以參考他們的文章 How to Organize Your Product Team Around Your North Star。一般來說,產品成長團隊也是按照目標區分的經典例子,例如把目標分為 AcquisitionActivationRetention Revenue 等。也有一些公司會把 Growth 團隊獨立於產品團隊之外,可以參考 Andrew Chen 的文章 How to build a growth team
  • 問題區分:按照用戶問題來區分團隊,以叫車平台為例,人身安全與風控就是按用戶問題區分的。這個問題可能會跨多個目標客戶,例如平台的不同端,或是多個使用者流程。這個區分方式的好處是可以專注於問題本身,提供全面性的解決方案,給用戶較好的體驗。但挑戰是因為問題涉及面向廣,需要與專注不同目標客戶與產品流程的團隊緊密溝通合作。跟按照問題區分類似,有公司是按照 Jobs-to-be-done Job 來區分團隊,蠻有意思的,可以參考這篇文章 4 ways to organize your scaling product teams

也有一些團隊是按技術區分,例如 API 產品、開發者平台、Infra 等,不過這些團隊不見得會有產品經理的配置,因此在此就不多討論。

若公司規模尚小,例如產品團隊(產品經理、工程師、設計師等)在 50 人內,五個產品團隊左右,此時大多會有一個主要的產品團隊組織劃分區分方式。例如以筆者早期待過的新創團隊為例,Gogolook 曾經按照目標做區分,將團隊分成 GrowthData QualityRevnue 等不同團隊。iCHEF 在早期則是區分成新產品與既有產品維運,因為屬性是 B2B,透過既有產品維運來保持產品的穩定性與客戶滿意度。

若公司規模較大,則有多個劃分方式同時存在的可能。以筆者前公司 Booking.com 為例,筆者是位於 Apartment 事業群,這個事業群的產品團隊,首先按照「目標客戶」劃分,先區分為消費者端(旅客)與商家端(民宿主或民宿代管公司),接著再按「使用者流程」區分,例如消費者端有搜尋、比較、訂房體驗、訂房後流程等不同團隊,商家端則有上架流程、新手上路、商家成效等不同團隊。最後,還有按照「問題」區分的團隊,例如負責民宿主與旅客人身安全的團隊。

3. 劃分產品組織的原則

談完了常見的產品組織劃分方式後,最後談談產品組織劃分的原則

重新劃分產品組織時(例如 Re-Org 或成立新團隊),公司或產品主管都必須參考產品藍圖來了解短、中、長期產品團隊需要解決的問題。接著,盤點現有產品團隊劃分方式。許多較公司都會有產品的 One-Pager(不見得是整個產品,可能是部分的產品),內容包括該產品的目標用戶(例如商家端或消費者端、中小企業或大企業)、欲解決的問題、對問題的數據或假設、衡量成功的方式、負責範疇與團隊成員。劃分產品團隊是一件很慎重的事,許多公司設有評審委員會,在劃分產品組織時,按照 Product One-Pager 來評估合適的產品劃分方式及是否要成立新團隊。想要了解 Product One- Pager 範例的可以參考 Amplitude How to Write Good Product Docs

常見的產品組織評估原則如下:

  • 是否符合公司願景:產品組織按照公司規模與商業目標做調整是很正常的,而這個調整的結果就是俗稱的 Re-org。然而,不管公司再怎麼轉變,公司願景應該不容易有大的變動(有變就叫 Pivot)。在評估產品組織劃分時,應思考公司願景,確保有產品團隊可以顧到這塊長期不變的價值,例如臉書的願景是連結人與人的社群,那不管公司再怎麼改組,一定會有團隊專注在這個價值上。又例如 Booking.com 的願景是幫助旅人去探索世界,那麼專注在旅客訂房與旅遊體驗就是一直都會存在的產品團隊。
  • 是否為需要長期投入:如同前一點提到,組織變動是企業的正常新陳代謝,但變動過於頻繁則容易影響士氣。在劃分新團隊組織時,需思考該領域是否需要長期投入(例如未來 24 個月),如果是探索性、或是短期的項目,可以開宗明義的訂出此團隊的短期任務目標,讓團隊成員有一個預期的心理。例如在 3 個月內完成階段性任務,或是 6 個月內完成新方向的探索。
  • 減少相依性:一但公司有了兩個產品團隊,那麼在規劃產品組織劃分時,就要減少不同團隊之間的相依性。若公司是按照目標客戶或使用者流程區分,那麼相依性可能比較低。但若是按照目標或問題區分,不同團隊同時想要針對相同的使用者或相同的頁面做改動,那就需要事先的商議。完全沒有相依性是不太可能的,但原則是至少確保每個團隊對自己的領域有主導權、決策權,讓團隊在有主導權的狀況下進行協作。
  • 顧及團隊效率:公司持續成長,產品團隊也會擴張,例如雙邊平台的新創,一開始可能各一個團隊分別顧消費者端與商家端,每個產品團隊大概 8-10 人。但隨著人數持續擴增,為了讓溝通、協作保有效率,則需要開始思考分出新的產品團隊。至於何謂合宜的團隊人數,大家可參考亞馬遜的 2 Pizza Rule,關於產品經理與工程師的比例,Ken Norton 的文章 A Certain Ratio What’s the ideal number of engineers for every PM 也值得各位參考。

產品組織劃分的好,各團隊的權責清楚,彼此間不會有太多重疊與相依性,是讓團隊能深入了解問題、培養 Ownership 與自主性的重要基礎。組織設計是每個公司、產品團隊到一定規模後都會面臨到的問題,最後推薦矽谷知名創投 Ben Horowitz 的文章 Taking the Mystery out of Scaling a Company ,裡面關於組織設計的部分很值得一讀。

本文原始出處:https://medium.com/@petersuppi/產品團隊組織劃分- Product Organization Structure


看完文章之後還意猶未盡、想知道更多實務應用作法嗎?

2020 DesignOps 實務研討就邀請到 2 位在不同領域擔任團隊領導人的講者,要與各位關注團隊成長、跨部門協作議題的夥伴,分享自己的成敗經驗。
8/30(日)13:00~17:00 一起參與交流!>>> https://bit.ly/2DoAOR1

悠識 2020 DesignOps 實務研討

分類: 編輯精選