一句話總結

TinyPilot 正面臨令人稱羨的好問題。

重點回顧

• TinyPilot 的營收驚人成長，從 12 月的 1.5 萬美元躍升至 1 月的 4.2 萬美元。
• TinyPilot 的大部分銷售額來自一支正面的 YouTube 評測。
• TinyPilot 正經歷成長陣痛，我正手忙腳亂地應付需求。

目標評分

每個月月初，我都會訂下當月想完成的目標。以下是我的達成情況：

聘請一位自由接案開發者協助 TinyPilot 開發

• 結果：試用了一位開發者但合作不順利，目前正在試用另一位。
• 評分：A

聘請新開發者的過程很緩慢，但一切都按計畫進行。透過每次的試用合作，我都在學習如何幫助他們更快上手。這也讓我更清楚未來招募時該尋找什麼樣的特質。

獲得兩位部落客或 YouTuber 對 TinyPilot 的評測

• 結果：獲得一支 YouTube 評測，另外兩支正在進行中
• 評分：A-

我低估了 YouTuber 製作新影片所需的時間。有一支新評測上線了，但那是基於我在 11 月進行的接洽。另外兩位 YouTuber 已同意評測，但他們的影片仍在製作中。

話雖如此，其中一支評測的效果好到幾乎讓人難以招架。更多細節請見下方。

透過 Hit the Front Page of Hacker News（《登上 Hacker News 首頁》）獲得 4,000 美元營收

• 結果：獲得 2,600 美元營收
• 評分：C

這門課程的發展不如我預期的那樣順利。我對課程內容感到自豪，但購買的人數遠低於我的預期。

我嘗試了多種不同的行銷手法來推廣它，但沒有任何一種對銷售產生明顯的效果。

TinyPilot 數據統計

對 TinyPilot 來說，這是個驚人的月份。銷售額從 1.5 萬美元躍升至 4.2 萬美元。

每個月我都會想：「哇，這個月真是幸運！我不可能再重現這樣的表現了。」結果下個月又迎來更高的成長，但願這份幸運能持續下去。

TinyPilot 的第一支 YouTube 評測

1 月份的大部分銷售額都來自單一來源：Craft Computing，一個面向專業人士與家庭愛好者、介紹 IT 硬體的 YouTube 頻道。

我去年年初透過它那支關於安裝 Proxmox 的優質教學認識了 Craft Computing 頻道。幾個月後，頻道主持人宣布他已辭去 IT 經理的工作，開始為自己工作，所以我產生了共鳴。

11 月時，我聯繫了該頻道的主持人 Jeff（傑夫），詢問他是否有興趣評測 TinyPilot。他答應了，所以我馬上寄了一台過去。接下來幾個月都沒有消息，我開始懷疑我的 Voyager 是否只是被堆在他那堆廠商免費寄送的硬體山裡。

1 月 12 日，就在我準備就寢時，傑夫來信告訴我評測已經上線。

那感覺很不真實。我和女友在客廳的大電視上觀看，所以我看到追蹤了一年的 YouTuber 拿著我的產品、透過大螢幕直接對著我說話！

傑夫非常喜歡 TinyPilot，並分享了許多讓他印象深刻的地方。整支影片我都提心吊膽，深怕他會突然停下來 說：「老實說……我改變主意了。這產品爛透了。叫你認識的每個人都別買。」但幸運的是，整支評測都保持正面，他的批評也只是小問題。

成效既強勁又即時。隔天，我就收到了 33 筆訂單、創造了 5,000 美元的營收，遠遠超越以往的銷售紀錄。再隔一天，訂單數量雖然下滑，但更多顧客購買了高階套件，因此總營收大致維持不變。

我預期第三天熱度會消退，的確稍微降溫了一些，但訂單仍持續湧入。我的庫存原本設計來應付這類的爆量，但我沒料到熱度會持續這麼久。

第一週，我和 TinyPilot 的出貨經理還能跟上訂單進度，但到了第八天，我們已經筋疲力盡。我們有幾項零件用完，且無法在兩天的出貨承諾期限內補齊，因此暫時將多數產品標示為缺貨待補。幾天後，我們重新站穩腳步，訂單量也回落到可管理的範圍。

TinyPilot 的第一次事後檢討

Blameless postmortem(無責任事後檢討)是我在 Google 工作期間學到最有價值的實務之一。當發生重大問題時，你要先讓系統回到穩定狀態，然後撰寫一份分析事件始末的報告。

顧名思義，這份文件是無責任的。它絕不會寫成：「我們發生服務中斷，是因為 Michael（麥可）是個白痴，刪錯了檔案。」

事後檢討的基本假設是團隊中的每個人都很聰明且勤奮，所以如果出了問題，是系統失靈，而非人的問題。當某次失敗看起來像是某人犯蠢時，根本原因其實是流程未能防範可預期的人為失誤。

在 Craft Computing 的評測之後，我和出貨經理進行了 TinyPilot 的第一次事後檢討。以下是我們發現的主要問題，以及為降低風險所採取的改善措施。

庫存目標水位過低

我們用試算表管理庫存。對於每項零件，我們都會設定最低與最高的庫存水位。舉例來說，Raspberry Pi 的最低庫存為 40，最高為 80。也就是說，每當 Raspberry Pi 的庫存低於 40，我們就會下單補足至 80。

問題在於，我們只有在庫存用完、發現規劃不當後才會調整這些目標水位。而當我們陷入短缺、陷入恐慌時，又很難理性思考新的目標該訂多少。

• 改善措施：根據近期訂單量，每月定期調整庫存目標水位。
• 改善措施：假設下一波訂單高峰會比以往任何一次都更猛烈。
• 改善措施：若曾發生缺貨或差點缺貨的情況，就將該零件的庫存目標加倍。

緊迫性不夠明顯

我們在庫存試算表上的標準流程是，任何低於最低水位的品項就進行「補貨」。當 USB 傳輸線的庫存跌破補貨門檻時，我們依循平常流程下單，並選擇一般的陸運寄送。

我們沒有注意到顧客的購買速度如此之快，在新一批貨到達前，庫存就會歸零。隔天，我們又額外下了一筆隔夜快遞的訂單，以銜接後續的到貨。

• 改善措施：當「現有庫存」欄位的數字達到危險低水位時，以醒目顏色標示。
• 改善措施：升級至 Amazon Business Prime，讓兩日到貨成為理所當然的選項。
• 改善措施：尋找具備趨勢警示功能的庫存管理軟體。

出貨處理時間過短

剛開始經營 TinyPilot 時，我承諾在一個工作天內出貨。很快就發現一天內出貨是不可持續的，因為這會迫使我不斷切換工作內容、匆忙出貨。幾週後，我將對外公告的處理時間改為兩天。

在 YouTube 評測之後，我們手忙腳亂了一週後不得不將商品標示為缺貨待補，但如果當初承諾的出貨時間是三天，就足以提供緩衝、避免進入缺貨狀態。我們發現，過去約有 80% 的缺貨或差點缺貨案例，其實都只差一天的時間。

兩天的處理時間帶來了過大的壓力。反正我們多數訂單本來就是隔天就寄出，顧客對於公告的處理時間是兩天還是三天，應該也不會太在意。

• 改善措施：將對外公告的處理時間延長至三天。

以包裝數量補貨造成不必要的認知負擔

我們有些零件是單個購買，有些則是以每包兩或三個的方式購買。舉例來說，我們的電源轉接器是以每包三個的方式進貨。我們的庫存試算表記錄的是電源轉接器的絕對數量，而非包裝數量。

在爆量期間，我們原本想訂 150 個電源轉接器，卻不小心訂了 150 包 3 入裝，總共 450 個。

雖然超量下單是人為失誤，但也凸顯了我們的系統容易誘發錯誤。下單的人需要針對每項商品進行不同的心算。

改善措施：在試算表中新增「補貨數量」欄位，將每包數量納入計算。

TinyPilot 該如何擴大規模？

TinyPilot 的成長速度遠超出我的預期。幸運的是，現有流程目前還能應付成長，但若持續下去，終將不堪負荷。以下是我計畫在幾個面向擴大規模的方式。

擴大客服能量

隨著 TinyPilot 顧客數量增加，我收到的客服信件也越來越多。有些日子，我有多達一半的工作時間都花在技術支援上。

我回想起一篇來自 Jen Yip（珍·葉普）的部落格文章，她是 Lunch Money 的創辦人。她獨自打理事業的所有面向，並透過在應用程式中實作能幫助使用者自行解決常見問題的功能，來降低客服負擔。

TinyPilot 約有一半的客服請求，其實只是產品功能的缺口。常見的問題是：「要怎麼開啟 WiFi？」目前我會傳給他們一個連結，說明如何透過命令列操作，但這應該是使用者能直接在 TinyPilot 網頁介面中完成的操作。

隨著我持續開發 TinyPilot 的軟體，我正優先加入能消除使用者困惑的功能，並讓除錯工具在出問題時更容易取得。

擴大製造規模

3D 列印的零件很棒，因為設計修改既快速又便宜。缺點是 3D 列印難以擴大規模。製作我的 Voyager 外殼的實驗室，使用我指定的材料每週只能生產 40 個，這很快就會成為瓶頸。

下一個階段是 injection molding(射出成型)。基本上，製造商會用鋼或鋁打造外殼的模具，注入塑膠後再壓製成型。製作模具既耗時又昂貴，但一旦完成，每天就能以低成本生產 1,000 個。我向多家廠商詢價，回覆的報價落在 2 萬至 4 萬美元之間，目前來說有點太高。

我聯繫了其他實驗室，想看看能否平行化 3D 列印。問題在於，我喜歡的材料是一種在 3D 列印實驗室中並不常見的碳纖維材料，所以沒有太多其他廠商有提供。有提供的廠商，其報價比我目前支付的價格高出 10 到 15 倍。不過，Voyager 的利潤夠高，即使外殼成本提高，必要時我仍能獲利。

其中一間實驗室告訴我，使用另一種列印速度更快的替代材料，也能達到類似的效果。我正在向他們索取樣品，並與主要合作的實驗室洽談替代材料。

我的女友兼庫存經理負責最後的製造步驟，例如測試電路板和組裝 Voyager。我們可能會遇到她沒有足夠時間處理訂單出貨、庫存管理、組裝以及其他工作，同時還要兼顧全職研究生身分的情況。因此，我們正在評估當她的工作時間達到上限時，哪些工作可以外包。

擴大開發能量

除了經營 TinyPilot 的其他事務外，我很遺憾地幾乎沒有時間投入軟體開發。12 月時，我開始尋找兼職開發者來分擔工作。我準備了這兩份文件來說明工作內容，並在幾個小型的社群管道中分享：

• 職務說明
• 與我合作的指南

在我招聘過的所有自由接案職位中，軟體開發始終是最具挑戰的。我對軟體品質要求很高，因此很難找到對品質與可維護性同樣抱持熱情的開發者。

我不進行面試，而是直接進入試用合作。第一位試用者合作不順利，但他們表示對流程感到滿意。這也幫助我找到讓新開發者更快上手程式碼庫的方法。

舊有專案

以下是一些我仍在維護、但並非主要開發重心的專案的簡要更新：

Hit the Front Page of Hacker News

《Hit the Front Page of Hacker News》是我為開發者族群撰寫的部落格課程，終於在 1 月上線了。雖然上線前後銷售額有所提升，但遠低於我的預期。我對這門課程的目標是在年底前賺進 2 萬美元，現在看來不太可能實現。

當我告訴 Cory Zue（柯瑞·祖）我對目前的銷售感到失望時，他取笑我說 TinyPilot 的營收已經把我寵壞了。這門課程光是 1 月的營收，就超過了我擔任獨立開發者第一年的總收入。

Is It Keto

Is It Keto 創下了單月新高，即使我完全沒有動過這個網站。由於它與飲食有關，每逢新年新希望的時期，總會出現一波關注度的高峰。

Zestful

Zestful 仍在小幅成長，儘管它處於維護模式。成長似乎來自一位長期客戶的使用量增加。

總結

完成了什麼？

• Hit the Front Page of Hacker News 上線了。
• TinyPilot Pro 從測試版正式發布。
• 完成了 TinyPilot 的第一次事後檢討。
• 以試用形式聘請了兩位自由接案開發者。

經驗教訓

• YouTube 評測的效果可能非常強大，但需要時間。
  • 看到第一支評測的成果後，這絕對是我想進一步探索的管道，但要安排新的評測還需要幾個月的時間。
• 隨著成長，請重新檢視流程背後的假設。
  • 這是我一再學到的教訓。我經常為某項任務建立流程後，就讓它變成習慣。但接著我便不再批判性地思考流程，也沒意識到當初設計流程時的條件可能已經不再成立。
  • 定期退一步檢視流程是否仍是最佳方案，是非常重要的。

下個月的目標

• 吸引五位部落客或 YouTuber 加入 TinyPilot 的聯盟行銷計畫。
• 為 TinyPilot 新增兩項能降低客服或製造成本的功能。
• 向 10 位顧客收集對於 TinyPilot 機架式版本的回饋。