TinyPilot:第 32 个月
原文由 Michael Lynch 于 发布,订阅该博客
一句话总结
我在 TinyPilot 创业以来最长的一次休假
第一次看?
你好,我是 Michael。我是一名软件开发者,也是 TinyPilot 的创始人,这是一家独立的计算机硬件公司。我在 2020 年创办了这家公司,如今月营收在 6 万至 8 万美元之间,团队除我之外还有六名员工。
每个月,我都会像这样发布一篇回顾,分享公司业务和我个人工作状态的近况。
亮点
- 我出国休假了两周,期间 TinyPilot 运转顺利,完全不需要我操心。
- TinyPilot 办公室发生水管爆裂,险些酿成大祸。
- 我正在探索被动响应式工作和主动规划式工作之间的平衡。
目标完成度
每个月初,我都会定下当月想要完成的目标。以下是本月的完成情况:
恢复 TinyPilot 设备的正常现货库存水平
- 结果:库存量仍未达到我的预期。
- 评分:C
库存依然紧张,履约团队遇到了不少突发状况。为尽快恢复正常,我已经上调了价格并大幅削减了广告支出。
启动向新第三方物流(3PL)服务商的过渡
- 结果:已与新的 3PL 服务商签约,正在准备向其发送首批货物。
- 评分:A
我对这家新的 3PL 很有信心。一旦把履约环节交给外部服务商,团队的压力就能大大缓解,我们也能腾出精力投入到其他有助于更快扩张的领域。
推动开发团队与技术支持团队的跨团队协作
- 结果:TinyPilot 召开了首次开发与技术支持联合会议。
- 评分:A
开发和技术支持团队之间有一些可以协作的工作,但我一直想等到两个团队能面对面交流时再推进。我们已经开了第一次开发与技术支持的联席会议,接下来两个团队就可以直接开展合作了。
TinyPilot 运营数据
| 指标 | 2023 年 1 月 | 2023 年 2 月 | 变化 |
|---|---|---|---|
| 独立访客 | 8,092 | 12,141 | +4,049 (+50%) |
| 总浏览量 | 16,665 | 23,117 | +6,452 (+39%) |
| 销售收入 | $66,420.52 | $72,585.15 | +$6,164.63 (+9%) |
| 企业订阅收入 | $290.70 | $290.70 | 0 |
| 版税收入 | $5,689.93 | $3,935.73 | -$1,754.20 (-31%) |
| 总收入 | $72,401.15 | $76,811.58 | +$4,410.43 (+6%) |
| 利润 | $8,552.79 | $32,905.55 | +$24,352.76 (+285%) |
尽管我一直在有意控制销量,营收却仍在增长,处境有些微妙。履约团队在完成现有其他工作的同时,已经没有余力去处理更多订单。销量上涨可能是口碑传播的自然结果,也可能是因为过去几个月新增的功能吸引了更多客户购买。
我预计,一旦把履约交给 3PL 服务商,月营收就能达到 9 万美元。目前我们受限于履约能力,而一旦完成向 3PL 的过渡,这个瓶颈就会消失。
我们已经连续第七个月实现盈利(确切说,是过去三个月的平均利润为正,因为我们的利润波动较大)。照这个趋势,我们将轻松超额完成我定下的 2023 年实现 10 万美元利润的目标。
“你是做 TinyPilot 的那个人吗?”
上个月某个周六下午,我正在家里的书房,突然听到有人敲前门。我穿着睡衣去开门,门口站着一位四十多岁的中年男子。他开口问道:“你是做 TinyPilot 的那个人吗?”
糟了。怎么会有人不请自来跑到我家来问 TinyPilot 的事?
我赶紧回想最近有没有什么客户纠纷,会让人找到我家来找我麻烦。想了半天,没想起有什么事。
“算是吧……”我谨慎地回答。这位不速之客解释说,他是 TinyPilot 办公楼的维修工。他没有我的电话,但设法找到了我家的地址。
“办公室的水管爆了,我们进不去你们那间,能麻烦你过去一趟吗?”
听起来可不是什么好消息。
我开车跟着他赶往 TinyPilot 办公室,一路上在心里盘算,如果所有库存都被水泡了,公司还能不能撑下去。就算能拿到保险赔偿,重新生产的周期也会让我们几个月无法正常运营。
到了我们那一层,我看到与 TinyPilot 相邻的会议室里喷淋系统已经启动。我打开 TinyPilot 办公室的门,长舒了一口气——我们的房间里一点水都没进。

与 TinyPilot 相邻的办公室水管爆裂,室内物品全部被毁。
他们说在消防部门检查签字之前,几天内都不能进入我们的房间,因为大楼的喷淋系统已经失效。到了周一,我给房东打了电话,他说我们可以恢复正常使用办公室了。
我以为事情就此结束了,可几天后,一位负责履约的同事问我是不是要搬办公室。“没有啊,为什么这么问?”我反问道。“哦,维修工随口说了一句,说我们可能得搬走。”
糟了。
我赶紧给房东打电话问个究竟。他倒是——说得非常轻描淡写——没错,我们可能得在周二之前搬到一间新办公室。而这通电话打的时候已经是周五了。
房东解释说,由于水损,施工方可能需要更换我们的一面墙。不过不用担心——他有一间空余的办公室可以给我们用。新办公室比我们现在的要小 40%,而我们现在的办公室已经用了 80% 的空间,搬过去肯定会很挤。我问要在小办公室待多久,他说也不清楚。
接下来的几天,房东对于我们是否要在几天内彻底搬走这件事,态度一直很无所谓。可这对我来说就很棘手了,因为我马上就要去欧洲两周,到时候根本没法去新办公室搭建 IT 基础设施。
出发前的每一天我都打电话问那面墙到底怎么处理,房东却始终给不出准话。最后我决定,只把电脑、打印机和网络设备先搬到那间备用办公室,因为只有这部分工作在我不在时会比较麻烦。
一周后,我们收到消息,说那面墙可以保留,不用搬了。履约团队因此耽误了大约一天的工作,我也花了两天时间做应急预案,虽然损失不算大,但那种不确定性让人倍感压力。
这件事也让我更坚定了要把履约迁移到新的 3PL 的决心。我真心希望不再因为办公室出点状况就导致整个履约工作陷入停滞。当然,水管在 3PL 那边也可能爆,但到时候如何腾挪、如何恢复运营,就成了别人的问题了。
我在 TinyPilot 期间最长的一次休假
今年二月,我休了自创办 TinyPilot 以来最长的一次假。我在欧洲待了两周多。
这次行程的起点是去德国图宾根参加一场婚礼。那段时间里,我完全没有查看工作邮件。

在德国图宾根市政厅参加婚礼
与我共事的许多 TinyPilot 成员都住在欧洲,所以我又多留了一周,开启了我所谓的“TinyPilot 欧洲之旅”。行程包括:
- 在德国卡尔斯鲁厄住两晚,拜访 punkt.de,TinyPilot 的欧洲分销商
- 在德国柏林住两晚,拜访 TinyPilot 的一位开发者
- 在英国伦敦住两晚,拜访 TinyPilot 的两位技术支持工程师
这次旅行也是对 TinyPilot 离开我能否正常运转的一次检验,结果总体还不错。订单都按时发出了,用户也得到了正常的支持。
之前我在 TinyPilot 期间最长的一次完全不看工作邮件的休假是五天,而这次达到了 11 天,之后还有一周在路上,网络时断时续。
对本地团队而言
履约团队虽然跟上了订单进度,但已经接近满负荷运转。我们仍在消化切换到 Voyager 2a 带来的影响,这款设备组装时间要多 30%。我们还首次推出了旧设备换新折扣活动,这也给履约团队增加了负担。办公室的那档子事更是雪上加霜。
总的来说,履约还算顺利,但余量比我希望的要小得多。如果有人病倒几天,我们就会捉襟见肘。
同样,这次经历也再次坚定了我把履约外包给 3PL 的想法。由第三方来负责履约后,需要我们自己处理的紧急事务会大大减少,团队应对短期压力或人员缺勤的能力也会更强。
对技术支持团队而言
TinyPilot 的技术支持团队在我不在时也运转良好。平时,技术支持工程师可以选择将问题升级给我处理。而在我休假期间,他们独立解决了所有问题,用户依然获得了高质量的支持。
不过,技术支持团队确实经历了一次“空档期”——有一段时间没人能及时回答技术问题。其中一位技术支持工程师恰好在我休假期间有两天计划休假,而另一位工程师又在同一时间生病了。
以我们团队的规模,我觉得很难完全避免这类空档。这虽然少见,但三个人同时需要休假的情况确实可能发生。
团队对此感到很自责,所以我能做的最实际的事,就是明确告诉他们:这种空档是我的责任,不是他们的。我固然不想让客户得不到技术支持,但更重要的是尊重团队成员的休息时间,不让他们在休假或生病时还感到必须工作的压力。
对开发团队而言
开发团队在我外出期间工作得很顺利。只有少数小任务因为需要我做决定而暂时搁置,但团队对产品路线图已经足够了解,能够在我不在的情况下继续推进。
过去几年里,我一直在努力赋予开发团队更多的自主权和责任感,看到我的缺席没有过多拖慢他们的进度,我感到很欣慰。
团队的主动性工作,会给创始人带来被动响应式工作
过去几个月里,我一直在思考 TinyPilot 在被动响应和主动规划这两类工作之间的平衡。
回复一张工单就是被动响应式工作的典型例子。它有很强的时效性,但影响有限,因为一次只帮助了一位发邮件的用户。而主动规划式工作,则是去修复产品或完善文档,让用户根本不需要提交工单就能解决问题。
直到最近我才意识到,员工的主动性工作往往会转化为我的被动响应式工作。比如,技术支持工程师写了一篇新的教程,这是很有价值的主动工作,但我需要去审阅它,而这对我来说就是一项被动的任务。
审阅文档也有时效性,因为我想在作者对内容还记忆犹新时给出反馈。而且相比自己写,我发现给别人的文字提修改意见更费神。当我在别人的写作中看到一个细微的问题时,往往很难准确地指出并清晰地表达问题所在。
过去几个月,我越来越成为了团队主动性工作的瓶颈。我反复问自己,是否应该放手让团队按自己的方式去写,但答案始终是“不”。我非常重视我们的文档,并且认为保持风格一致很重要。
开发团队也经历过类似的过程。起初,我会审查每一处代码改动。大约五个月后,我们改成了同行评审,现在大多数软件开发工作已经不需要经过我了。
我希望技术支持团队也能走过同样的历程。要写出符合我要求的风格,学习曲线很陡,但如果我们持续投入,同事们最终会掌握我想要的风格,并能在内部互相审阅文稿。
我的体会是,即使是委派任务,也要考虑自己的精力。有些任务会产生让我难以审阅的后续工作,所以在布置任务时,就要预判自己在任务完成后是否有时间做出高质量的审阅。
收尾
完成了什么?
- 完成了一次为期两周、兼具私人与工作性质的旅行。
- 与新的 3PL 服务商签订了合同。
- 发布了 TinyPilot Pro 2.5.3,新增了音频串流功能。
经验教训
- 分配任务时,要考虑自己需要投入多少精力去审阅。
- 即使前期工作可以不依赖我完成,有些任务的审阅本身也需要耗费大量精力。
下月目标
- 将一款低销量产品的履约工作迁移至新的 3PL。
- 在 NERD Summit 2023 上做分享。
- 减轻履约团队的负担,使被动响应式工作占其时间不超过 80%。
求助
这个月我在尝试一个新做法:公开说明读者可以如何帮助我。如果你是这个博客的读者,并且认识符合我需求的人选,欢迎给我发邮件。
在探索将生产转移到中国的过程中,我发现这比我预想的要复杂得多,涉及许多我毫无经验的领域。
如果你认识有每月 500 至 5000 台规模电子产品制造经验的人,我很希望能与他们聊聊。我愿意考虑引入联合创始人、聘请顾问,或者只是与愿意分享经验的人随便聊聊。
随机一篇博客
评论
登录后参与讨论