企業人士總是喜歡成長 — 高速成長、魔術般的成長，為成長而成長。
雖然他們可能口口聲聲說：「我們要串連世界上所有與我們有共同熱情的用戶」，還把這當作是公司的宗旨；不過，在每次全員大會的時候，總是把成長放在第一位。提到的都不是我們怎麼串連用戶、我們將公司的宗旨落實了多少，而是拿出成長數據還有折線圖。
作為社畜，你在台下，看到這些數據，你還以為他們接下來要講大家可以分配多少股票、公司的股票又要漲多少之類的，不然關我什麼事呢？不過，好像每次都不會提到這些。很多時候，你覺得這大概是某種老闆的偷懶，老闆們似乎總以為做給股東的報告，就是員工想聽的東西，而且就是提供給用戶的價值。
—
講別的話題，都讓企業人士興趣缺缺，當你提到最新技術或是競爭對手產品，你就可以看到老闆們開始玩手機，也不知道在看些什麼，可能是兩個女人對著貓咪鬼哭神號的梗圖、還是新的限量款跑鞋之類的，但只要提到成長，就立刻讓會議室裡頭瀰漫起一股腎上腺素與睪丸酮的亢奮氣味。老闆們還會自以為謙遜地標榜「我們不自許成功，而是追求成長」 — 好像這個世上真的會有毫無限制、永不停歇的成長，而且相信這一套，就一點都不像神經病。
所以你就發現，這年頭我們沒有品質駭客、沒有價值駭客、沒有幸福或是企業良心的駭客，甚至沒有法遵駭客。我們有什麼？只有成長駭客。我們需要的 Mindset，就是 Growth Mindset。
想要討老闆的歡心，就要對準老闆的喜好，而不是拍錯馬屁 — 老闆喜歡成長，就讓老闆看到成長。可是，我們好像沒有分到股票，所以就算公司怎麼成長，就算會發獎金，還是比不上晉升帶來的實質好處；而且，我們討厭風險，所謂富貴險中求，你一沒搞好沒弄到富貴，就反而掉進了這個「險」裡頭，非社畜所為。
我們應該要有更輕鬆的選擇 — 沒錯，世上一向沒有正確或錯誤的選擇，只有輕鬆還是困難的選擇，沒有正路或是歪路，只有抄捷徑或是繞遠路 — 以我們的聰明智慧，就會知道，既然老闆想看到成長，我們就讓老闆「看到」成長。
老闆想要魔術、想要神話，我們就施展魔術。我們應該在老闆面前努力製造成長的幻象，並且在幻象被戳破之前就奪取老闆底下的最高權力，同時鏟除所有可能的異己與威脅。
別搞錯了，我們並沒有打算做什麼壞事，不過是老闆要什麼，我們就給老闆什麼。頂多只是些對我們有好處、不會受到處罰，而且在追求「成長」的過程中一定會發生的事。
—
反之，如果你想在職場上快速自殺，你可以試試看在全員大會時舉手，當著所有人的面前說：「我覺得，呃，盲目擴張是在自取滅亡。」
如果原本這場會議的背景音樂是行星組曲的木星樂章，你可以感受到，馬上變成火星樂章。這種觸霉頭的說法，下場大概就會跟 2019 年十二月的時候，就造謠說武漢在流行肺炎病毒一樣。
—
你應該要在一家公司剛拿到鉅額投資的時候，翩然登場。
你知道，這些企業人士也辛苦了好幾年，做了一個市場接受的產品，受到投資人的肯定，但他們也早已經身心俱疲，有的覺得一直沒辦法給孩子美好的童年而懊惱，有的則是三不五時就被痛風還是其他各種職業傷害所苦，一邊看著那些去矽谷發展的朋友同學好像過得更幸福更美好，突然拿到了一筆自己都不知道怎麼花的錢，要達到投資人所設定，但自己不知道怎麼達成的目標。
他表面上看起來志得意滿，但心裡始終住了一個飽受挫折、滿佈陰影、逼近絕望、隨時淚水都會潰堤的孩子，每天早上看到鏡子裡頭的自己，都忍著不要把鏡子砸個稀巴爛。他想哭喊著「創業的辛酸到底有誰懂」。 — 不過，反之，那些不創業的人有什麼辛酸，他也不是很想懂就是了。
你知道他們需要安慰 — 這時候其實你可以對他們販賣任何一種宗教商品，但他們現在最誠心信仰的宗教商品就是「成長」。你帶著漂亮的學經歷、新股東的推薦，以及與神祕的微笑出現。「放心，」你說：「把產品交給我。我知道該怎麼做，我們一起成長。」
你在從上而下的支持中，取得了產品主管的位置，負責管理公司內的產品 PM。你已經想好了接下來的手段：你不打算開拓新市場，也沒有新策略，這兩者都只會製造新的風險，所以，我們要開發讓人眼花撩亂的大量新功能，然後自己掌握這些新功能的成效數字，再用各式各樣的大量會議，把這些成長數字強迫灌食到老闆的肚子裡頭，把整家公司都拖入我們的成長大夢中。
另一方面，我們要想辦法阻止公司開發其他可能威脅我們地位的產品，如果有這樣的東西真的跑出來，就要想辦法再把手伸進去，把這個產品也納入旗下。最後，等到時機成熟，就發動組織調整。
—
要開發大量新功能，也不是一個人就能做到的，我們需要一批沒有思考沒有靈魂的奴工，幫我們製造出大量的企劃。
要達到這點，我們需要先擴充 PM 的人數，一口氣拉高人事成本 — 雖然這家公司只有一個產品，但我們還是要大概擴充到目前的三到五倍，辦公室的人數變多，把原本的空閒區域都用 OA 家用填滿，就頗有成長的感覺 — 哪有想做更多事、卻沒有更多人的道理？
然後，翦除部門內一個個可能反對我們的因素。
管理從來就不是怎樣跟員工講道理，也不是怎樣相互妥協，更不是什麼「帶兵要帶心」這種虛無飄渺的精神論，你需要的是一套具體、明確、入世而且絕不馬虎的統治技術，你需要的是帝王學。管理，就是要拔掉員工可以與管理階層對抗的羽翼。
部屬可以與主管、甚至更高管理階層對抗的資本，包括：
一，在公司內的經歷。因為待得久，所以他會有你所沒有的人脈、知道你所不知道的資源、還有那種英文叫做 credit 但中文怎麼翻譯都掌握不到味道的東西，像這樣的老鳥，我們可以利用考績排除掉，PM 這種工作最適合玩權力遊戲了 — 公司很多工作是在自己的職位上就可以創造資源，但 PM 卻是一種特別仰賴於可以取得多少公司資源，才有辦法做多少事情、有多少表現的工作，只要拿走資源，自然可以剝奪他的績效，剩下我們就可以交給 HR 代勞了。不過，有時候為了要讓自己看起來還是個溫和仁慈的主管，你可能得忍受這些人至少到過年。
二，專業社群甚至整個業界的認同，也就是公司外的名氣 — 有些員工在外面比老闆還有名。這種人很麻煩，你開除某個領域的明星，人家的閒言閒語不是這個人怎麼了，這是這家公司、或是這個主管怎麼了，很容易把火弄到自己身上，有這種人的話我們可以暫時先晾在一邊，只要三不五時給他們一些屈辱般的待遇，他們或許自己會走。重要的是，我們自己在找人的時候，就不可以找這種人，在有經驗、能力的人選，以及聽話的人選之間，我們要選擇後者。
沒有一個大專科系教你怎麼當 PM，在徵才時我們也往往搞不清楚擔任 PM 應該要有什麼資格。這可能暗示了一件事情：對照網路遊戲的規則，PM 根本就不該是一種新手職業、而是在二轉時才應該出現的職業，你可能在客服的位子上跟用戶打過交道。在 QA 的位置上熟稔所有的產品規則以及當中潛在的商業邏輯，可能在業務的位置上跟上下游都打過交道，不然你哪來的資格談產品規劃？但這種人，就是有可能反對我們的人，我們只該找一些剛畢業的乖巧年輕人來當 PM。
其三，就是我們最不想要看到的：部屬聯合起來反對我們。
所謂可以犯天威、不可犯眾怒。我們不怕頂撞老闆，再怎樣，老闆也只是一個人而已，我們也只需要攻克一個人。但是如果底下做事的人不聽話，那還真是什麼事都做不了，很不方便。
要阻止部屬聯合起來，就要切斷彼此之間的資訊交換 — 我們所需要的理想員工，是眼睛蒙上黑布、一往直前、奔馳到死的馬，不需要知道這個世界到底發生了什麼，只需要讓他耳朵聽到其他馬匹的蹄聲，擔心自己落後繼續跑得更快，即使前方就是懸崖，也讓他直接跳下去，更不會知道我們真正希望他做的事：原地繞圈圈。
在我們的世界中不需要懷疑論者，員工應該要盲目服從主管的指示，全心全意服從威權，並且猜忌同事。要一邊害怕自己無法完成主管交辦的工作，還要害怕身邊同事表現得更好。
如果你希望部屬之間都互不聯繫，你可能覺得應該讓每個人都在家上班，但這樣反而把事情弄得更糟，因為辦公室裡頭沒有人，外面也看不出來你們這個部門有沒有認真工作，辦公室裡頭沒有鬧哄哄的一片，也沒麼成長的感覺，你也無法約束部屬在你眼睛看不到的地方在幹些什麼。
在辦公室裡頭才能夠看得勞，而且以我們的手腕，在辦公室裡頭就可以操作絕招：資訊不對稱。
你應該先把每一份企劃工作都切到小到不能再小，讓每個 PM 都只做一小份在限制範圍內的工作，即使是再大型的企劃，也不能夠讓兩人以上一起進行，在職務分配上，就要讓員工看不清楚公司運作的全貌。你平常也要喜怒不露於色，不僅可以透露出一種神祕的威嚴，更讓人無法從表情當中，看出你講的工作中，到底哪件重要、哪件不重要。
我們也反對部屬去參加任何的業界社群，更不可以在各種場合就自己的工作經驗發言，所有的發言權與光環，都只該在我們身上。要做到這點，我們要讓工作佔滿部屬的全部時間，就算每個人只被分配到一小塊工作，但是在下班時間，心思也全都是工作的事，像是，我們可以在下班時間一樣敲 Slack，詢問工作進度，就是一種很好的作法。
最重要的是，我們要閹割他們對於世界以及公司的好奇，讓部屬心甘情願主動限縮、最終放棄視野。我們需要一套話術：一套透過連哄帶騙，加上斜坡謬誤的邏輯，佐以各種勵志心理名詞，最終達到情緒勒索的話術。只要有了這套話術，就可以讓一群涉世未深的年輕人，在職場上像 Ed Stafford 那樣單挑荒野，我們也就只需要躲在後面，遠端遙控。
—
你應該把部屬一個一個輪流找進小會議室，發動這套話術，而且講到自己都相信這一套。
「我知道，這家公司裡頭有很多資深員工，你每天要跟很多工程師、行銷、業務，要討論很多你不懂的事情。可是，你有沒有想過，你為什麼是這個時候進入公司？而我為什麼是這個時候，讓你通過面試、進入公司？
那當然是 — 此時此刻，公司需要的不是這些資深員工，而是我們。
這家公司需要我們的領導，只有我們才能夠透過產品，帶領公司進入持續的高速成長。我們在公司扮演的，就是這樣的角色，你也看到了老闆對我們部門的器重。所以，你要小心這些資深員工自稱以專業為出發的意見，社會與職場是個大染缸，我不希望你被污染；公司這時候找我們進來，需要的就是我們的能力，而不是那些過時、落伍的糟粕，他們甚至還覺得你不進入狀況 — 到底是誰不進入狀況呢！真是笑話。
產品是為了用戶服務的。用戶是誰？用戶就是一般人。你想想，有多少用戶是工程師？有多少用戶知道我們的上下游關係？用戶哪裡在乎你的技術限制？用戶哪裡在乎商業邏輯還有法規？我們最大的優勢，就是不受過去經驗的限制，不受過去包袱的束縛。
你有聽過『五隻猴子與香蕉』的故事嗎？有群科學家做了個實驗，把一群猴子被關在一個放了香蕉的籠子，只要有一隻猴子靠近香蕉，就會被水潑，結果有新猴子進了籠子，一靠近籠子，曾經被潑過水的猴子就來打這隻猴子。沒有什麼是不能做的！你看到的那些員工都只是一群不知道為什麼被潑水的猴子而已，但我們完全不同，我們的身上有勇氣，我們的胸口有初心！
事實上，誰愈是不了解技術、愈不了解商業，誰就越真正貼近用戶，我們代表的是冰冷科技產業當中的人文視野。有人說你沒能力，但這才是創造公司成長所需要的能力。跟我念一次，來 — 沒能力，就是你的超能力！
但，這些話，你不要在部門外面講，如果你隨隨便便、冒冒失失講出去，這種表現很自大，我反而會對你很失望。
有些工作你可能不知道怎麼做，但是我非常看好你，你一定不辱使命，不然我不會找你進來。但，我很看好你這件事，我也只跟你一個人說，你也只要記得就好，不要隨便講出去。接下來我會交代你很多重要的工作，都會對公司產生巨大的影響，但有時候不但外人不了解，就連部門裡頭有些同事也恐怕不了解，不說也罷。
所以，你懂吧？如果你把這些說出去了，恐怕我也就只會對你感到 —
很失望。」
—
生命總會尋找出路，你不用特別教，小 PM 也很快找到了生存之道。
即使根本沒有時間讓他們接觸用戶，去客服部獃個一兩天見識一下窮凶惡煞的客戶是什麼面貌，也搞不清楚工程部門擅長以及不擅長什麼什麼，因為我們是來帶領公司產品的，根本不需要知道工程師在幹嘛 — 更棒的是，也沒有時間去搞清楚自己做的這份企劃，是不是跟另外一份企劃衝突。但是在自我限縮視野的孤絕、昏天暗地的壓力下，有人設定了要在短時間產生大量產品功能企劃的目標，就會有人達成。
快速產生企劃的第一招，是先看看有沒有什麼天上掉下來的禮物。有些傻呼呼的工程師看到了什麼 MS Build、Google I/O 、WWDC 還是 F8 上頭有些什麼年度新技術，就急著想應用在產品上，而且可能已經做好了七八成拿出來。
這時候，我們要搶在工程師前面攔胡，叫工程師交代這個技術是做什麼用的，提供目前的進度文件，把上面的名字改成我們的，然後大筆一揮叫工程師這邊改一點、那邊改一點，好了，我們完成了一份企劃。
不過，畢竟不是天天都在過年。那，就要用到第二招：抄襲競爭對手。
— 喔，錯了，是對競爭對手產品的分析與研究。
我們的角色是帶領公司，而不是聆聽公司內部的意見，我們所放眼的就是整個市場上的所有產品；而我們的產品相較於競爭對手目前已經有什麼優勢，這一點都不重要，因為這些優勢都是前人建立的，前人的功業勢必不能讓我們在新時代創造成長，但是競爭對手做了什麼，都可能造成我們的威脅，所以競爭對手做了什麼功能，我們也統統都要做。
我們就算是市場第一名的產品，也該去抄襲第三名的產品。而競爭對手那麼多，每個對手也都做了不同的功能，我們應該要抄哪些呢？唉，小孩子才做選擇。
第三招是拼命改 UI。沒有什麼是比 UI 更能顯露出產品立即的改變了，UI 是最起眼的績效，愈經常改 UI，愈能夠讓大家知道產品部門有在做事，如果不知道要抄什麼，那就改 UI。
改 UI 的重點有兩個：1、把所有你可以想到的東西，統統放在版面上，2、老闆看不到的地方，就不要管，3、在所有你可以想到的時機改 UI。
以第一點來說，例如，我們現在有一個影片列表的畫面，裡頭有好幾列的影面封面圖片，有些人希望可以有大張、色彩豐富的圖片，吸引用戶目光，另一方面，有些人想要有一個又大又顯眼的播放按鈕，讓用戶知道這些圖片是可以點擊的。兩者應該要怎麼取捨呢？小孩子才做選擇，我們先準備好圖片，然後把方便的播放按鈕直接放在畫面的正中間，直接蓋在明星啊、網紅啊的鼻子上，這樣一來所有人都開心了，完美的設計。
再來，就算你也在台灣以外的地區提供服務，你的產品也支援多國語系，可是老闆只看中文，你就只需要針對中文做設計。
中文大概是全世界最簡短的語言，所以，如果你的版面只用中文做設計，套上其他各種語言的文案，大概都會跑版，但如果你以別的語言為基礎做設計，套上中文，又感覺似乎版面有點空曠。你就別管海外用戶看到的都是跑版的產品了，你把力氣放在這上面，老闆看不到。
再來談談如何抓緊時機改 UI。比方說，在某次會議中，需求部門希望接下來在登入畫面上，我們先拿掉一種沒什麼成效的登入方式，再增加一種第三方登入，既然登入的選項改變了，那就稍微調整一下登入畫面。到了我們手上，由於我們有三個負責登入畫面的 PM，我們要讓這三個人都有事情做 — 因為我們私底下都分別告訴他們，我們非常看好他們的表現 — 所以這看起來應該是一份企劃可以搞定的事情，就得分成交給三個人的三份工作。
每個 PM 也都各自找了一次設計師與工程師，花時間討論與實作：拿掉一種登入方式的時候，改一次 UI，再增加一種登入方式的時候，改一次 UI，最後，既然都說是 UI 調整了，那當然要改 UI。前一版的設計還在 QA 階段，後一版的設計就已經送進來，前兩版的 UI 在線上的產品生命週期都只有半個月。
如果哪個小 PM 在開始規劃 UI 改版之前，就知道自己花一個多月溝通出來的企劃，只存活半個月就會被改掉，應該會心灰意冷吧。所以，我們在這三個小 PM 上面，最好再設立一個小主管，嚴密監視，確保這三個 PM 之間不會交換資訊 — 即使他們的位置都坐在同一排。
這樣一直耗用資源改 UI，在會議上報告的時候，老闆難道不會注意到嗎？放心，不會的，一項功能到底花了多少成本，只是一場會議的前菜，還不到進入成長數字的高潮（那是我們後面要講的），根本就還沒辦法吸引老闆的注意。
他不會注意到的，他還在低頭玩手機。
—
公司很快就被會議佔據，好不熱鬧。
底下的小 PM 遞交了一份又一份的企劃，你根本就沒有時間細看，你也不應該細看，細看這些企劃只會佔據你去跟老闆開會，在老闆面前爭取存在感的時間，就叫他們各自去找相關部門主管 kick off 各個專案吧。
話說有了這麼多企劃，我們該不該為排個優先順序？當然不行啊！都已經跟每個小 PM 各自說過很看好他們了，主管怎麼可以偏心呢？
對了，開完會，別忘了帶個 deadline 回來。
所以一場會議可能像這樣：
「我們接下來會在產品當中進行一些 campaign，為了計算 campaign 的成效，我評估了一下，我們可以使用某家廠商的 SDK，我也獲得了主管的同意，評估我們在導入這套 SDK 時可能會遇到什麼困難，還有我們可以在什麼時候完成？」
「這套 SDK 不是上次 release 的時候，你旁邊那的 PM 就叫我們整合進去了？產品裡頭已經有這個 SDK 啦？」
「我不懂你的意思，我問的是你們可能會遇到什麼困難，所以希望你們提供一份評估報告以及時程，就是這麼簡單的東西。而且我們不同 PM 各自負責重要的計畫，我們部門如何運作，我們自己能夠安排，不需要外人的指教。」
「都已經做完的事情哪來的時程？還是你希望把已經做好的東西砍掉再做一次？我們可以散會了嗎？」
「所以你就是不願意提供時程囉？我們客客氣氣的，不過就是希望有一個技術評估還有時程規劃，這件事情對公司非常重要，你不尊重我沒關係，但我們愛這家公司，我也希望大家可以一起愛護這家公司！」
或是：
「我們今天要跟一個外部的廠商合作。我已經畫好了 Mindmap，確定了在我們的產品中需要跟對方系統銜接的部份，因為我已經跟大家開會了，所以我希望大家可以提供給我一個完成時間。」
「我們根本就沒看過對方的系統，連個 API 文件都沒有，誰知道對接需要多少時間？而且就算我們完成了，這個計畫一定是對方也要一起完成，而且還得是對方先完成我們才有辦法接上，我們連對方的完成度都不知道，怎麼可能評估出時間？」
「所以你就是不願意提供時程囉？我們客客氣氣的，不過就是希望有一個技術評估還有時程規劃，這件事情對公司非常重要，你不尊重我沒關係，但我們愛這家公司，我也希望大家可以一起愛護這家公司！」
—
— 孩子們啊！你們在工作上受到挫折了嗎？我們就來提點一下吧。
在 kick off 專案的時候，我們要注意到，很多工程師無法理解我們是來帶領公司成長的角色，往往出爾反爾，或是拿奇怪的理由刁難我們，打亂我們的管理。上面的狀況是一個例子，更常見的就是在時程安排上反反覆覆說話不算話。
我們派了十個 PM 分別問一個技術主管，完成一項該 PM 所負責的專案要多久，他都說只要一個星期，出於信任，我們就當然給了他一個星期充裕的時間，但是在我們好不辛苦做好了 roadmap 之後，居然還用極其頑劣的態度，跟我們喊著這樣的工作量需要十個星期才能完成，一口氣要了十倍的時間，而且完全打亂了我們已經排好的 roadmap。
還說什麼，他的時間都被拿來開會，都沒時間寫程式，公司應該是看重他的程式能力，怎麼進來都在開會…這種亂七八糟的藉口，拒絕和我們用會議溝通 — 工程師與 PM 本來就應該要經常溝通啊！居然還提出能不能將 kickoff 會議集中在同一天舉行這種無理的要求，我們那麼多的企劃，本來就不可能是同一個時間完成，本來就應該是哪份企劃寫完就什麼時候 kickoff 才對。
好吧，有幾個工程部門的主管不想跟我們開會，在工程部門找了所謂的 TPM 進來，T 也不知道是 Techinical 還是 Talk 裡頭的哪個字，總之工作就是負責跟我們開會。這樣也好，反正重點也不是一定要跟誰開會，而是要有人跟我們一直開會，而且人數也變多了，公司的規模更大了，更有成長的感覺。一個部門的 TPM 如果嫌不夠，就安排兩個。
更讓人噁心的是，工程師不時就賣弄技術名詞。我們要做個直播，體驗就是弄不好，工程師就跟我們說什麼只要是直播就會有延遲，先不說網路架構，物理上光速就是有極限，用光纖傳送資料再怎樣也不可能比光速快什麼鬼的，這誰說的？愛因斯坦說的？愛因斯坦就不能夠配合我們的產品需求嗎？愛因斯坦就這麼沒有 Growth Minset？我們就是要一個零延遲、違反因果律、因與果同時發生的直播產品，對這些工程師來說到底有什麼難的？為什麼連試都不試？
這些工程師全都不可信任，那我們也沒有什麼好客氣的。
我們找到讓企劃更快出爐，然後快速進入實作的流程。一開始我們以為，在初步企劃階段，應該找工程師評估可行性，確定可行才遞交企劃，但這樣的流程只會讓工程師一直打槍我們，所以我們應該把這個流程反過來：先做投影片，在老闆面前報告，告訴老闆工程師都看過，都沒有任何問題，然後把投影片丟給工程部門，把投影片當成規格書，跟他們說這就是老闆想要的功能，接下來你們自己想辦法。你先跟老闆報告一個完成時間，然後回來跟工程師說，這就是老闆要的 deadline。
其實我們自己也有需要加強的地方，有時候，我們自己的規劃也不夠完整，在規劃完目前想要做的功能之後，我們有時候會忘記預告 Phase 2 還想做什麼。至於這項計畫可能與什麼其他計畫衝突、需要多少成本、可能會造成哪些風險的評估、happy path 之外的錯誤處理、以及成效不如預期之後要有什麼退場機制…請不要把力氣放在這上面，老闆不會看。我們用的都是其他部門的成本，所以成本與我們無關，至於退場機制，那是計畫失敗才會用到的，但是我們的計畫一定不可能失敗 — 到了產品月會，你就會知道為什麼。
我們想要的最終成果，也絕對不能完全照著這份投影片的內容走，在開發以及驗受階段，甚至在出貨上線的前一刻，當然還要繼續追加新的規格。當然，你又會受到一輪工程師的砲轟，但是你想過嗎？你的投影片之前很多人都看過，老闆也看過，只照著死板板的規格把成品做出來，在結案的會議上，就只能把老闆已經知道的事情再重複一次，那還有什麼意思呢？
只有實作不按規格走，才能夠創造出─驚喜啊！
這樣的驚喜，就像是前菜之後的開胃酒，讓我們對接下來要端上的成長數字大餐，充滿期待。看啊！老闆把手機放下了。
— -
產品月會，是我們端上成長數字的場合。要有充足的數據，我們就要整合數據分析的 SDK，以及事件的埋點 — 至於，外界有那麼多的數據分析服務，哪些事件應該要記錄呢？小孩子才做選擇。
我們發出會議通知，邀請公司內所有的一二級主管參加，讓小 PM 們一個個輪流上台報告，讓公司全體為我們精美的投影片以及穩健的台風所折服，展現公司在這個月當中又締造了什麼驚人的成長。當然，產品月會這樣的會議，也是從你進入公司之後才開始的，數據，也完全是由我們自己解釋的。
你知道怎樣的數據才能夠讓人信服，基本上所有的數據還是要有所本，還是要來自我們實際上搜集到的記錄，畢竟工程師經手過、而且看過這些數據，所以重點是在呈現方式。首先這些成長數字要夠多，每個功能都有分別的成長數字，好讓忙碌的現代人沒力氣一一細看，這也就是需要這麼多小 PM 的最大意義。
此外，就是怎麼呈現片面事實的技巧：有時我們要掩蓋時間軸上縱向的前後趨勢，有時候則是橫向同一時間發生的其他事件。而其實，你不需要刻意想辦法製造片面事實，你底下的小 PM 為了不讓你失望，都會盯好對自己有利的數據。
比方說，我們對某個功能改了 UI，看了一下數據，這個月這個功能的用量成長了 5%，這種立即的成長當然要大書特書。至於這個功能前三個月與後三個月的發展的曲線，只要沒有人要求，我們就別拿出來了，如果把時間軸放大到半年，你發現這半年這個功能的用量本來就在一直成長，整個斜率都是一致的，從斜率上你根本感受不到中間這次 UI 改版造成了任何影響。 — 這不是我們要的，雖然用量提昇是好事，但這不是我們的績效。
然後，我們對官方網站做了 SEO，然後在完成 SEO 之後的三週，我們發現官網的流量突然也上升了 5%，太棒了！我們完美地優化了搜尋引擎的搜尋結果，SEO 做到了成功導流，官網流量大幅成長！是了，你只要告訴老闆這是 SEO 的成效就好，千萬別提醒老闆，在同一週，公司下了電視廣告。我們不需要刻意提點小 PM 去做這樣的數據解釋：一匹蒙上眼睛的馬，不知道公司做了電視廣告，也沒什麼好奇怪。
我們要把首頁設計得像是迷宮一樣，讓用戶迷路，一進入首頁像是墜入五里霧中找不到要找的東西，這樣就可以創造出用戶在首頁停留時間的數據，你看，用戶在首頁停留這麼久，可見用戶多喜愛我們的產品。
我們應該要把一次可以在網站上看完的文章分成五篇，這樣原本一篇文章只會創造一次點擊，現在變成可以創造五次點擊。
如果數量表現得不夠吸引人，我們就只呈現比例，一個幾百萬等級的服務裡頭，有個功能的用戶從五百人變成七百人，這種數字實在沒意思，但如果寫成「成長了 40%」，那就完全不一樣了！
公司的服務分成付費與免費兩種模式，年初的時候我們希望付費用戶多一點，我們就把免費模式的入口變小，改一次 UI，年底的時候又覺得整體用戶數字不好看，我們就把免費模式的入口放大，再改一次 UI。每當老闆覺得可以強化某個功能，我們這個月就把這項功能改一次 UI而且放在入口，於是每個月都可以看到不同功能的用量都在成長，然後沒有人會拿出前幾個月改版的功能的後續追蹤。
很久以後，老闆才注意到我們在做的事情：只是在產品內部的不同功能之間不斷導流。很久以後，有個小 PM 負責擴大免費模式的用戶，他想要花一筆行銷，預算推廣免費模式，最好我們還可以對目前的付費會員做點宣傳，讓他們也意識到其實我們有個免費模式，好增加免費用戶的人數…
但老闆怎麼打槍這份企劃，是很之後的事情，現在我們眼前就是密密麻麻的成長數據。老闆說，在成長的時候，還是要末忘初心。想來，初心就是我們年少時期的夢，我們從來沒忘記那個夢，所以，我們現在就在那場夢裡頭。
會議室裡頭人這麼多，難道沒有人發覺這些數字有問題嗎？
你環顧四周，沒有人說話。
好像有些人不以為然，私底下說這是什麼「每月例行媚上邀功大會」，還說什麼「這些東西上個月最後都是我做出來的，我幹嘛要來花一個上午時間來別人報告聽我做過的事情」之類的東西。不過，我們會讓他們閉嘴，總有辦法的。
—
我們想要別人閉嘴，可以先不用弄髒自己的手，我們真要出手就得毀天滅地，想到連自己都會害怕。話說，有個專司皇城內的和氣的衙門，叫做 HR。
所以公司又多了這種佔用大家時間的會議：
「我們知道，公司裡頭其實有很多很優秀的工程師，而工程師在討論事情的時候，往往都會用邏輯來思考事情，你有沒有想過，這樣公司裡頭有一些邏輯比較不好的同事，就覺得你們很可怕，都不敢跟你們討論事情了嗎？你覺得這樣對公司、對大家好嗎？你懂我的意思嗎？」
「所以，你的意思是，工程師應該不照邏輯來工作？還是公司做事還有討論沒有邏輯，這樣對公司以及大家比較好？」
「…我們最近收到很多的投訴，很多同事都說心理壓力很大，生活過得十分沮喪，有些下班還去看心理醫師，跟他們部門的主管反應，而我們 HR 也必須要出面處理，希望工程師能夠有所改變，跟著公司一起成長。」
「你希望有什麼改變呢？變得邏輯不好嗎？」
「你可能一時之間不知道該如何改變，或許你可以來看一下我們 HR 部門的運作，我們的部門氣氛就十分的融洽，沒有那種用邏輯讓人壓不過氣的氣氛，你知道最大的差別是什麼嗎？」
「因為 — 呃，HR 做事不用邏輯？」
—
工程部門的速度始終不夠快，講話還是這種氣燄，實在非常糟糕。
我們的競爭對手都已經做好了那麼多的功能，我們也以最快的速度，拿競爭對手產品的截圖放進投影片，列入我們的產品 roadmap，但是工程師不但不能夠立刻做出來，好讓我們拿出成長數據。我們沒有必要在乎競爭對手在產品上線之前花了多少時間開發，就像不會有人在乎一大篇幹話的背後到底是幾年的積怨。為了成長，這些功能，我們馬上都要。
但他們真的完全不懂什麼是 time to market，還一直嚷嚷跟我們要列表形式的需求與規格文件，說看不懂我們到底要做什麼。我們要做什麼？我們要的就是成長啊！有了投影片還要其他文件，才能夠實作上線，這樣我們時候才能產生成長數字？
我們需要一套不用寫出具體文件，也能夠實作上線的工作流程以及組織型態，而且在採用這種流程之後，要讓我們聽起來很厲害，充滿科技業的風采。我們準備好了，我們要聘請業界最貴的講師，要求所有的 PM 以及技術主管都去上課，
我們要導入 Scrum。
—
有些人，尤其是工程師，以為 Scrum 就是透過幾種保證生產力：因為團隊小，所以可以減少溝通成本，只需要少量而且簡短的 standup meeting。然後要有所謂的 Time Box — 在一兩週時間內，或是所謂的 Sprint — 決定好要完成哪些有價值的任務，決定之後中途就不再改變，好讓做事的人可以權力衝刺。要有 Scrum master 在旁觀察，確保沒有人偏離正軌，都有做好 Scrum 的相關實踐。然後在 Sprint 結束之後的 retrospective 會議中提出檢討，不斷讓團隊的合作默契更好。
台灣最接近 Scrum 的組織是國軍。一個 Scrum team 不應該太大，所以一個班只有九個人，然後有一個直接的 PO，叫做班長；每天工作之前都有的 standup meeting 呢，叫做早點名；至於固定時間都有的 retrospective 會議呢，叫做榮團會。所以，如果我們真心相信有個 Scrum 外型的組織就可以提昇效率的話，就等於，我們居然會願意相信：中華民國國軍是個高效率的組織。
所以，我們想要引入某種組織型態，看重的自然就不會是書本上所吹噓的那些效果，而是得看實質上可以解決哪些目前的問題，以及創造什麼好處。
我們發現，我們無法固定佔用工程部門一定比例的合理資源。我們做了大量的企劃，但是這些企劃在送進工程部門之後，到底會有多少人力投入在我們的事情上，居然不是我們能夠決定的：工程師還在處理其他部門，像是客服部的事。
產品上線之後會有像是服務不穩定、有 downtime 有 bug 之類的事情，於是就有客訴電話進來，有些牽涉到技術問題，光是客服部門不能解決，就把問題後拋到工程部門，要工程師想辦法重現問題、找出癥結、提出修正版本，這個叫做二線客服 — 客服部是第一線，客服部無法立刻處理的，就會交給第二線，丟給二線客服的案件往往來得又快又急，說什麼來電的客人非常急，希望能夠用最短的時間回覆客人，而處理二線客服又往往像是偵探小說情節，工程師得了解來電的客戶到底在講什麼，弄到用戶發生問題的設備重現問題，有些設備甚至已經停產了，然後在幾萬行程式碼當中找到出錯的那行。
二線客服的工作量每天不同，要看當天的客訴案件數量而定，而工程部門說，最近有愈來愈多新功能上線，就是必得要更多資源得放在二線客服上。咦？那能夠拿來開發新功能的資源，不就變少了？
我們贊成開發新功能與處理二線客服上的資源，應該要有一個平衡的比例 — 放在後者的資源應該要是零才對。的確，客服部門那邊也會產生一些數字，像是客訴案件的數量、Google Play 與 App Store 上面的星星數量，用戶的滿意程度指標之類的，但這種數字根本無法讓人興奮，因為這些數字不會勃起：你說 Store 上面的星星數量好了，我們只要去刷榜、弄些來自俄羅斯的殭屍帳號就可以衝起來了，而且衝到五顆星之後，就一直會是五顆星，這樣能看出什麼成長？一直討好目前的用戶，你要怎麼創造成長？客戶很急算什麼？我們難道不急嗎？
但我們當然不可以把這種事情說成我們不在乎既有用戶的留存，在職場打滾久了，你就要懂得話術 — 我們也很在乎客訴啊，所以我們也安排了一個最邊緣、最不起眼、最不討你歡心的小 PM 處理客訴，你可以說我們不在乎嗎？而我們開發那麼多新功能，當然也是為了我們既有的用戶，努力地增進 ARPU，所以我們就一定需要更多資源，投入到開發新功能上。
為了確保我們取得的人力不會被轉移到其他用途，我們可以把這些人編入一個新的、由我們主導的跨部門 task force，至於最後是什麼形式無所謂，鎖定人力資源的數量是第一要務，我們直接整理好名單：不管這些人現在在做什麼。我們就是要這些人。
再來，就是這家公司的人，為什麼就是不懂好好聽話呢？最後要逼你承受這麼大的部門內部壓力呢？我們都已經跟小 PM 說過，我們就是來帶領公司成長的領導者，產品部門就是這家公司裡頭的最高蘇維埃，但目前的組織卻還無法讓我們直接指揮工程師，底下的小 PM 都一個個有心理疾病在看醫生了，而且心理疾病最嚴重的，又都剛好是最有孝心最乖巧聽話的孩子。唉呀，Scrum 裡頭沒有 PM、只有 PO，這個不錯，這種位子完全就是為了我們打造的。
仔細一看，PO 不但可以主導整個團隊，還不用寫文件，這是我們要的。沒錯，你可以不用撰寫給工程師的文件，但如果你以為寫給我或是老闆的文件以及投影片也不用寫的話，那恐怕我就會對你，嗯，很失望。
Scrum 裡頭有一堆冠上專有名詞的會議，這也很棒，開會是我們的專長，不過原本的那些會議，什麼 kickoff 啦、產品月會啦，也是我們決定要開的，如果導入了一些新的流程，就廢除把原本的優良傳統，就會顯得我們對之前的作風自打嘴巴。所有的會議都要開，小孩子才做選擇。
理想狀況下，我們當然希望每個小 PM 都可以統管一個 Scrum team，不過我們怎麼算，公司裡頭的工程師就是沒有這麼多。所以在折衷之下，我們雖然只有一個產品，同一個 code base，但是我們弄出了兩個 Scrum team，剩下一些人處理客服以及其他隨時想到的開發；每個 Scrum team 有 QA、有工程師、有設計師、有三個 PO、但是沒有 Scrum master，而且以後也不會有 Scrum master。
Scrum master 的所作所為都是我們的阻礙。Scrum 說在 Sprint 當中就不可以修改要做的事，那要怎麼創造驚喜？每件事情沒有 priority 只有 order，但我們不可以對某個小 PM 偏心，所以這個 team 裡頭的三個，嗯，PO，想做的事情當然都得同時做。
沒有 Scrum master 的 scrum 還能順暢運作嗎？
當然能，我們說他順暢，他就是順暢。
—
據說，工程師是用一套叫做 git 的工具管理程式碼，git 可以產生多個開發分支。我們拆出的兩個 team 在開發階段，是在各自的分支當中開發，並且在功能還在開發分支中，我們就要求兩個 team 當中的 QA ，對各自分支當中的產品做完整測試。既然在分支當中都做好完整測試，我們只要再把這兩個分支合併起來，就趕快讓產品上線，接收成長數據了。
這麼流程這麼單純美好，居然也有工程部門的主管跑出來反對，這些人真的是為反而反。合併兩邊的功能不是一個按鈕就可以完成的事情嗎？Apple 還有 Pen 不是「嗯」一下就可以變成 Apple Pen 、還有 Pen Pineapple Apple Pen 嗎？卻有人跑出來說，組織被切成這樣兩邊根本無法互相 code review，主管能夠 code review 的時間又被排滿各種會議，而兩邊都有人不斷改到最底下的 codebase，然後每次兩邊的差異各自都長到兩三百個 commit 才合併，很多時候衝突多到根本無法合併。
有時候兩個分支裡頭，居然同時出現了完全同名的 class，兩個 class 居然行為都還不一樣，根本就不知道到底要保留哪一個，而如果刪掉了其中一個，也不知道會對另外一邊產生什麼影響，就算寫了單元測試還有自動化 UI 測試，兩邊的單元測試也在衝突，你根本搞不懂應該要保留哪邊的單元測試。還有些時候，這個 team 上次 release 寫的程式，在下個 release 反而被另外一個 team 刪掉了。
各種稀奇古怪的 bug 都是在合併之後造成的。既然最後上架的並不是在各自分支的那份程式，而是合併之後的版本，為什麼是在分支當中就做完整測試，而不是把力氣放在最後真正要上線版本上？最近每次上線的版本都屢屢出問題，二線客服一直進線，一直在推出 hotfix 版本，但能夠處理客服案件的人力卻愈來愈少，這樣下去產品的穩定度會很有問題…。
藉口、藉口、藉口。
一直講會產生 bug，工程師不過是想要把修 bug 變成 KPI 而已，這樣工程師接下來就會自己一直製造 bug 然後一直修，自私地增加自己的 KPI，結果讓新功能不能如期上線，我們能接受嗎？
而你們要 QA 不要測試還在分支當中的版本，那就是 QA 不要放在我們的，嗯，Scrum team 裡頭囉？你們打算讓 QA 做一些別的事情對不對？已經要到手的人力，要我們放手？那怎麼成？我們不會上當的。
—
產品。
每個產品都是從一個點子出發的，然後這個點子要先想辦法變得可行，再經過市場的篩選，最終才會變成產品。
產品繼續發展下去，就會有愈來愈多的人參與，愈來愈多的想法加入，四方的影響愈來愈濃厚，一開始的點子的面目就會愈來愈不清楚。慢慢，產品不是想要改變世界的熱情所驅動的，而按照部門的切分、工作的慣性、偷懶以及名利的慾望，把各種配方加進產品裡頭。最後，你在產品當中，看到的是組織的輪廓。
在我們的組織中，每個人都在規劃、開發大量的新功能，而且從不節制產品中的功能總數，所以打開產品，我們也要讓用戶看到各式各樣的新功能。我們在每個新上線的功能上都加上了提示的紅點，告訴這邊有東西是新的，而我們從來也不在乎這個紅點再過了多久之後應該拿掉 — 把這個納入規劃完全不會產生績效數字。
最終，來到產品首頁的時候，你會看到一大片密集恐懼症者喜聞樂見的美麗紅色，就像是你可以在稻田中看到的、一大片福壽螺的卵。而如果紅點還不能達到我們想要的效果，我們還可以選擇另外一項總是可以創造績效數字的武器：蓋版廣告。
兩個 Scrum team 擁有各自的設計師，也都慢慢走出了自己的風格，加上我們原本的部份，所以我們的一套產品，最後看起來就像是三套產品黏在一起，只要切換到另外一個分頁，就完全是另外一種視覺風格的東西，一套產品同時提供用戶三種不同的視覺享受。
追求產品的整體性是一件多餘而無益的工作，明明我們就有這麼多設計師，卻要求他們都做風格統一的設計，這怎麼看都是人力的浪費，而且再三強調，我們這麼看好底下的小 PM，怎麼可以拿整體性這種東西限制他們發揮產品規劃的空間？整體性只會妨礙我們，不要忘了我們到底在追求什麼，我們追求的是成長。
有些同事反應我們的產品愈改愈難用，甚至說外面的用戶都出現抱怨的聲音，說什麼 Scrum 應該是對產品做不斷的改善，但我們的 Scrum 卻是不斷把產品改爛。荒唐！在一家公司當中，每個人都有各自的角色，而 PM 所扮演的，就是代表用戶立場的角色，你不是 PM，你代表的就只是你自己的本位主義而已。
你們行銷業務只想要有個東西方便跟外面廠商談生意，你們工程師就只是想要擅自改動規格好讓程式好寫一點而已，你不代表用戶。你有什麼證據，可以證明你可以代表用戶？你說這是外面用戶的聲音，你有什麼證據可以說這真的是用戶說的，還是你自己在外面假冒用戶的發言？我們規劃這麼多新功能，有哪一點不是為了用戶？如果不是為了用戶，我們為什麼會這麼辛苦？
就算反應來自真實的用戶，也不過只是局部，這些少數人就可以代表全部的用戶嗎？我們規劃產品，要看的當然是市場的全貌，要看千千萬萬沈默的用戶到底平常怎麼使用我們的產品。用戶說我們的產品難用 — 你的說法，背後有數據可以支撐嗎？
我們的產品難用？
我們手上的數字，可不是這麼說。
—
沒有人可以阻止你的權力了。
從這個公司創立開始，從來沒有一段時間，擁有這麼大的產品團隊，開發了這麼多的產品功能，也從來沒有過這麼多的產品文件與投影片，沒有過這麼多的產品成長數據，從來沒有過這麼多的績效。
你可以肆意調動其他主管的資源，但你可以看到絕大多數的主管都只想歲月靜好，領著主管薪水付完房貸，每天準時上下班，可以在回家之後好好地每天換貓砂。更有許多聰明人知道應該要加入你的陣營，明明掛著一個技術主管的頭銜，卻把技術主管的工作都丟給底下的工程師做，自己跑來做 PM 的事情 — 遇到這種聰明的孩子，你除了誇獎他之外，也可以提點提點他：工程師背景來做 PM 工作，最好是先抓好產品數據埋點這項重點工作，因為大概每個產品都需要埋點，所以就有機會指揮很多人，這樣會很有成就感，而且，數據，就是我們的成長神話的核心中的核心。
時候到了，我們這時候可以發動組織調整了。既然我們的 Scrum 運作得這麼好，我們當然該把公司裡頭所有的組織，統統改組成 Scrim Team，在新的組織架構中，當然，由我們來擔任所有 Scrum Team 的頭。
發動組織調整的時候，切記，兵貴神速。
在組織調整之後，每個原本的主管全都被調整到新的位子上，而且，嗯，有些人，我們並沒有預留位子，所以這樣的調整與調動呢，如果還要逐一溝通，一定會有反彈，不但可能會讓組織最後不是我們想要的樣子，更可能會打消這次的組織調整。
所有關於新組織的方向都只該在秘密會議中討論，大家只需要知道最後的職務就可以了。我們不用知道每個人現在手上的職務是什麼，在新組織當中每個人接下來要做什麼事，我們不用知道新組織到底有沒有辦法運作，我們只要知道我們的終極目的：數據、成長什麼的，都只是過程與手段，我們的終極目的是獨裁 — 只要權力在手，我們總有辦法，逼迫下面把事情做出來。
這時候，你可以來料理那些長久以來看你不順眼，你也看不順眼的那些人。比方說，你可以把開發與修 bug （美其名叫做維持產品品質）分成兩個 Scrum Team，開發的功能都屬於前一個 Team，至於開發出來的產品有什麼 bug 全都算到第二個 Team 的頭上，乖巧的工程師就放在前一個 Team，至於你看不順眼的傢伙呢，就算他離開現在的工作，到了其他公司也可以直接擔任 CTO 職位，我們也給他擺到只會有過不會有功的位置上。你不用逼他離開，你只要這樣羞辱他，人家隔天就會遞出辭呈。
沒有人可以阻止你的權力了。但，就算我們搞定了公司內部的所有勢力，還得要繼續提防公司外的勢力，一些與公司合作的廠商、還有一些黑客松活動中開發的應用，並不在我們的控制範圍，如果他們真的做出了些什麼東西，還是會搶走我們的績效。不過，不用著急，好的獵人懂得等待，一開始他們也做不出什麼，但只要我們感受到威脅，我們就再發動一次組織調整，把這些合作產品統統納入麾下。
沒有人可以阻止你的權力了
—
沒有人可以阻止你的權力了。除非…
除非煙火總有放完的一天，除非派對的時間已經不多。
除非，你的成長數據跟來自財務的數字始終對不起來。
而那邊的數字是，我們的用戶在消失。
除非，之前拿到的投資，再也無法支撐你的成長神話。
這也沒什麼大不了的。這代表我們應該重新出發，尋找下一個目標。我們也拿到我們想要拿到的東西，我們又賺了幾年高階經理人的薪水，在履歷上又多了一個高階經理人的頭銜。或許有人會問起為什麼要離開，其實業界本來就是來來去去，有什麼好問的呢，但你真要問起的話，我們就說，那是因為公司沒有一開始就把所有的權力交給我們，讓我們的管理才能無法發揮，害得公司無法成長。
我們一定有地方可以去的。在這個業界也一定還會有人需要我們，一定會有人被我們的經歷折服，一定會有其他公司又獲得了投資，又有老闆拿到不知道該怎麼花的錢。
一定會有公司想要成長。
—
老闆們會說，公司是一定得要成長的，如果公司不成長，現在的人才就沒有發揮的空間，最後就會失去人才。所以，多少公司千辛萬苦、汲汲營營，拼死老命，就是得往成長的路上走。
可是，為了成長拿到投資之後，在短時間想要大量招募的人才，那就既沒有嚴格篩選、也沒有長期訓練，新的股東也會插手人事，於是空降一大堆掛著 VP 還是總監頭銜的管理階層，由他們來管理一個原本就可以自我管理的團隊，一個管理層如果不夠，你還可以再加一層，而這些空降主管到底是真的來做事還是急功好利製造績效，你說不動也管不動。
你身邊的人，迅速地從一個團隊，變成巨大而互不信任的科層。
當你拿到投資的同時，就是組織文化邁向沈淪崩壞的開始。
到最後，大概只有薩諾斯才能夠解決你的問題 — 還記得在薩諾斯出場，集滿六顆寶石，讓世界上一半生物消失之前，復仇者聯盟在做些什麼嗎？他們在拯救人類嗎？啊！他們在搞英雄內戰呢！
你所得到的成長是：公司的業務還沒開始成長，公司的人數與規模就開始成長：營收沒有成長，費用就在成長；員工的能力沒有成長，但是會的數量卻加倍成長；對外的影響沒有成長，但是內鬥的火花在成長；還沒有大公司的成就，就先有大公司的毛病；你沒有什麼實質的成長，成長的就只有那麼一份自大。
而無數的企業人士還是嚮往著成長。
—
然後，這家公司還是留著一大批原地繞圈奔馳到死的馬，繼續做著被交辦的工作。還是整天有人想著怎麼繼續瘋狂增加新功能，可以寫程式的 TPM 還是繼續在開會。
也許有一天，終於突然想到要稍微跳出框框，做一個實驗性的新產品，找來一個新來的 PM 負責。這個 PM 在跟工程師開會的第一天，提出需求的時候，還不知道工程師打算要用什麼技術，哪種軟體工程方法，每個部分之間有什麼相依關係，什麼東西得先做不然後面的東西沒辦法開工，或是哪些東西可以平行進行，居然在投影片上就已經畫好了甘特圖。先壓好時程才跟工程師討論，這招也不知道是從哪裡學來的。
也許有一天，有個工程師隨便翻閱到一本流行讀物。他楞了一下。
第一頁，就這麼寫：
「世界上沒有所謂的『持續成長』，偏偏這卻是傳統商業人士所渴求的事。但成長的目的是什麼呢？牛津大學如此有名，它為什麼不在華盛頓哥倫比亞特區設分校呢？一個擁有一二〇個音樂家的交響樂團很成功，為什麼擁有六百個音樂家的交響樂團沒有更成功呢？『成長』完全稱不上是有效的商業策略。」
然後：
「…當前的商業模式教導我們，如果想賺很多錢、或得到長期的成就，我們就要擴大業務規模 — 彷彿大型企業不容易倒、或不會不賺錢（顯然不是事實）。事實上，如果根據這個觀點，我們幻想中的企業甚至還沒起步，我們就必須把成長當成唯一目標，並以這個目標來創造想像中的企業 — 而且最後可能為了豐厚的利潤而賣掉它，然而這種模式並非真理，也經不起批判性科學研究的考證。
根據創業基因計畫（Startup Genome Project）做的一項研究發現，在這項研究中分析的三千二百多間高成長的初期科技業當中，有 74% 失敗了，並不是因為太競爭、或商業計畫太差，而是因為規模成長太快。將『成長』視為首要重點，不僅是個糟糕的商業策略，也是徹底有害的策略。在失敗過程中 — 正如研究所定義 — 這些高成長的初創企業大規模裁員，徹底倒閉，或者廉價出售自己的企業，無論它們的商業想法多符合潮流，把利潤成長當成策略就是它們失敗的原因。」
「…這些公司之所以無法維持，是因為它們把支出與成長，建立在它們認為自己可以達成的收入水準之上 — 或者根據創投注入的資金來發展，而不是根據真實的收入水準。」
「…一間公司的利益，不可能永遠跟它的投資者的利益一致。更糟的是，投資者的利益可能不會始終跟企業最終客戶的利益保持一致。資金注入也會讓企業的掌控權、彈性、速度，以及簡單性降低…」
「…你永遠要問的問題是，我能做些什麼讓我的企業變得更好？而不是我能做些什麼來成長我的企業？」
他蓋上書，長吁一口氣。
—
他想到，最近公司老闆換人了，股東選了一個新的人選。新老闆第一次跟員工說話，就希望全體員工要有，嗯，Growth Mindset。
我們不自許成功。
我們追求成長。
