一个新项目刚开始时，眼前常常什么都有，又什么都没有。
有很多人的判断、一些零散的用户声音、可以迅速实现的技术，也有一个听起来很大的目标。大家会讨论产品形态、商业模式和长期想象，却不一定知道明天先做哪一步。
我最有能量的，通常就是这个阶段。
我喜欢把散落在桌面上的东西一件件捡起来，找到一条最短的路径：从一个真实问题出发，做出最小体验，找到第一批用户，再用结果决定下一步。
第一条路，不是第一个完整产品
做「萌芽」时，我们没有一开始就开发一个功能齐全的应用。
我先把产品想解决的问题做成 Mockup，用小红书招募外部用户，同时推进最小的对话体验。我们事先写下继续与停止的条件：是否有人愿意报名，是否真的开口，是否在对话里得到价值，以及第二天会不会回来。
最后，62 位非帆书用户接受招募；72 位用户注册，49 位产生对话，18 位连续聊了 10 句以上。拉新和首次价值成立，次日留存却只有 15%，低于原定的 30%。
这条路没有把我们带到一个成功产品，却把不确定的问题变得具体了：人愿意来，也会在「被整理、被看见」的瞬间感到惊喜，但现有形态没有创造持续使用的理由。
如果一开始就做一个庞大的版本，我们可能会用更多功能解释这个结果。因为路径足够短，答案反而更清楚：原来的假设不成立，应该停。
0 到 1 的核心，不是一个人包办所有事情
从外面看，0 到 1 很容易被写成一种英雄叙事：一个人想出点子、画页面、写文案、找用户、做运营，最后把所有事情都完成。
我的确常常跨过岗位边界工作。除了技术实现，我会尽量把用户链路、产品结构、PRD、页面、招募、访谈、商业化和复盘接起来。这样做不是因为每一项都必须由我完成，而是新项目最怕关键问题散落在不同分工里，没有人把它们连成一个判断闭环。
但「我什么都做」不是能力本身。真正重要的是，我能不能明确：
- 这一次先验证什么；
- 什么证据足以继续；
- 哪个结果出现时应该停止；
- 跑通以后，怎样让别人接得住。
技术同事负责实现，并不减少我对整体路径的责任；同样，我负责整体，也不意味着可以把技术成果算成自己一个人的功劳。0 到 1 需要边界清楚的协作，而不是模糊所有人的贡献。
第一条路的终点，是让项目不再只存在于某个人脑子里
有些人擅长把已经成立的业务做得更稳定：细化流程、管理团队、提高转化、日复一日地优化同一个系统。那同样是一种很难的能力。
我更喜欢的，是在还没有答案时，找到第一批真实用户，把模糊问题压缩成可测试的动作。当路径证明成立，我会把流程、指标和关键判断交给更擅长规模化的人；如果不成立，也要留下清楚的复盘，而不是把失败藏起来。
因此，快速并不等于不停地做新东西。没有停止条件的试错，只会制造一堆半成品；没有记录和交接的开路，也只是把混乱留给后来的人。
一条真正被跑出来的路，应该让团队知道从哪里出发、经过什么、哪里容易走错，以及下一次如何走得更稳。
我喜欢 0 到 1，不是因为空白看起来更自由。
而是因为在最混乱的时候，把第一条路径变得清楚，会让所有人终于可以围绕同一个现实继续往前。