最重要的产品决策，是决定不做什么
文章摘要
作者 Liam Nugent 以一句扎心的观察开场：问一支团队今年交付了什么，你会得到一长串清单；问他们今年砍掉了什么，全场立刻安静。他从自己在面向消费者的金融科技 App 的从业经历出发，点名了两个他每次都拼命想拦下来的功能——「文档中心」和「通知中心」。
这两个东西的共同点在于，它们表面上都在解决一个真实存在的问题，实际上却是组织把自己的麻烦转嫁给了用户。以文档中心为例：业务侧的遗留系统会生成大量 PDF（对账单、通知函，因为这些东西最早是靠邮政寄出的），合规部门还会搬出「持久化沟通渠道」的要求，于是 App 里总得有个地方放这些文件。最省事的方案就是做一个文件列表。听起来很简单。但接下来，每一个利益相关方都会像电视剧里的神探哥伦布那样，在走到门口时回头再加一条「还有一件小事」。等做完，你实际上已经重建了一个 Google Drive：打标签、归档、打印、跨多渠道分享，每条渠道各有各的怪脾气，外加一整套「确保只有对的人能看到对的文件」的鉴权与安全体系。
而这些还只是「把东西建出来」的成本。作者强调，真正压垮人的是之后年复一年的维护开销——每一轮 iOS 发布周期到来时，你赖以支撑某个功能的某个系统小特性，可能就被 Apple（或 Google、微软、亚马逊）单方面砍掉了。通知中心也是同一个剧本的另一个开场白：某位利益相关方问「能不能就在右上角放个带小红点的铃铛图标」，几个月后你在做一个糟糕版本的 Gmail。作者甚至见过通知中心真被做了出来，结果原本那条消息想传达的意图，反而没法通过这个为它而建的载体表达。
他给出的实操经验是：说服别人放弃脑中已成形的心智模型很难，尤其当用户焦点小组还部分印证了这个想法时。真正管用的手段不是摆建设成本，而是把未来数年的运行成本摊开来算给人看，这通常能把人从悬崖边拉回来。但砍掉平台不等于原问题消失，正确的做法是回到每个用例本身逐一评估：到底有什么非说不可、什么时候说，然后毫不留情地追问「这真的需要先建一整个平台吗」。他反复用的检验标准是「这能让船开得更快吗」。绝大多数情况下，答案是用一个简单的、或者已经存在的东西，哪怕它并不完美。
文章后半段讨论了为什么「删」比「不加」更难。作者引用 Gerry McGovern 的观点：我们的文化奖励生产东西的人，审查、维护、移除都被视为次等工作，所以没有人因为删东西而升职。McGovern 的 Top Tasks 研究发现，砍掉网站约 80% 到 90% 的内容后，企业反而卖得更多、客服电话更少、用户找东西更快——移除本身就是改进，而不是改进之后的收尾。更深一层，作者引用 Klotz 等人发表在《自然》上的研究：八组实验表明，即使删减明显是更优解，人们仍会系统性地忽略「做减法」这个选项，因为加法的点子来得又快又便宜，减法则需要真实的认知成本。
对于「AI 时代建东西几乎免费了，所以这套论调过时了吗」，作者的回应是：那恰恰是误读。更聪明的做法是用 agent 去做修剪、做维护、做那些人手工很难细致完成的清理。他还引用 Stewart Brand 的说法——维护既绝对必要又完全可选，作者补了一句「可选，直到它变成必需为止」。结尾照例请出了 1997 年乔布斯那个四象限矩阵：两款消费级、两款专业级，每格一款明星产品，其余全部砍掉，把工程人才汇聚起来而非摊薄。作者提醒，苹果今天有五十多条产品线，所以终局从来不是只卖四样东西，重点是让组织专注在最重要的事情上。文末他自嘲：「我本想写得短一点，可惜实在想不出该删掉哪段。」
HN 评论精华
这条讨论有 145 分、51 条评论，大量从业者在评论区认领自己的「文档中心」。
「自定义报表」是最常被提名的功能黑洞。 swader999 说他最常收到的需求就是「我们要自定义报表」，而他的对策是反复追问「为什么」，然后先去做一个他们真正会用的功能，把这个需求一个月一个月地推后。pelagicAustral 补刀说，绝大多数提这个需求的人对自己想要什么报表、数据长什么样毫无概念，实际含义往往是「把所有有外键的表都 join 起来，没外键的就随便挑个字段强行 union，最后全部倒进一张 Excel 里」——这就是行业金标准。
tytho 提供了更建设性的视角：他共事过的一位专做报表管线的同事认为，用户要自定义报表，多半是因为产品内建的排序、筛选、聚合能力回答不了他们的问题。所以他现在的第一句话永远是「你到底想知道哪个问题的答案？」——这通常会导向一个新功能，或者只是指出答案其实早就在某个地方。Terr_ 顺着展开：报表和监控有时是绕开正常产品与工程流程的后门。比如有人要求某字段被编辑时打特殊日志，你追下去才发现他的真实目标是客服打电话来说「糟糕出错了」时，能把旧值复制粘贴回去——于是报表工具成了客服流程的一部分。真正该做的其实是一张「设置变更事件」表，或者把这个字段从单一可变值升级为「版本」概念。gedy 讲了一个更惨的版本：他入职后第一个项目是「改进报表」，花几个月做各种查询与排序的性能调优，最后才发现产品经理搞错了需求——用户只是想在几百行里看到某一个数字，并希望它能排到最上面。他指出「其实在首页加个数字几分钟就搞定」之后，团队并不高兴。
关于「为什么没人肯删」，最扎心的回复来自 bunderbunder。 他说自己在上一个产品上线前，就那些连早期客户都不喜欢的花哨功能提出了长期维护成本的担忧，结果产品负责人当场卸下伪装直说：那不是他的问题；已经做出原型的功能如果砍掉，他要被追问；而且产品一上线他就会调去新项目，维护负担会落到某个更资浅的 PM 头上。在另一条线里他还指出，房地产开发商建了后来荒废的小镇设施，也未必是算错账，而是激励错位——开发商和当时的镇政府官员都不为长期维护成本负责，等账单到期他们早就换岗了；科技行业人员流动同样制造了这种「长期思维的道德风险」。
也有人提出反面意见。 bob1029 坦言自己经常判断不出什么不该建，退而求其次的做法是「飞快地把最糙的、勉强能用的东西做出来」，故意做得差一点反而有帮助，关键是别掉进 clean code 和测试覆盖率的意识形态陷阱里；他发现时间约束越激进，越不容易做出毁掉整盘棋的工程决策，他曾用这种方式把好几个月的产品路线图压缩成一天的任务——通过快速试错去发现什么不该做。_the_inflator 则认为「不做」被讲得太酷太叛逆了，真正的决策者应该是整体产品战略，而且向后兼容才是最容易扼杀产品的摩擦源。jillesvangurp 提出一个实用的三分法：增值功能、不增值但必须有的通用功能、以及做砸了的通用功能（负价值）。他举登录注册为例——有人非要在这上面创新结果制造出多余的引导摩擦，有人干脆照抄别人所以到 2026 年还在用邮箱加密码，两者都在给产品减分。
最引发共鸣的提问来自 ungreased0675，一位产品经理：他还没找到彻底杀死一个功能点子的办法。某个工程师甚至 CEO 灵光一现，想加一个根本不属于这个产品的东西；他可以说不，也可以解释原因，但这个点子会一直回来——头脑风暴时它回来，销售电话里它被抛给潜在客户，他休两周假回来它已经进了 sprint。他问其他产品负责人：怎么才能客气地说出「不，我们永远不会做这个」？