创始人烧光300万后才懂：产品完成度20%就够了

YC（Y Combinator，美国知名创业孵化器）的合伙人有个冷笑话：最危险的创始人不是懒的，是太勤奋的。他们能在6个月里做出一个"看起来完整"的产品，然后花6个月发现没人用。

这不是段子。2023年Startup Genome报告显示，70%的初创公司死亡不是因为想法烂，是因为在产品验证前就把钱花光了。更具体点，平均每个失败团队浪费了11个月在"完善功能"上——而用户真正在意的，可能只占他们工作量的五分之一。

那个"再加一个功能"的陷阱

我见过最典型的路径是这样的：创始人有清晰愿景，第一周画好核心流程，第二周开始写代码。第三周，"要不加个数据看板？方便用户理解"。第四周，"竞争对手有API，我们也得有"。第六周，"注册流程太简单，做个多步骤引导吧"。

每个决策单独看都合理。但三个月后，产品变成一团功能 spaghetti（意大利面条，指混乱纠缠的代码结构）。更隐蔽的伤害是：你失去了对话能力——不是跟投资人，是跟真实用户。

Basecamp（美国项目管理软件公司）创始人Jason Fried说过一句刻薄但准确的话：「用户不会因为你功能多而爱你，他们只会因为你解决了问题而留下。」他的团队做新产品时，第一版永远只解决一个场景，哪怕看起来"简陋"得可笑。

20%法则的残酷数学

这里有个反直觉的计算：假设你计划做20个功能才能"完整上线"。按传统做法，你需要8个月开发，第9个月获取首批用户。但如果只挑4个核心功能（20%），2个月就能见人。

关键差异不在时间，在信息密度。前者在第9个月才知道自己错在哪，后者在第2个月就开始收反馈。多出来的7个月不是"完善产品"，是用真实用户数据迭代了3-4个版本。

Notion（美国笔记协作工具）早期版本连数据库功能都没有，就是个简单的Markdown编辑器。Figma（美国设计协作工具）第一版不支持实时协作，你得手动刷新看同事改了什么。这些"残缺"产品反而拿到了早期 adopters（尝鲜用户），因为核心痛点抓得准。

怎么判断哪20%值得先做

有个粗暴但好用的筛选标准：如果删掉这个功能，用户会不会立刻流失？不是"不爽"，是"直接走"。

Stripe（美国支付平台）创始人Patrick Collison分享过他们的做法：每次加功能前，团队必须写出「不做的代价」——不是"做了的好处"，是"不做会死多少用户"。这个视角转换逼他们砍掉了80%的"应该做"。

更实操的建议来自Lenny Rachitsky（前Airbnb产品负责人，现独立分析师）：「你的MVP（最小可行产品）应该让用户觉得"这玩意儿居然能用"，而不是"这玩意儿真完整"。」前者产生粘性，后者只是好评。

那个被推迟的"真相时刻"

过度开发最隐蔽的成本，是推迟了验证。每多一个月开发，你的假设就多固化一层。团队会开始捍卫自己的劳动成果："都做到这了，上线再说。"但上线后的沉默比开发中的忙碌更致命。

2024年一个被投项目的数据让我印象深刻：他们花了14个月做"完整版"，首月留存3%。砍掉70%功能重做，第二版2个月上线，留存冲到22%。创始人后来复盘：「我们不是在优化产品，是在优化自己的幻觉。」

现在回到你的待办清单。如果明天必须砍掉80%的功能才能上线，哪些会留下？这个假设性暴力，可能是你今年最重要的产品决策。