前10%法则

前提：速度与质量没有 trade-off。 人们把"快"错误地等同于"赶工/马虎"，而应该等同于"能力强（competent）"。任何工艺巅峰的人（大厨、程序员、国际象棋大师）都可以用速度反推产出质量——顶级棋手让时间还能赢。软件质量的很大成分就是"你做了多少轮迭代"，而多迭代的唯一途径就是快。（Patrick Collison 同款观点："good, cheap, fast 选二"是慢家伙散布的错误信息，慢和贵通常一起出现。）

操作规则：时间预算过去 10% 时，必须有能跑的东西。 如果一个 feature 预计做一个月，第一周结束就要有一个可交互的版本，验证某个关键内部假设——而不是到一半才有"候选方案"。到 80% 才发现假设错了就只能推迟 deadline。

心态设定：第一版明确不追求好。 它只是"朝最终方向的最佳猜测"：不需要 pixel perfect、不需要修 UI 小 bug，只需要能跑、能感受"是否解决了核心问题"。因为没人被要求完美主义，成本大幅降低。团队还要有"不被每个设计小决策卡住"的工程师。

发布机制：逐层扩大的用户圈。 内部 dogfooding（Linear 每天用 Linear）→ 达到"不损坏数据、不太难看"后进 early access 客户群 → 多层 beta 群 → GA。中途信号：如果 beta 用户没人用，说明没打中，直接回炉。

推论：几乎不做工期估算。 Linear 靠"尽早 ship"而不是靠估点数来命中日期——10% 时间点的可用版本让你把剩余时间花在"再迭代一轮还是打磨上线"的选择上。

配套实践： 开工前维护一个 20-30 个机会点的 backlog，每个附带持续更新的书面分析（避免 PM 的用户心智模型只能"心灵感应"传递）；对每个机会先决定"该咬下问题的多大一块"——咬太大会 overpromise。