在這個話題上，很多團隊對於「Growth Hack」戰術以及 「Project Management」是否能同時並存且執行是存疑的。因為在傳統的分工架構與流程下，Project Management 強調的是職能分權以及排定優先順序。而 Growth Hack 「印象中」執行的場景是有不分組且跨領域的的 Growth Hacker 獨立的進行產品改造工程。
這兩件看似衝突的事如何一起執行？
產品是誰的？
在繼續講述這個公認為最難的主題之前，我想來先聊一個其他主題。我覺得很多 project management skill 與 framework 在很多團隊裡面沒有效果，其實是一個最重要的前提假設錯了。
這個最重要的前提假設是「產品是誰的？」通常，官方政治正確答案是「產品是大家的」。
但是在許多組織運作現有運作情況下，卻是「產品是 PM 的」。
以至於很多敏捷方法、架構、以及操作方法，在這樣的操作現況下，變得超級畸形以及沒有效率。
Scrum 中的角色 Stackholder 與 Product Owner 會是 User Story 的主導角色嗎？
Scrum 是市場上現存有「最多教科書」以及「看似最主流」的「敏捷」「框架」。但是不少公司在導入 Scrum 時卻常常遭受到重大挫折。最常見的原因是這些：
- Team 沒有那麼大，許多專案開發角色重疊，不知道如何調配角色。
- 誰是 User Story 的資料搜集者，主撰寫者，以及最終拍板者。
- User Story 的權重籌碼是由誰去調配比重？集體表決似乎又很蠢。因為團隊之內成員程度不一，投票出來的結果會亂七八糟。
- etc.etc...
有些主流 Scrum 擁護者會批評這些「質疑者」並沒有「受過好的 Scrum 訓練」或「團隊的 Scrum Master 功力不夠」以及「沒有完成執行 Scrum 內所有流程，跑半調子 Scrum」或者是「公司架構不適合引入 Scrum 須先改造」。總之，看起來這些質疑是因為「學習者並沒有學好 Scrum，所以執行到爛掉」，所以解決方法是「付費持續學習」。
答案真的是這樣嗎？我不置可否。
但仍不可否認的公認現實是：Scrum 這身大衣在許多團隊身上穿起來就是「不合身」。導致於有心要「正確」執行 Scrum 的團隊，必須要引入許多 Patch，或者是發明很多「說法」，讓「不合理的」作法有辦法「勉強被執行」。
（但這又會招致 Scrum 擁護者的批評：你們就是「執行」「錯的/變形」的 Scrum 才會變成這樣）
你不曾想過 Scrum 的前提角色設定，有可能才是根本上的錯誤嗎？
(這個標題我承認有點地圖炮）
在 Scrum 的既有設定中，案中的成員分成三個「主要」角色：
- Product Owner
- Scrum Master
- Team Member
『Product Owner 是所有利害關係人(Stakeholder)的代表。 他負責整合不同的利害關係人，並協助專案來定義Vision。 換言之，他決定專案到底最後要做成甚麼樣子，確保投資的回報能最符合組織(其他利害關係人)的需求。 最後尤其重要的，他得定義專案的完成日期。
也因為他肩負這樣的責任，他在專案開始前，必須要了解各利害關係人的考量，並根據這考量定義出這個專案的需求/功能清單(Scrum的術語稱之為Product Backlog)，以及各需求的優先順序。 甚至在專案的每個循環(Scrum術語稱為Sprint)，他得定義各循環的需求、調整需求的優先順序、甚至根據成果來刪減或增加Product Backlog的內容。』
Scrum 的標準作法：產品是 PM 的
Scrum 的標準作法是 PO ( 通常是 Product / Project Manager ) 去 interview stackholder，然後寫下 User Story 給 dev team 去挑選執行排成。
但「原始問題」的闡釋權與是誰的呢？
你有沒有曾經遇過 PM 寫過 User Story 的每一條都政治正確與格式正確，但是原始情境根本與需要解決的問題完全是 Out of Scene 呢？結果完全浪費大家的時間嗎？我有。
因為 PM 掩蓋了原始的細節，擅自自行以技術角度出發掩蓋了原始的 signal。要是這個 PM 技術功底與執行專案經驗不夠，感覺他好像幫技術團隊省了力，事實上卻害整個 team 造出廢物產品。要是這個 PM 溝通效率低，整個 team 更會被浪費了大量時間。
專案切分權責最後，結果大家就變成「為『位置』在做事，而不是為『事』在做事」，所有單一 Story 執行都正確，卻執行出「錯」的 Result。（ PM 與 RD 認為需要「做成這個樣子」，上線後卻發現「嚴重」偏離使用者需求）。
PM 應該要幫團隊做什麼事？
我認為 PM 需要做的是搜集需求，蒐集實作限制（資源以及時間），協助團隊在合理限制內「一起解決產品問題」。
而專案內不應該有 Product Owner 這個角色，因為產品的擁有者是「所有人」。
今年初，我們在公司內開始找到一種不錯的新的專案執行方式，PM 做的是讓產品需求能夠以這樣的格式被呈現：
- 我們遇到了什麼問題?
- 為什麼這件事會發生？
- 我們目前的限制是什麼
- PM 建議的解決方案
- 大家建議的解決方案是什麼
讓團隊相關成員 vote，以及協助安排後續 release 資源。
這樣的做法能讓大家有責任感，以及可以平行找到最有效的方式，實做出最貼近現實的方案。
PM 應該是致力於流程透明以及高效的協助者，而非「資訊黑洞」。
Growth Hack 與 Project Management 可以並行
所以回到 GrowthHack 與 Project Management 這個主題。你會發現原先假想衝突的癥結在於哪。在於「產品是誰的」？
Growth Hack 在你沒有兵權的情況又沒有把 Growth 知識充分傳授給團隊的情況下，會快速引發暴動。即便你跑 Scrum 或者是 Kaban 或者是任何一種 Agile 一樣。
所以整件事的中心點必須要回到「產品是誰的？」這個核心點進行討論。
「產品是大家的」。
以這樣的出發點出發，才有辦法做到「真正的產品增長」。