一句话总结

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》获得 4000 美元收入

• 结果：获得 2600 美元收入
• 评分：C

这门课程的实际表现并未达到我的预期。我为课程内容感到自豪，但购买人数远低于我的预期。

我尝试了多种不同的营销方法，但似乎都没有对销量产生明显的影响。

TinyPilot 数据

这对TinyPilot 来说是极其惊人的一个月。销售额从 1.5 万美元飙升至 4.2 万美元。

每个月我都会想：“哇，这个月真是走运！下次肯定没法再复制了。”结果下个月的增长反而更高，只能希望这份好运能继续下去。

TinyPilot 的首次 YouTube 测评

1 月份的大部分销量都来自同一个来源：Craft Computing，一个面向专业人士和家庭爱好者、专注于 IT 硬件的 YouTube 频道。

我是在去年初通过它那篇关于安装 Proxmox 的优质教程发现这个频道的。几个月后，频道主宣布他已辞去 IT 经理的工作开始单干，我对此颇有共鸣。

11 月时，我联系了频道主 Jeff，问他是否有兴趣测评 TinyPilot。他答应了，于是我立刻寄了一台过去。之后几个月杳无音信，我一度怀疑我的 Voyager 是不是被埋在了各家公司寄给他的那堆免费硬件里。

1 月 12 日那天，就在我准备上床睡觉时，Jeff 发来邮件说测评已经上线了。

那种感觉很不真实。我和女朋友在客厅的大电视上观看，看到自己关注了一年的 YouTuber 拿着我的产品，在巨大的屏幕上直接对着我侃侃而谈！

Jeff 非常喜欢 TinyPilot，并分享了许多让他印象深刻的地方。整个过程中我都提心吊胆，生怕他突然话锋一转说：“其实……我改主意了，这产品很糟糕，别让身边的人买。”好在整个测评都非常正面，他的批评也只是一些小问题。

效果立竿见影。第二天我就收到了 33 笔订单，营收 5000 美元，远超以往的销售纪录。第二天订单数有所回落，但更多顾客购买了高配套件，所以总营收基本持平。

我原以为第三天就会回落，确实稍有下降，但订单依然源源不断。我的库存原本就设计为能应对这样的突发高峰，但没想到会持续这么久。

第一周，我和负责履约的同事还能跟上订单节奏，但到了第八天，我们已经精疲力竭。有几种零件库存告急，无法在两天的发货时限内补货，只好暂时将大部分商品标为缺货预订。几天后，我们缓过劲来，订单量也回落到了可控范围。

TinyPilot 的第一次事后复盘

无指责复盘是我在谷歌工作期间学到的最有价值的实践之一。当出现重大问题时，先恢复到稳定状态，然后撰写一份分析事件经过的报告。

顾名思义，这份文档是无指责的。里面不会出现“这次故障是因为 Michael 太蠢，删错了文件”这样的表述。

复盘背后的假设是，团队中的每个人都是聪明且勤勉的，因此如果出了问题，错在系统而非个人。当一次失误看起来像是某人犯了低级错误时，根本原因其实是流程未能防范可预见的人为失误。

在 Craft Computing 的测评之后，我和履约负责人一起进行了 TinyPilot 的第一次复盘。以下是我们发现的主要问题以及为此采取的改进措施。

库存目标定得过低

我们用一张表格来管理库存。对每种零件，我们都会设定最低和最高的库存量。例如，树莓派的最低库存是 40，最高是 80。也就是说，一旦树莓派库存低于 40，我们就会下单补货至 80。

问题在于，我们只有在库存耗尽、意识到计划不周时才会去调整这些目标。而当真正出现短缺时，我们又慌乱不已，很难理性地思考新的目标该定为多少。

• 改进措施：每月根据近期的订单量定期调整库存目标。
• 改进措施：假设下一波订单高峰会比以往任何一次都更猛烈。
• 改进措施：一旦某种零件出现缺货或险些缺货，就将其库存目标翻倍。

紧迫性不够直观

我们处理库存表格的常规流程是，只要某个零件低于最低库存就进行“补货”。当 USB 线的库存跌破补货阈值时，我们按惯例用普通陆运下单补货。

我们没有意识到顾客的购买速度如此之快，按这个趋势，新货到达之前库存就会清零。第二天，我们又额外下了一笔隔夜加急订单，以衔接到后面的那批货。

• 改进措施：当“现有库存”一栏的数字降至危险水平时将其高亮显示。
• 改进措施：升级到 Amazon Business Prime，让两日达成为默认选项。
• 改进措施：寻找能基于趋势进行预警的库存管理软件。

承诺的发货时效太短

刚开始做 TinyPilot 时，我承诺一个工作日内发货。很快我就发现一天周转根本不可持续，它迫使我不断切换上下文、匆忙发货。几周后，我把承诺的周转时间改成了两天。

YouTube 测评之后，我们手忙脚乱了一周后不得不将商品标为预订状态，但如果当时承诺的发货时效是三天，这个缓冲就足以让我们避免进入预订状态。我们发现，之前约 80% 的缺货或险些缺货的情况，其实都只差一天。

两天的时限带来了过大的压力。实际上我们大多数订单本来就是次日发出，顾客想必也不会太在意官网上写的是两天还是三天。

• 改进措施：将对外承诺的发货处理时间延长至三天。

按包补货增加了不必要的认知负担

有些零件我们按单个购买，有些则按每包两件或三件购买。例如，电源适配器是按每包三件进货的。而我们的库存表格记录的是电源适配器的绝对数量，而非“包数”。

在那次抢购高峰中，我们本想订 150 个电源适配器，结果误订了 150 包 3 件装，总共 450 个。

这次多订是人为失误，但也暴露了我们的系统很容易诱发错误。下单的人需要针对每种零件做不同的心算换算。

改进措施：在表格中新增一列“补货数量”，自动计入每包数量的换算。

TinyPilot 如何实现规模化？

TinyPilot 的增长速度远超我的预期。好在现有流程目前还能勉强支撑，但如果继续增长，体系很快就会不堪重负。以下是我在几个维度上对规模化增长的规划。

扩大客服能力

随着 TinyPilot 客户数量的增加，我收到的客服邮件也越来越多。有些日子，我多达一半的工作时间都花在了技术支持上。

我想起 一篇博文，作者是 Lunch Money 的创始人 Jen Yip。她独自打理公司的方方面面，并通过在应用中加入帮助用户自行解决常见问题的功能，来减轻客服负担。

TinyPilot 约有一半的客服请求，其实源于产品本身的功能缺口。一个常见的请求是：“怎么开 WiFi？”目前我会给他们发一个链接，教他们如何在命令行中操作，但这本该是用户能在 TinyPilot 的网页界面上直接完成的事。

在后续的软件开发中，我会优先加入那些能消除用户困惑的功能，并让出错时的调试工具更易于使用。

扩大生产能力

3D 打印零件的好处是设计调整快速且成本低，缺点则是难以规模化。为我生产 Voyager 外壳的实验室，使用我指定的材料每周只能生产 40 个，这很快就会成为瓶颈。

更进一步的方案是注塑成型。原理是厂家先用钢或铝制作外壳模具，再注入塑料压制成型。开模过程缓慢且昂贵，但一旦模具完成，每天就能以很低的成本生产 1000 个。我向多家供应商询过价，报价在 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 测评威力巨大，但需要时间。
  • 鉴于第一条测评带来的效果，这无疑是我想进一步探索的渠道，但要安排新的测评还需要几个月时间。
• 随着业务增长，要重新审视流程背后的假设。
  • 这个教训我得反复学习。我常常为某项任务建立一套流程，然后就养成了习惯。但随后便不再批判性地审视流程，意识不到当初设计它时的前提可能已不再成立。
  • 定期退后一步，审视流程是否依然最优，这一点至关重要。

下月目标

• 为 TinyPilot 的联盟推广计划吸引五位博主或 YouTuber。
• 为 TinyPilot 新增两项能降低客服或制造成本的功能。
• 就 TinyPilot 潜在的机架式版本收集 10 位客户的反馈。