功能越加越多，离做完反而越远：创始人最常见的加法误区

早期团队最常见的错觉，不是「不做产品」，而是「一直在做加法」：用户群里有个人说想要个导出功能，加；竞品上了个暗黑模式，抄；投资人随口问了句「能不能做个社区」，排进下个版本。三个月过去，功能列表翻了倍，核心流程的完成率却原地踏步。产品没有更接近「做完」，只是变得更胖了。

数字更能说明问题。我们复盘陪跑过的几十个早期项目，功能使用率几乎是清一色的二八开：20% 的核心功能承担了 80% 的有效使用，排在后半段的长尾功能，月活用户里摸过的人不到 2%——但它们往往吃掉了全部开发量的一半以上，还贡献了大部分 bug 和客服工单。微软早年对 Office 的内部统计也是类似结论：用户稳定使用的只是少数核心命令，于是 2007 版敢于把用了十几年的菜单栏整个推翻，换成围绕核心任务组织的 Ribbon——功能做减法，使用率没掉，可用性测试的得分反而更高。

为什么加法停不下来

• 拒绝一个具体的人很难。功能请求背后是一张真实的脸：付费客户、热心用户、给你投钱的合伙人。拒绝「加一个功能」感觉像拒绝这个人，于是每个请求都变成了排期。
• 加法看起来像进展。本周上线三个小功能，周报很好写；这周在打磨同一个流程的第 4 版，看起来什么都没发生。但前者往往是在原地摊大饼，后者才是在加深护城河。
• 竞品压力是错觉。用户离开你，99% 是因为核心路径没走通，不是因为你少了对手某个边缘功能。盯着竞品的功能清单做产品，等于让对手替你排优先级。

判断该不该加，问三个问题

• 核心路径变快还是变绕？加完之后，新用户第一次成功完成关键操作，是更快了还是更慢了？只看这一个指标，一半的功能请求会自动出局。
• 三个月后删掉它，你心疼吗？不心疼，说明它本来就可有可无；心疼的核心功能，才值得继续投入。
• 有没有更便宜的处理方式？一句人工回复、一个表格模板、一次群里的 @，常常能顶住一个功能的活儿——先用服务扛需求，扛不住了再写代码，这是早期团队最划算的排期策略。

说到底，产品完成度衡量的是「核心路径能不能一次走通、走顺」，不是功能数量。一个 8 个功能但下单流程从不掉链子的产品，比一个 30 个功能但处处半成品的产品，完成度高得多——用户对「半成品感」的嗅觉极其灵敏，一次掉链子，抵消十次小惊喜。

51Kaifa 帮早期项目做 MVP 时，坚持先定「一条核心路径」：上线前所有需求都要过一遍上面三个问题，砍到用户能一次走完为止。经验是：第一版砍得越狠，第二版做加法时底气越足——因为那时你手里已经有真实数据，而不是一堆猜的。