《存在的约束》 很多人做产品，喜欢问一个问题： 还能加什么功能？ 但真正的问题其实是： 什么功能，能够一直留下来？ 因为一个功能是否存在，从来不是由开发者决定的，而是由现实决定的。 时间，会替所有人完成筛选。 一个按钮，如果没人点，它终究会被删掉。 一个模块，如果没人依赖，它迟早会被重构。 一家公司里的一个岗位，如果始终没有创造价值，总有一天会被裁撤。 一种商业模式，如果不能持续解决问题，再多融资也只是延缓死亡。 存在，本身就是一种筛选后的结果。 ⸻ 很多开发者误以为，自己是在创造价值。 实际上，他们只是在提出一个假设： 我认为这个东西值得存在。 真正验证这个假设的，从来不是产品经理，也不是老板，更不是自己。 而是真实世界。 有没有人每天使用？ 有没有人愿意付费？ 有没有人离不开它？ 这些反馈，才决定了它是否能够继续存在。 ⸻ 自然界一直遵循着同样的规律。 一个物种能够繁衍，不代表它最完美。 但说明它适应了当前环境。 一个制度能够长期运行，不代表它最先进。 但说明它能够维持当前系统。 一种思想能够跨越几十年甚至几百年流传，不代表它没有缺陷。 但说明它持续解决着某种真实的问题。 能够留下来的东西，一定承受住了时间施加的约束。 ⸻ 真正的约束，从来不是代码能不能写出来。 而是现实是否需要它。 很多花里胡哨的功能，发布当天掌声雷动。 几个月后，使用率接近零。 真正每天被点击、被调用、被依赖的，往往只是几个最普通的功能。 因为用户不会为设计师的想象力买单。 用户只会为自己的痛点买单。 ⸻ 这也是为什么，任何系统最终都会不断收敛。 能够留下来的，不一定最复杂。 反而往往最简单。 简单，并不是因为设计者能力不足。 而是因为所有多余的部分，都已经被现实淘汰掉了。 复杂容易设计。 保留下来，很难。 ⸻ 所以，一个系统最重要的问题，不是： 还能增加什么？ 而是： 如果一年以后只能留下三个功能，它们会是什么？ 如果回答不了这个问题，就说明你还没有找到系统真正的价值。 因为真正的结构，不是在设计图里诞生的。 真正的结构，是经过真实世界反复筛选之后，依然无法被删除的那一部分。 时间不会创造价值。 时间只会不断删除虚假的价值。 而那些最终依然存在的，就是现实给予它们的答案。