shipping-products

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Shipping Products

产品交付

Help the user ship products effectively using frameworks and insights from 47 product leaders.

帮助用户运用来自47位产品负责人的框架和见解，高效交付产品。

How to Help

如何提供帮助

When the user asks for help with shipping:

Understand the blocker - Ask what is preventing the ship: scope, quality concerns, dependencies, or organizational friction
Assess the context - Determine if this is a new product, feature iteration, or infrastructure change
Challenge timelines - Apply the 'maximally accelerated' principle to identify the critical path
Guide quality tradeoffs - Help balance speed with appropriate quality standards for the product type

当用户寻求交付相关帮助时：

明确阻碍因素 - 询问是什么阻碍了交付：范围问题、质量顾虑、依赖项问题，还是组织内的协作摩擦
评估上下文 - 判断这是新产品发布、功能迭代，还是基础设施变更
挑战时间线 - 应用“最大化加速”原则识别关键路径
指导质量权衡 - 根据产品类型，帮助平衡交付速度与相应的质量标准

Core Principles

核心原则

Speed is a signal of competence

速度是能力的体现

Nan Yu: "If you look at people at the pinnacle of their craft, you can tell how good the output is going to be by how fast they're going." High speed combined with quality indicates mastery, not sloppiness. Use speed to increase iterations and variations tested.

Nan Yu: "如果你观察那些技艺顶尖的人，你可以通过他们的速度判断输出质量的高低。" 高速且高质量的交付代表着专业水准，而非草率。通过提升速度来增加迭代次数和测试的变体数量。

Ship to get feedback

交付以获取反馈

Dylan Field: "Get it out as fast as you possibly can. The faster you get it out, the more feedback you get." Prioritize shipping speed to accelerate the feedback loop, which is the most valuable asset in early product development.

Dylan Field: "尽可能快地推出产品。推出得越快，获得的反馈就越多。" 优先保证交付速度以加速反馈循环，这在产品早期开发阶段是最宝贵的资产。

Speed and stability move together

速度与稳定性相辅相成

Nicole Forsgren: "When you move faster, you are more stable. You're pushing smaller changes more often with a smaller blast radius." Push smaller changes more frequently to reduce complexity and make failures easier to debug.

Nicole Forsgren: "当你交付速度更快时，系统会更稳定。你会更频繁地推送更小的变更，影响范围也更小。" 更频繁地推送小型变更，以降低复杂度，让故障更容易调试。

99% done is 0% done

99%完成等于0%完成

Dmitry Zlokazov: "If something is 99% done, it's closer to 0% rather than 100%." A product provides zero customer value until fully finished and launched. Maintain relentless focus until shipping is complete.

Dmitry Zlokazov: "如果某件事完成了99%，那它更接近0%而非100%。" 产品在完全完成并发布前，无法为客户创造任何价值。要持续专注直到交付完成。

Ask why you can't ship tomorrow

问问自己为什么不能明天交付

Nick Turley: "Why can't we do this now? If this was the most important thing and you wanted to truly maximally accelerate it, what would you do?" Use this question to strip away non-essential blockers and identify the critical path.

Nick Turley: "我们为什么现在做不到？如果这是最重要的事情，你想要真正最大化加速它，你会怎么做？" 用这个问题剔除非必要的阻碍，识别关键路径。

Use quality checklists

使用质量检查清单

Matt MacInnis: "We have a Product Quality List that articulates the standards we want you to meet when you ship." Create a PQL checklist of quality standards that must be met before release, and iterate on it when bugs slip through.

Matt MacInnis: "我们有一份产品质量清单（Product Quality List），明确了交付时需要达到的标准。" 创建一份PQL质量标准检查清单，必须在发布前满足这些标准；若有漏洞出现，要对清单进行迭代优化。

Ship to learn, then polish

先交付学习，再优化完善

Nick Turley: "You won't know what to polish until after you ship." In emergent products like AI, ship early to discover which areas actually require polish based on real-world usage.

Nick Turley: "在交付前，你无法知道需要优化哪些部分。" 对于AI这类新兴产品，尽早交付，基于真实用户使用情况发现真正需要优化的领域。

Tempo matters more than org design

交付节奏比组织架构更重要

Patrick Campbell: "Your tempo framework is more important than your org design. If a team is always planning but doesn't ship, you don't have alignment on what good tempo looks like." Define shipping frequency expectations for every department.

Patrick Campbell: "你的交付节奏框架比组织架构更重要。如果团队一直在规划却不交付，说明你们对良好的交付节奏没有达成共识。" 为每个部门明确交付频率的预期。

Perfect execution validates strategy

完美执行验证策略正确性

Naomi Gleit: "Only with perfect execution can we reevaluate whether the strategy is right or wrong." Poor execution leaves the cause of failure ambiguous. Ship properly to learn whether your strategy was correct.

Naomi Gleit: "只有通过完美执行，我们才能重新评估策略的对错。" 糟糕的执行会让失败的原因模糊不清。正确交付才能了解策略是否正确。

Small consistent gains compound

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

Keith Yandell: "If you continuously push up what you ship by a week, you'll end up lapping competitors because you start the next thing a week sooner." Small velocity improvements create massive competitive advantages through compound interest.

Keith Yandell: "如果你能持续将交付时间提前一周，最终会超越竞争对手，因为你能提前一周启动下一个项目。" 微小的速度提升会通过复利效应创造巨大的竞争优势。

Questions to Help Users

用于帮助用户的问题

"What would it take to ship this tomorrow - what's actually blocking you?"
"Is this a mission-critical product where reliability matters, or can you ship raw and iterate?"
"What is the smallest version that would let you learn something from real users?"
"Who is the single person with authority to make the final trade-off decisions?"
"What quality bar must be met, and what can be polished after launch?"
"When did you last have a working, testable version of this product?"

"要在明天交付需要做什么——真正阻碍你的是什么？"
"这是一款可靠性至关重要的核心产品，还是可以先交付初始版本再迭代？"
"能让你从真实用户那里获得有效信息的最小版本是什么样的？"
"谁是拥有最终权衡决策权限的唯一负责人？"
"必须达到哪些质量标准，哪些可以在发布后再优化？"
"你上次拥有可测试的产品工作版本是什么时候？"

Common Mistakes to Flag

需要指出的常见错误

Over-polishing before launch - You can't know what needs polish until you see real usage patterns
Waiting for pixel-perfect designs - Early versions don't need pixel perfection; they need working software you can interact with
Feature flag sprawl - Excessive feature flags create technical debt and hidden failure points during launches
No single decision maker - Coherent product design requires one person with moral authority to make trade-off decisions
Confusing activity with shipping - High-quality ideation and documentation are useless without the velocity to actually release

发布前过度优化 - 在看到真实使用模式前，你无法知道需要优化哪些部分
等待像素级完美的设计 - 早期版本不需要像素级完美，需要的是可交互的可用软件
功能标志滥用 - 过多的功能标志会产生技术债务，并在发布时带来隐藏的故障点
没有单一决策人 - 连贯的产品设计需要一个拥有最终决策权的负责人来进行权衡决策
将活动与交付混淆 - 高质量的构思和文档如果没有实际发布的速度支撑，毫无用处

Deep Dive

深入了解

For all 55 insights from 47 guests, see

references/guest-insights.md

如需获取来自47位嘉宾的全部55条见解，请查看

references/guest-insights.md