最重要的产品决策：不做什么
The most important product decision is what you don't build
问团队今年上线了什么，你会得到一长串清单；问砍掉了什么，房间却会陷入死寂。在做面向消费者的金融服务 App 时，我坚决拒绝了“文档中心”和“通知中心”这两个看似标准实则累赘的功能。它们往往让组织逃避责任，却给用户留下烂摊子。从重建 Google Drive 般的文档系统到开发糟糕的 Gmail 克隆版，这些功能不仅开发成本高，维护更是无底洞。真正的解决方案不是堆砌功能，而是展示长期运行成本，针对每个具体用例做严谨判断。正如 Steve Jobs 当年的矩阵决策所示，成功往往源于聚焦核心，而非盲目扩张。在如今构建成本极低的时代，利用 AI 代理进行修剪和维护，比无休止地执行新想法更为明智。
那些创造和发布产品的人受到奖赏和推崇，因为我们的文化奖励的是产出，而非其他一切。
HN 评论区
39- bob1029
我有时很难搞清楚到底不该做什么。
次优的选择是快速造出一个勉强能用的烂东西。故意做得稍微差一点通常很有帮助。陷入干净代码和测试覆盖率的意识形态地狱，恰恰是我们想要避免的。
我发现，你设定的时间约束越激进，就越不太可能把自己套进某种毁掉整个项目的工程决策里。
如果那个 90 分钟的快速原型行不通，你也没浪费多少时间。用这种方式向利益相关者证明观点也更容易。
我曾通过将正确的事情在正确的时间做出来（以发现不该做什么），把原本需要数月的产品路线图扩展包压缩成了单日任务。
- alentred
我去过不少小镇，这些地方大概是在 60 年代积极建设起来的，经常能看到被遗弃的宏大甚至浮夸的项目——比如这里的公园，那里的社区中心——全都建好了，如今却彻底荒废，往往已成废墟。
每次看到这些，我也看到了教训：算算你的维护成本。这是一条漂亮的人工水渠，没错，但城市会有钱去运营它、清理它、供水吗？
我当然知道最初的（房地产）开发商做过成本分析，但当你看到这些被遗弃的地方时，你完全可以客观地得出结论：他们算错了。要么是计算失误，要么是判断错误。
--
回到软件领域，我认为范围蔓延（scope creep）引发了许多问题：团队失去焦点，因为交付没人需要的功能而士气低落等等——这些都是真实且严重的问题。但最终，不断增长的维护成本才具有真正摧毁团队全部产能的能力。
无论我们构建的东西质量多高，都需要维护，所有项目都应将这部分成本纳入其“运行”阶段的预算。而且，不断增长的维护成本只会加剧其他范围蔓延的问题。
--
这也是身为工程师、工程经理甚至 CTO 的悲剧所在。正如帖子所说，你并不会因为“拒绝做某事”而获得“晋升”。我有无数次成功说服产品团队和董事会放弃或缩减项目的经历，虽然我相信这确实带来了好处，但……
- mmonaghan
我经常看到表达这种观点的帖子，对此我心情复杂：
- 如今，LLM 让我们能相当快地构建出我们想要的东西，或者至少是一个原型；
- 而这种快速构建这些功能（或独立产品）的能力，恰恰是个陷阱。
> “这是我挑选待解决问题时一直采用的测试标准：它能让船跑得更快吗？”
但谁知道这个答案呢？工程师通常不知道。产品团队在自己的领域内通常有很好的判断力。在好公司里，领导层通常（大体上）是步调一致的，尽管具体取决于发言者，细节上会有些微差异。
这是一种很好的理念，但很少是某一个人的决定。
如我所说，我看到这些帖子出现时，通常会感到恼火，因为在这个阶段还能有什么新见解呢？但我每次都还是会读一遍 :p
- daitangio
我补充一点，从顾问的角度来看，何时对客户说“不”。
当你被各种需求淹没时，预测正确的优先级并管理甘特图至关重要。
客户满意度是顾问的优先事项，但如果你能运用智慧，那它的价值甚至更高。
- stevoski
我书中有一章介绍了一家公司的做法，他们用“加一个按钮；删一个按钮”的信条来应对这个问题。
在添加任何新的 UI 元素之前，他们先寻找可以删除的东西。