shipping-products

发布产品

运用 47 位产品领导者的框架和见解，帮助用户有效地发布产品。

如何提供帮助

当用户请求有关发布的帮助时：

1. 了解阻碍因素——询问是什么阻碍了发布：范围、质量顾虑、依赖项还是组织摩擦
2. 评估背景——判断这是新产品、功能迭代还是基础设施变更
3. 挑战时间安排——运用“最大限度加速”原则，找出关键路径
4. 引导质量取舍——帮助用户根据产品类型，在速度和适当的质量标准之间取得平衡

核心原则

速度是能力的体现

Nan Yu：“看看那些技艺登峰造极的人，你会发现，他们的产出水平如何，往往从他们的速度就能看出来。”高速度与高质量并存，代表精通，而非草率。利用速度增加迭代次数，并测试更多方案。

发布以获取反馈

Dylan Field：“尽可能快地把它发布出去。发布得越快，获得的反馈就越多。”优先提升发布速度，以加快反馈循环；在产品开发早期，反馈循环是最宝贵的资产。

速度和稳定性相辅相成

Nicole Forsgren：“行动越快，稳定性越高。你会更频繁地推送更小的变更，影响范围也更小。”更频繁地推送小变更，以降低复杂性，让故障更易排查。

99% 完成就是 0% 完成

Dmitry Zlokazov：“如果一件事完成了 99%，那它离 0% 比离 100% 更近。”产品只有完全完成并发布后，才能为客户创造价值。在发布完成前，始终保持专注。

问问自己为什么不能明天发布

Nick Turley：“为什么我们不能现在就做？如果这是最重要的事，而且你真的想尽可能加快进度，你会怎么做？”用这个问题剔除非必要的阻碍，并找出关键路径。

使用质量检查清单

Matt MacInnis：“我们有一份产品质量清单，明确了发布时应达到的标准。”创建产品质量清单，列出发布前必须满足的质量标准；如果有漏洞漏网，就对清单进行迭代。

先发布以学习，再打磨

Nick Turley：“发布之后，你才会知道该打磨什么。”对于 AI 这类不断演进的产品，应尽早发布，根据真实使用情况找出真正需要打磨的地方。

节奏比组织架构更重要

Patrick Campbell：“你的节奏框架比组织架构更重要。如果一个团队总是在规划，却从不发布，说明你们没有就怎样才算良好的节奏达成共识。”为每个部门明确发布频率的预期。

完美执行才能验证战略

Naomi Gleit：“只有完美执行，我们才能重新评估战略究竟对错。”执行不佳会让失败原因变得模糊。认真发布，才能了解战略是否正确。

持续的小幅进步会产生复利效应

Keith Yandell：“如果你持续把发布提前一周，最终就会赶超竞争对手，因为你能早一周开始下一件事。”速度的小幅提升会通过复利效应带来巨大的竞争优势。

帮助用户思考的问题

• “要明天发布，需要做些什么——实际阻碍你们的是什么？”
• “这是一个可靠性至关重要的关键任务产品，还是可以先发布粗略版本再迭代？”
• “最小可行版本是什么，能让你从真实用户那里学到东西？”
• “谁是唯一有权做出最终取舍决策的人？”
• “必须达到什么质量标准，哪些方面可以在发布后再打磨？”
• “你们最近一次拥有可运行、可测试的产品版本是什么时候？”

常见错误

• 发布前过度打磨 - 看不到真实的使用模式，就无法知道哪些地方需要打磨
• 等待像素级完美的设计 - 早期版本不需要像素级完美；需要的是可供交互的可用软件
• 功能标志泛滥 - 过多的功能标志会带来技术债务，并在发布期间造成隐蔽的故障点
• 没有唯一的决策者 - 连贯的产品设计需要一位拥有最终决策权的人来权衡取舍
• 把忙碌误当成发布成果 - 如果没有足够的速度真正发布，高质量的构思和文档也毫无用处

深入了解

47 位嘉宾分享的全部 55 条见解，请参阅 references/guest-insights.md

相关技能

• 撰写 PRD
• 利益相关者协同
• 设定 OKR 和目标
• 可用性测试