做工具产品的人，大概都经历过这个阶段：功能清单越来越长，用户却没有变多。
我参与过一个内部工具，从最初的三项功能，半年内长到十七项。每次评审都有人提“能不能再加一个”，每次我们都觉得有道理。年底做使用统计，日活最高的是最早那三项。
功能是承诺，不是资产
每加一个功能，团队就欠下五笔债：开发、测试、文档、客服、后续迁移。上线只是开始，真正的成本在它被使用之后。
功能不是资产，是被承诺出去的责任。
这句话听起来有点绝对，但它解释了一个常见现象：产品越做越重，团队越做越累，用户却没有更满意。因为用户要的从来不是“什么都能做”，而是“我要做的那件事很顺”。
我做过的那个工具里，有一个导出功能，支持七种格式。实际统计下来，九成以上的导出用的是其中一种。剩下六种格式，每个季度都有人提一次需求，但没人真的用过。它们占掉的开发和测试时间，比那一项主功能还多。
少为什么能变成优势
我观察到三个具体的好处。
第一是决策快。选项少的时候，团队讨论的是“怎么做更好”；选项多的时候，讨论会变成“要不要做”，而后者通常没有结论。
第二是体验一致。功能之间会互相牵扯，每多一个入口，就多一种状态组合。少功能的系统，边界是清楚的。
第三是迁移成本低。用户敢用，是因为知道它不会突然变复杂。这一点在工具类产品里被严重低估。
还有一点不太被提到：功能少，意味着每个功能都能做得更深。资源是有限的，分散在十七个功能上的注意力，和集中在三个功能上的注意力，产出完全不是一个量级。
怎么判断该不该砍
我现在的判断标准有三条：
- 一个月内没人主动用过
- 只在演示和汇报时被打开
- 需要写一份文档教人怎么用
三条里中两条，我就会提议砍掉。砍之前会先看一段时间的访问日志，确认不是某个人每周用一次、但没留下数据。
但也要区分克制和偷懒。真正的克制，是你能说清楚拒绝了谁、为什么拒绝；偷懒是没做完，然后用“克制”来解释。这两者从外部看很像，从内部看完全不同。
留下的东西
那个内部工具最后砍到九项功能。砍完的第一个月，支持请求少了一半。不是因为功能变好了，是因为能出错的地方变少了。
砍功能时最难的不是技术，是面对提出需求的人。我现在的做法是：先问清楚他要解决的场景，再看现有功能能不能覆盖。很多时候答案是“不能完全覆盖，但能解决八成”。剩下那两成，通常没有他一开始以为的那么重要。
护城河不是功能少，是敢于一直少下去。因为每多一个用户，就会多一个“能不能加个功能”的请求，而你需要有能力一直说不。