有了 AI 编程工具，“这个功能能不能做”越来越容易得到肯定回答。一个按钮、一种导出格式、一套简单流程，看起来都不必耗费太久。
但功能写完的那一刻，往往也是另一段工作的开始。
以后数据格式变了，它要跟着改；用户不会用，要有人解释；原来支持的平台调整规则，它可能突然出错。增加功能的成本，远远不只第一次开发所花的时间。
产品设计里有一个不太好懂的词：“反功能”。放在这里，可以直接理解为明确选择暂时不做什么。它表达的是服务范围，而不是故意把产品做差。
Basecamp 在《Start With No》里提出，不必立刻接受每个新功能请求，功能上线之后也会带来持续责任。资料来源：Basecamp
设想一款专门整理用户访谈的工具。有客户提出，能不能顺便加入排班、工资结算和审批？技术上可能都能实现，对方也愿意付定制费。可一旦答应，产品就要同时处理另一整套业务。那笔收入背后，还跟着后续支持与维护。
有时，客户提出的功能也未必是他真正需要的完整方案。他想要“审批系统”，可能只是希望负责人能看一眼摘要并作出确认。一个清楚的分享页面，也许就能完成这件事。未经理解就满足字面要求，容易把简单问题做成复杂产品。
当然，拒绝也不是一种值得炫耀的姿态。如果目标客户反复被同一个缺口卡住，原先的选择就有必要重新讨论。暂时不做，应当保留接受新信息的余地。
我看这类取舍，更在意产品能否长期照顾好已经作出的承诺。一个长期没人用的功能，不会因为页面上的位置很小，就停止占用开发者的注意力。
对个人经营者尤其如此。白天答应的每一个“顺手加上”，都可能成为几个月后某个晚上必须处理的消息。产品的大小，有时就是由这些消息决定的。