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

文 / Peter Su, Product Manager at Facebook

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

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

• PM Zero — Product Founder/CEO：CEO 或創辦人就是產品經理。
• 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。一般來說，產品成長團隊也是按照目標區分的經典例子，例如把目標分為 Acquisition、Activation、Retention 與 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 曾經按照目標做區分，將團隊分成 Growth、Data Quality、Revnue 等不同團隊。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