商業模式驗證完之後，我的挑戰換了一種

先前在產品開發的角色，其實更接近一般公司的產品經理，專注在商業模式的打造和用戶的意見。我們傾聽客戶、進行市場調查、分析商業邏輯、設計用戶體驗的流程，這些事情有明確的方法，也有明確的產出。

但商業模式只是企業規模化的第一步，它建構的是「這間企業或這個產品要成功的核心元素」，但真正讓其營利、持續、增加影響力的是規模化，隨之而來的議題則是：應對量變所產生的質變。

一間店和一百間店，不是同一件事做一百次

量變產生質變這句話很抽象，但放進現場就很具體：

• 一間店和一百間店的銷售系統有什麼不同？
• 一個人負責一間店的店長，和一百個店長的運作模式，需要經歷哪些轉變？
• 一百個會員和十萬個會員的經營方式，行銷方案該如何調整？

這幾個問題都不是「同樣的事情做更多次」可以回答的。

一間店的銷售系統可以有例外、可以人工補救，但一百間店的系統如果留了例外的空間，就會變成一百個例外。

一個店長可以靠帶人的直覺處理現場，一百個店長需要的是一套能被複製的SOP。

這是在商業模式框架下、產品本身發生的質變，但除此之外還有另一種質變，發生在團隊。

「少數人決定細節」方式失效了！

先前我們只需要依賴產品經理和專案經理，兩個人基本上就可以決定所有的細節。我們有能力、也有時間做出幾乎所有的決策指揮，來確保所有事情的同步性以及策略一致。

但當需要做的事情變多、變得複雜的時候，這個決策方式就不再適用了。在有限的時間內，我沒辦法針對每一個個案，都跟同事討論應該怎麼設計處理。

舉例來說，在前期的軟體開發中，我們完全有時間去討論某個按鈕的顏色、位置、大小、文案，不只是因為有時間，而是我們需要確保產品的基礎夠穩固扎實。但如果現在仍然要做這件事，會佔據掉太多時間。

與此同時，由於參與的人變多，需要考慮的事情也隨著規模成指數級攀升。

• 我們先前是用獨立的人力來討論選址、打造。但現在需要新的工程管理人員加入，加入之後才發現他同時還是另外一個案場的監工，我們在討論時程規劃的時候，就必須配合另一個案場來排。
• 又或者，先前工程團隊的人力沒這麼多，當我們想把人手擴大兩三倍的時候，還得考量新人的訓練速度跟不跟得上，會不會反而導致組織過度混亂。

這些都不是產品本質問題，而是團隊的議題，並且會決定產品做不做得出來。

總結來說，我的角色已經從產品經理漸漸往執行長、營運長的角度靠攏。由於規模化的緣故，多面向的複雜整合成為了下一階段的溝通與策略挑戰，包含：

• 因產品規模擴大，在產品與服務設計上，量變所產生的質變。
• 由於產品整合性的需求，從較為單純的專案模式產品溝通，變成多部門的職責與目標溝通。
• 從「點、線、面」思考商業模式較合理的組合、設定階段性目標，變成用網狀、系統性、時間演化性的多層次思考，來設定多元發展的平衡性擴張目標。

交接任務的時候，難的不是放不放權

協作模式的轉變，是這個階段最實際的挑戰之一。

過去幾個月，我們運用的企業資源其實很少。每個人參與一個案子大概一到三週，佔據這幾天不到一半的時間，對個人的時間運用和績效影響都還小，當時的企業模式也維持在一個相對彈性的狀態。

但隨著後面的階段需要產出的項目變多，產品和專案管理都需要更專注在跨單位的統合上，確保整體同步。這也意味著，我們必須把一些任務交接給各部門團隊。

而這個交接同時需要確認：哪些東西是可以放權的，以及我們期待這件事做到什麼程度。

以客服這個項目為例。

在前期，我們因為很關注產品的狀況，而且仍在探索用戶的想法，所以客戶來訊的時候，除了幫他們解決問題以外，有時也會追問這些問題是怎麼發生的、他們期待產品做到什麼，甚至從對話裡挖掘更多需求。

然而，這並不是一般客服團隊做的事，他們更關注的是營運效率、結單速度、服務滿意度這些面向，並不擅長需求探索，而且常常對於產品怎麼發展沒有太多決定權，以至於無法辨識哪些訊息對產品發展更有價值。

那麼這個項目應不應該交接出去？交接完畢之後，各單位所關注的議題、設定的個人與團隊績效目標，能不能反過來支持產品發展？這才是真正需要細緻討論的地方。

而且討論橫跨的範圍比我原本以為的更廣。

要說服其他主管承接目標、並定義好這些目標方向，並且在企業發展、部門發展、個人發展上都需要細緻的溝通，而目前我仍然沒有一個比較整體的方法。

但我認為，從達成目標的菁英團隊變成企業部門穩定團隊，總的來說對於目標達成並不是一個太好的方向，至少在團隊還小、每次迭代發展週期都相對短的狀況下，更不應該這麼做。

理由是，我們早期發展時，很多項目的定義和規劃都是以2~4周為單位在進行，而且經常性調整戰術方向。如果每一次的定義調整，都需要經過兩三層的目標溝通，還要設定個人的績效標準，顯然不符合比例原則。

專案團隊變成企業團隊

所以，專案團隊變成企業團隊，我想最大的挑戰是：管理的事項變多、管理的人也變多，在這樣的情況下要怎麼良好地溝通調度，部門主管的責任與控制界限應該到什麼程度。

我們要面臨的挑戰不只是市場與競爭對手的角力。在企業內部，即便沒有派系問題，也會有基於各自目標與立場的資源、權限爭奪。

此外，我們的專案管理模式，在不同單位之間其實有明顯差異，有些單位甚至不是以專案邏輯在管理事項，光是整合 Notion、google sheet、個人行事曆、Wrike(專案軟體)，就是一個複雜的問題。

目標的形狀變了

過去我們在衝刺時，基本上只會有一個核心目標（Sprint Goal，衝刺目標），幾乎所有任務都圍繞這個目標進行。

但在規模化階段，單一的大目標無法直接在多個單位發揮指引作用，因此目標必須被拆解，也就是：協作沒那麼細膩了，而是靠重要、被拆解的多個目標來結合。

舉例來說，擴展第一間店的時候的軟體開發，由於現場佈置需要和軟體系統比較緊密結合，包含設計風格、顯示資訊...等等的溝通，所以會跨單位的緊密溝通這些資訊。

但在第三間店開始，這些資訊早在先前就同步了，在討論的範圍開始是軟體擴充，就不需要空間設計師的資訊，只需要在時間上需要配合，剩下都是工程師的工作了。

對 PM 來說這仍然是同一個目標（讓第三間店擁有良好的租用體驗）。但顯然體驗已經被拆分成部門層級的工作（可多分店使用的租用流程），並不需要過度的溝通協作，開會的人反而變少、討論也變少，更像是由 PM 進行公告指揮，而不是跨單位的溝通討論。

協作變複雜的四個方向

總結來說，協作變得比以往複雜許多。

先前是由我獨自背負一個中期的大目標，剩下的任務定義、時程規劃，都是直接跟其他單位調度資源，擁有直接的指揮權來完成。

現在則同時面對四種轉變：

• 溝通對象：從直接與執行者核對，變成執行者、部門主管、執行長的多層次溝通，而且隨著任務事項的差異，溝通的層級也不一樣。
• 戰術目標：從原本的一個核心，變成多個衛星。甚至有些戰術的達成，並不是由 PM 控管、擬定執行計畫，而是單純地要求指定單位做到。
• 交付模式：從原本純粹的專案成果交付，變成多元的展開，需要根據不同單位而有不同的方式。
• 同步節奏：事項之間的緊密性，從原本以天為單位的時時溝通跟進，變成以週到月為單位的指揮公告。

結語

規模化最容易被低估的地方，是它看起來像「把同一件事做更多次」，實際上協作的底層邏輯都會被換掉。

系統要換、店長的運作模式要換、會員的經營方式要換，連我自己習慣的溝通對象、溝通內容也要換（從兩個人決定所有細節，變成必須把事情交出去，然後承擔交出去之後可能走偏的風險）。

如果你也正在從專案模式走向部門模式，我覺得值得先確認的不是這件事情要不要交出去、要交給誰，而是要確認在這件事情交接出去後，組織該怎麼合作來達成目標。

包含了

• 溝通的範圍、層級、細緻度重新定位
• 各單位的目標、責任、分工要拆解並能達成整體性
• 交付的定義要從細節說明轉變為方向指引
• 時間與資源的配合節奏要一致

同時也想提醒各位主管老闆，如果一間企業想要達成一個開創性的目標，最好確保組織在資源的調度上有足夠彈性，或至少是一個明確流暢的機制，不需要很多的權限申請、回報、考核，否則成長的最大挑戰絕對不是產品與市場的難題，而是內部複雜的流程與政治問題。