這篇文章大多是靠 Wispr AI 即興口述完成的

我給自己定下的一個基本原則是，既然要經營一間遠端公司，就把原本會花在辦公室租金上的錢，拿來讓大家實體見面，每季至少一到三次。我們剛結束在聖路易舉行的第一次全員聚會（也就是三個人的 offsite），只有短短兩天半，但感覺相當有成效，所以想把一些覺得值得延續、也想推薦給其他人的心得記錄下來。

讓每一個小時都有任務

我在白板上做的第一件事，就是把這次聚會的每一個小時都標出來，並列出我們想在 offsite 期間完成的所有事項（基本上就是團體版的時間區塊規劃）。我們也確保每個人都能提出自己想涵蓋的議題，讓大家離開時都覺得自己想談的都有談到、有所收穫。

這種做法的典型問題是，低估的誤差會不斷累積。一個原以為一小時就能談完的議題，可能會花上三小時，這完全是正常的。你可以透過在每天的最後預留一些彈性時間來緩衝這些超時的延伸（也就是打上問號的時段）。因為我們還在非常早期的階段，所以接下來要談的這些議程，我們事前都沒有特別準備。而在規模較大的 offsite，我看過有人會在開始前一、兩天就先做好準備，確保每個議程都有足夠的背景脈絡。

財務回顧

我們幾個加起來待過四、五間有辦 offsite 的遠端公司，但很少有公司會在期間做完整的財務回顧。我猜這多少是出於不想公開所有財務細節（包含每個人的薪水）的保守心態，加上當客戶和產品品項很多時，會計本身就很複雜。這對我們來說不是問題，因為目前我們的薪資是完全透明的，資金來源和客戶／營收來源也都相當單純。

這個會議的基本目標，是讓公司裡的每個人離開時都清楚錢在哪裡、錢從哪裡來／到哪裡去，以及未來我們最有可能從哪裡賺到更多錢。這能讓大家，尤其是員工，對公司的現金跑道還有多長、以及事業根本上的可行性，感到比較安心。

對我們而言，這只花了 15 分鐘，因為實在太簡單，我憑印象就能直接講完。

客戶回顧

我們越了解自己是為哪些客戶打造產品，產品與工程的優先順序就越清晰。我得承認，這部分我們還在摸索，也不太確定能給什麼建議，只能說我確實堅信，以客戶為中心、對客戶著迷，才是讓公司成長的正確方式——至少能讓公司保持誠實——相較於以技術、研究為中心，或是以「氛圍」為中心。

架構導覽

把整個程式碼庫丟進 ChatGPT，請它用 Mermaid 畫出一張圖，用方塊和箭頭標示各個主要區塊的關聯。接著放到 Excalidraw 上，依喜好微調、配色，讓整張圖大致合理。然後帶著全公司一起走讀一遍。

基本原則是：每個人都有權對下一步該做什麼發表意見，但我們必須先對「今天已經有了什麼」這些基本事實達成共識。

有人質疑過為什麼這個練習很重要。理論上，在規模較大的公司，執行長應該可以把技術團隊當成黑盒子，不再需要關心實作細節。但撇開團隊規模不談，我仍然認為，讓非工程背景的人也理解架構是很重要的，這樣才能理解團隊已經做出的技術押注，不會提出離譜的功能需求，甚至有機會主動發掘系統中可以產品化的設計。

當然，身為技術背景的創辦人，我也會藉這個機會，安插一些自己想推動的想法，而這就銜接到下一個討論……

原則會議

Offsite 的好處在於，它是一個刻意跳脫日常的機會，讓我們得以「經營事業」而非「在事業中忙碌」。這個概念是我從 Richard Gerber 的《E-Myth Revisited》這本書聽來的，雖然我其實沒讀過，但聽夠多人談過，感覺就像已經讀過一樣。所以這場會議明確要談的是：我們如何工作，以及未來想如何繼續工作下去。

身為第一次創業的創辦人，我覺得這場會議特別讓人耳目一新，它是用最小力氣創造出我一直想待的那種公司的最高槓桿方式。我可以在大家面前公開表達自己最相信的原則，藉此讓自己被監督，進而培養出能累積成功的習慣。換句話說，我可以直接把我相信的工作文化說出來，讓它成形，大家可以提出不同意見，或大致上接受。

這場原則會議的主要靈感來源，大概是 Amazon 的領導原則，以及 Ray Dalio 談原則的那本書。Ray 最核心的原則是「痛苦＋反思＝進步」。在 Amazon，則有由 Jeff Bezos 提出的 14 條領導原則，定義了各種鮮明的立場。我認為原則貴在精簡——所以原則裡的每一個字都要有分量，這樣才有重量。如果原則太多，就記不住，也很容易為自己不遵守找藉口。我們最後訂出了 5 條原則，這大概還是多了一、兩條，因為已經比公司的人數還多了。當然，最難的就是對合理的增補說不。

一場核心、尚未定案的原則辯論

目前我在 AI 領域最堅信的一條原則是「產品帶動流程，流程帶動平台」。換句話說，我們會從第一性原理出發，思考對客戶而言最好的產品是什麼，並不計代價做出最好的產品——無論那是軟體與人力混合的成果。接著，我們會把其中的人力部分系統化為流程，最後再盡可能把這些流程轉化、編碼、泛化為軟體。

這與我看過一些把平台放在第一位的新創恰好相反。例如，先打造一個什麼都能做的開源產品或雲端產品，再去外面尋找客戶與使用場景。

我的大致感覺是，在 AI 領域最成功的領導者，都是打造出能封裝某種神奇或前沿體驗的產品，人們其實不太在乎底層能不能用到 API，他們只在乎最終的成果。

如果未來你再推出驅動這些體驗的開源產品或 API 平台，使用者就會因為產品的品牌而被吸引，進而採用你的平台，就像 Amazon.com 後來推出 Amazon Web Services 時，能為其背書一樣。當然，這個原則也有例外。一方面，像 Character AI 這樣以產品為優先的公司，即使產品處於領先地位，也不一定能獲勝，也不一定能成功將產品或平台變現。另一方面，也有一些沒有強烈產品主張領軍的平台，仍然取得相當的成功——例如 Together AI、Braintrust 和 Fireworks。

我確實擔心，把產品放在第一位而非把客戶放在第一位，會讓我們有藉口變得以產品為中心，而不是以客戶為中心。而這正是我認為目前這條公司原則的缺陷所在。

一條更簡單的原則

我提出另一條比較簡單的原則，雖然經過一些辯論，但最終還是被接受了，那就是每天都要發布程式碼。這是一條行為層面的原則，而不是理論或商業策略層面的，但我喜歡它能帶來的動能。

背後的故事是 Nat Friedman 接任 GitHub 執行長時的作法：大多數新任執行長上任後，會先花三到六個月與高階主管進行傾聽之旅，才開始採取行動。但 Nat 卻說：「我們要在接下來的 100 天內發布 100 項成果，並從中發現阻礙」——透過實作來了解公司是如何運作的。

顯然，在一間小公司裡，這句話比較沒有爭議，但我認為，正是這種貼近程式碼、也就貼近產品的承諾，幫助我們快速前進。在新創公司，身為新創就意味著要快速行動、迅速回應新技術與客戶需求。

這條原則也直接體現在我們一開始提到的時間區塊規劃中。我們在 offsite 的每一天都留下了寫程式的時間，回應了我們原本擔心一做這種後設工作，實際工作就會停擺的疑慮。

Bus Factor 交接

同樣地，這場會議大概在小小公司最有用。目標是讓最熟悉系統的人，帶著其他人走過整個系統的運作方式、取得權限與管理者帳號，並熟悉系統管理。這樣一來，就算有人休假，任何人都能接手繼續；即使有人暫時無法聯繫，其他人也能想辦法把系統重新架起來，只是可能要多花一點時間。

我會建議開一個 Zoom、分享畫面並錄影，這樣最後就會有一份完整的流程錄影可以回頭參考。有一些 AI 產品能直接從這類錄影自動產生操作手冊（runbook），不過我還沒試過任何一款，所以無法推薦。

腦力激盪

在日常工作中，大家會拋出很多關於該做什麼、能做什麼的想法——無論是核心產品本身，還是產品延伸或其他想嘗試的實驗。這場會議讓大家有空間一起激發創意、集思廣益，但可惜的是，要從發散切換到收斂非常困難。

我建議另外安排一場專門用來做優先順序排序的會議，我們就是在 offsite 的最後這麼做，才得以收斂。

優先順序排序

最終，決定優先順序是創辦人／執行長／產品經理的工作，所以這不完全是一場民主的練習。不過，把所有想做的事情攤開、列在白板上，並承認永遠沒有足夠的時間全部完成，因此必須做出艱難的取捨，還是很有幫助的。

我發現許多優先順序的評估框架，包含 Linear 和 JIRA 式的評分方式，最大的問題在於沒有考慮到優先順序會隨時間改變。評分系統或艾森豪矩陣式的評分方式，都沒有納入嘗試的價值，以及在用小而簡單的步驟獲取資訊時所面臨的戰爭迷霧。因此我提議採用一套雙指標評分系統，分別針對想法的「容易度」與「潛力」，以 1 到 10 分評分。接著我們會試著為這兩個維度的分數範圍建立基準（也就是定義在容易度上 1 分和 10 分分別代表什麼，在潛力上 1 分和 10 分又分別代表什麼）。

然後我們會用這兩個分數相乘或相加，作為積分系統來排序我們想投入的想法。我們對容易度的量尺還不太習慣……

大家在容易度上卡得最久，因為我們把那個 E 直覺當成了「費力度」（effort），但我們又希望分數越高代表越好，同時也認知到我們不能只挑容易摘的果實。我們想挑的，是預期報酬不錯的低垂果實，以及雖然較困難、但長期來看也預期有回報的事物的組合。

社交活動

大多數人都對尷尬的團康活動感到厭煩。老實說，除了大家一起吃飯、去逛了 Blueberry Hill 之外，我們也沒特別安排什麼社交活動——如果有到聖路易，我非常推薦大家去那裡看看。我覺得這樣就挺好的，不過我也很樂意聽聽適合像我們這樣小團隊的、更好的聚會點子。