PM 工作該縱切還是橫切？從實務角度談責任與效率設計 | Louis Yang

為什麼值得讀下去？
本文從實務出發，探討在 90% 以上的開發場景中，產品經理應該負責縱切（vertical cut）的完整功能責任，而非僅以橫切（horizontal cut）的職能分工為主。你將看到具體實務挑戰、組織結構的對照，以及實際可落地的策略與建議。

為什麼「縱切」是更務實的產品思維？

縱切的意思是：PM 對一個完整的 user story 或功能負責，涵蓋從使用者訪談、功能設計、技術選型、開發協調、go-to-market，到成本管理與價格設定。

不是「我只負責 UX」、「我不負責 release」，而是對成果負責。
不只是要產出，還要把東西賣出去。
只有從頭到尾都能掌握，才能真正知道產品是否能解決問題，並用對的語言推向市場。

舉例：曾有一個跨國 SaaS 專案，我負責的模組從 API 設計、前端操作邏輯、使用者教育素材，到定價策略都是我一手規劃，雖然壓力大，但每個決策都建立在一套邏輯體系裡，不會出現前後不一致或錯估風險的情況。

橫切 vs. 縱切：效率與責任的拉鋸

比項	縱切型 PM	橫切型 PM
對象	一個完整 user journey	一種職能（如 API）
責任感	高（擁有成果導向）	易碎片化、被動支援
溝通效率	高（跨平台邏輯統一）	易出現大量同步成本
組織適用情境	小團隊、創新產品、新市場	大公司、穩定開發、流程導向
缺點	技能需求高、需跨領域	缺乏 ownership 感

為何縱切效率更高？

橫切的 PM（例如只負責 backend 或只寫 spec）必須與各個其他負責人同步整體需求，每一次更動都要花額外時間開會、釐清、修改。當需求模糊或開發場景快速變化時，這樣的溝通量會呈倍數成長，也更容易「掉球」。

反之，縱切型 PM 能主導全流程，減少來回確認，也更容易整合經驗、快速學習並優化下一輪開發，iteration 週期也能更短、更緊湊，產品演進速度自然提升。

「PM 技能不夠廣」該怎麼辦？

這是反對縱切設計最常見的聲音：「一個人沒辦法掌握這麼多功能！」

我認為這是事實，但可以透過以下機制解決：

虛擬支援團隊（Virtual PM Team）

建立知識導向角色，負責撰寫 spec、行銷策略、定價架構等 best practice（例如：功能文件範本、不同商務語氣的回信句型、需求收斂與拆解流程等）
PM 間彼此分享模板、案例、指引，或由主管階層 coach 較 junior 的 PM
搭配 AI 工具（如 ChatGPT、ToneFlow）輔助產出初稿，降低技能門檻

AI 已降低進入門檻，現在的 PM 不必全會，但要知道「該問誰、怎麼查、要達成什麼」。

縱切 PM 的配套措施

為了讓縱切的工作模式真正落地，還需配套以下制度與流程設計：

建立明確的 PM 權責分工表：讓其他團隊清楚知道每個模組對應的 PM 是誰、該聯繫哪個角色確認什麼內容，避免資訊混亂或責任模糊。
定期 PM alignment meeting：週期性召開 PM 之間的對齊會議，對齊目前各模組進度、策略是否一致，並及早發現衝突點或風險。
整合與文件化 best practice：透過 Notion 或知識庫形式，彙整如撰寫規格、拆解需求、估時方式、技術合作流程等知識與經驗，讓 PM 團隊形成穩定輸出的共同標準。
建立交付流程透明的資料平台：讓其他團隊如開發、設計、行銷可以即時查閱每個功能的 Owner、時程與設計方向。

這些配套制度讓 PM 可以獨立作戰，又能在系統性框架下互相協作，有助於團隊規模擴張時的知識傳遞與責任清晰化。

模組劃分的實務建議

有些人質疑：「功能很難完整切分」，我認為這其實是 MECE 原則（Mutually Exclusive, Collectively Exhaustive） 的問題。這個管理概念來自 McKinsey 框架，意指拆分的項目之間應該「互斥但完整覆蓋」，每一個 PM 的負責範圍不應有重疊，但又能完整涵蓋所有產品需求。

好的縱切模組長這樣：

推薦系統：從資料蒐集 → 演算法 → 前端呈現，都交給同一位 PM
帳號模組：從登入邏輯、權限管理，到第三方整合，同一人統整管理

不適合獨立切割的模組：

如 iOS / Android / Web FE / BE：這些是職能導向，不宜切成單 PM 管理

因此，我建議縱切應該是以功能為主軸，而非以技術或平台為主。

誰對整體產品負責？

有人擔心：「如果每個人都只對自己的功能負責，那誰管整體產品策略？」

我認同要有一位產品總負責人（Lead PM 或 Head of Product）：

訂定產品方向與原則，負責整體組織運作
解決跨模組衝突
當模組 PM 經驗尚淺時，擔任 coach 與最後把關者

這樣的設計，既能讓每位 PM 獨當一面，也不會讓整體戰略碎片化。

小結：從分工邏輯回到產品本質

PM 的角色從來不只是橋接需求與開發，而是要對產品成敗有實質影響力。
當我們讓每個人都只專精一塊，就容易養出「這不是我負責」的文化。
但產品的成功，是一連串完整環節的結果。

縱切的思維不是為了讓 PM 做更多，而是讓 PM 思考得更完整。
讓每個功能、每段用戶體驗、每次商業決策，都有一個真正的 owner。
也只有在這樣的架構下，PM 才能真正從執行者，成為推動成果的人。

延伸思考：如果你想採用縱切架構，下一步可以怎麼做？

你的團隊適合什麼樣的 PM 分工模式？
評估目前 PM 人數、背景差異與合作模式，是否已具備縱切運作的基礎？哪些部位仍需調整或補位？
模組切分是否符合 MECE 原則？
回顧目前模組分工，是否具備互斥但完整覆蓋的邏輯？哪些功能模組其實應該由同一位 PM 統整負責？
如何幫助 PM 快速具備跨域能力？
是否已有虛擬支援機制，例如內部 best practice、AI 工具、內部顧問制度，幫助團隊降低跨功能負擔？

這些問題沒有唯一解，但正是導入縱切分工之前，值得與團隊一起深入對話與設計的起點。