shipping-products

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Shipping Products

产品发布交付

Scope

适用范围

Covers

Turning “we need to ship” into a concrete release plan with owners, dates, and a rollout strategy
Building a Shipping & Launch Pack that makes the release decision-ready (Go/No-go)
Shipping in small, frequent increments to improve both speed and stability
Defining a reusable Product Quality List (PQL) and iterating it based on escapes
Planning measurement, monitoring, rollback, and post-launch learning

When to use

“We’re launching / releasing / deploying / going live—make a plan and ship.”
“Create a go/no-go checklist and rollout plan for this release.”
“We need to ship faster without breaking trust—set up small-batch shipping.”
“Write release notes + comms + enablement for an upcoming launch.”

When NOT to use

You don’t yet agree on the problem or target user (use
```
problem-definition
```
)
You need to right-size scope to hit a date/appetite (use
```
scoping-cutting
```
)
You need a decision-ready PRD (use
```
writing-prds
```
) or build-ready spec/design doc (use
```
writing-specs-designs
```
)
You’re setting long-term strategy/vision (use
```
defining-product-vision
```
) or choosing among initiatives (use
```
prioritizing-roadmap
```
)

涵盖

把“我们需要交付产品”转化为明确的发布计划，包含负责人、时间节点和上线策略
构建一份上线交付包，让发布具备决策条件（上线/不上线）
采用小批量、高频次的交付方式，提升速度与稳定性
定义可复用的产品质量清单（PQL），并根据问题反馈迭代优化
规划度量、监控、回滚以及发布后学习复盘

适用场景

“我们要发布/上线/部署产品——制定计划并执行交付。”
“为本次发布创建上线/不上线检查清单和上线计划。”
“我们需要在不损害用户信任的前提下加快交付速度——建立小批量交付机制。”
“为即将到来的发布撰写发布说明、沟通方案与赋能材料。”

不适用场景

尚未就问题或目标用户达成共识（请使用
```
problem-definition
```
）
需要调整范围以满足时间/资源限制（请使用
```
scoping-cutting
```
）
需要一份可用于决策的PRD（请使用
```
writing-prds
```
）或可用于开发的规格/设计文档（请使用
```
writing-specs-designs
```
）
正在制定长期战略/愿景（请使用
```
defining-product-vision
```
）或在多个举措中做选择（请使用
```
prioritizing-roadmap
```
）

Inputs

输入信息

Minimum required

What you’re shipping (feature/change), target users, and where it will be available (platforms, regions, plans)
Desired ship date/timebox + constraints (compliance, privacy, brand, uptime windows)
Success metric(s) + guardrails (trust/safety, performance, reliability, support load)
Rollout context (flags? staged rollout? beta? migration?) + key dependencies
Stakeholders + DRI (who decides go/no-go) + who is on point during the launch

Missing-info strategy

Ask up to 5 questions from references/INTAKE.md.
If answers aren’t available, proceed with explicit assumptions and list Open questions that would change the ship decision.

最低要求

待交付的内容（功能/变更）、目标用户、可用范围（平台、区域、套餐）
期望的交付时间/时间范围 + 约束条件（合规、隐私、品牌、可用时间窗口）
成功指标 + 防护指标（信任/安全、性能、可靠性、支持负载）
上线背景（是否使用功能开关？分阶段上线？beta测试？迁移？） + 关键依赖项
相关干系人 + 最终决策人（决定上线/不上线） + Launch期间的负责人

缺失信息处理策略

从references/INTAKE.md中最多提出5个问题。
如果无法获取答案，基于明确的假设推进，并列出会影响交付决策的待解决问题。

Outputs (deliverables)

输出成果（交付物）

Produce a Shipping & Launch Pack in Markdown (in-chat; or as files if the user requests):

Release brief (what/why now/who/when; DRI; scope + non-goals)
Rollout plan (phases, eligibility, flags, sequencing, kill switch, rollback)
Quality plan (PQL) (tests/acceptance, “must be true”, known risks, sign-offs)
Measurement + monitoring plan (success metrics, dashboards, alerts, owner)
Comms + enablement plan (internal/external messaging, docs, support readiness)
Launch day runbook (timeline, checkpoints, go/no-go criteria, escalation)
Post-launch review plan (what we’ll learn, retro prompts, follow-ups)
Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md

生成一份Markdown格式的上线交付包（可在对话中直接输出；若用户要求，可作为文件输出）：

发布简报（内容是什么/为什么现在发布/面向谁/时间；负责人；范围与非目标）
上线计划（阶段、准入条件、功能开关、顺序、紧急关停开关、回滚方案）
质量计划（PQL）（测试/验收标准、“必须满足”的条件、已知风险、签字确认）
度量与监控计划（成功指标、仪表盘、告警规则、负责人）
沟通与赋能计划（内外部沟通内容、文档更新、支持团队准备工作）
Launch当日执行手册（时间线、检查点、上线/不上线标准、升级流程）
发布后复盘计划（复盘内容、回顾问题、后续行动）
风险 / 待解决问题 / 下一步行动（必须包含）

模板：references/TEMPLATES.md
扩展指南：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8步）

1) Intake + define “what does shipped mean?”

1) 信息收集 + 明确“交付完成的定义”

Inputs: User request; references/INTAKE.md.
Actions: Clarify the change, target users, ship date, DRI, constraints, and what “live” means (where/for whom).
Outputs: Release brief (draft).
Checks: You can state the release in one sentence: “We will ship <what> to <who> by <when> via <rollout>.”

输入：用户需求；references/INTAKE.md。
行动：明确变更内容、目标用户、交付时间、负责人、约束条件，以及“上线”的定义（覆盖范围/用户群体）。
输出：发布简报（草稿）。
检查：可以用一句话概括发布内容：“我们将在<时间>通过<上线方式>向<目标用户>交付<内容>。”

2) Choose the ship strategy (small batches by default)

2) 选择交付策略（默认采用小批量）

Inputs: Release brief; constraints; dependency map.
Actions: Decide: internal → beta → GA (or phased rollout), flag strategy, and how to keep changes small. Identify the smallest safe increments.
Outputs: Rollout plan (draft) + incremental release slices.
Checks: Each increment has a clear user-visible outcome and a rollback path.

输入：发布简报；约束条件；依赖关系图。
行动：确定流程：内部测试 → beta测试 → 正式发布（或分阶段上线）、功能开关策略，以及如何保持变更的小规模。确定最小安全交付单元。
输出：上线计划（草稿） + 分阶段交付切片。
检查：每个交付单元都有明确的用户可见成果和回滚路径。

3) Run the “maximally accelerated” forcing function

3) 执行“最大化加速”强制分析

Inputs: Rollout plan (draft); slice list; blockers.
Actions: Ask: “If we had to ship tomorrow, what would we do?” Use this to identify critical path vs non-essential work. Convert into a realistic plan.
Outputs: Critical path list + cut/defer list + open questions.
Checks: Every blocker is categorized: remove, work around, accept risk, or change scope.

输入：上线计划（草稿）；交付切片列表；障碍。
行动：提问：“如果我们必须明天交付，我们会怎么做？”以此识别关键路径与非必要工作，转化为可行计划。
输出：关键路径列表 + 削减/延期列表 + 待解决问题。
检查：每个障碍都被分类：移除、workaround、接受风险，或调整范围。

4) Define the Product Quality List (PQL) + acceptance bar

4) 定义产品质量清单（PQL） + 验收标准

Inputs: Known risks; guardrails; product surface area.
Actions: Create/extend a PQL (tests, UX states, security/privacy, reliability, performance). Explicitly list “must be true” to ship.
Outputs: Quality plan (PQL) + go/no-go criteria (draft).
Checks: PQL items are measurable/verifiable, not vibes; owners are assigned.

输入：已知风险；防护指标；产品覆盖范围。
行动：创建/扩展PQL（测试、UX状态、安全/隐私、可靠性、性能）。明确列出交付必须满足的条件。
输出：质量计划（PQL） + 上线/不上线标准（草稿）。
检查：PQL项可度量/验证，而非主观感受；已分配负责人。

5) Measurement, monitoring, rollback

5) 度量、监控、回滚

Inputs: Success metrics/guardrails; rollout plan.
Actions: Define dashboards/queries, alert thresholds, and on-call/escalation. Write the rollback and “stop-the-line” triggers.
Outputs: Monitoring plan + rollback plan + launch runbook skeleton.
Checks: If the metric moves the wrong way, you know who acts, how fast, and what they do.

输入：成功指标/防护指标；上线计划。
行动：定义仪表盘/查询规则、告警阈值，以及值班/升级流程。撰写回滚和“紧急叫停”触发条件。
输出：监控计划 + 回滚计划 + Launch执行手册框架。
检查：当指标出现异常时，明确知道谁来行动、行动速度以及具体操作。

6) Comms + enablement (internal first)

6) 沟通与赋能（先内部后外部）

Inputs: Release brief; target audiences; launch tier (minor/major).
Actions: Draft internal announcement, release notes, help docs updates, sales/support enablement, and external messaging (if any).
Outputs: Comms + enablement plan.
Checks: Every audience has: what changed, why it matters, what to do next, where to get help.

输入：发布简报；目标受众；发布等级（次要/主要）。
行动：草拟内部公告、发布说明、帮助文档更新、销售/支持团队赋能材料，以及外部沟通内容（如有）。
输出：沟通与赋能计划。
检查：每个受众都清楚：变更内容、重要性、下一步行动、获取帮助的渠道。

7) Go/No-go + launch execution

7) 上线/不上线决策 + Launch执行

Inputs: Full pack draft; PQL; checklists.
Actions: Run a go/no-go review, finalize the runbook timeline, confirm roles, and ensure dependencies are ready.
Outputs: Final Shipping & Launch Pack (ready to execute).
Checks: references/CHECKLISTS.md passes with no open “stop-ship” items.

输入：完整的交付包草稿；PQL；检查清单。
行动：召开上线/不上线评审会，最终确定执行手册时间线，确认角色，确保依赖项已准备就绪。
输出：最终的上线交付包（可执行）。
检查：通过references/CHECKLISTS.md检查，无未解决的“停止交付”项。

8) Post-launch review + iterate the system

8) 发布后复盘 + 迭代流程

Inputs: Launch outcomes; incident notes; feedback.
Actions: Run a short retro, capture learnings, update the PQL based on escapes, and define next iteration(s).
Outputs: Post-launch review notes + PQL updates + next steps.
Checks: At least 1 process improvement is identified and owners/dates are assigned.

输入：Launch结果；事件记录；反馈。
行动：召开简短的回顾会，记录学习成果，根据问题反馈更新PQL，定义下一次迭代内容。
输出：发布后复盘笔记 + PQL更新内容 + 下一步行动。
检查：至少确定1项流程改进措施，并分配负责人和时间节点。

Quality gate (required)

质量门（必填）

Use references/CHECKLISTS.md and references/RUBRIC.md.
Always include: Risks, Open questions, Next steps.

使用references/CHECKLISTS.md和references/RUBRIC.md。
必须包含：风险、待解决问题、下一步行动。

Examples

示例

Example 1 (B2B SaaS release): “We’re launching role-based access control for admins next month. Create a Shipping & Launch Pack with a staged rollout, go/no-go criteria, and support enablement.”
Expected: a phased rollout with clear eligibility, a PQL including permission edge cases, and a launch runbook + comms plan.

Example 2 (Consumer app iteration): “Ship ‘saved searches’ to 10% of users behind a flag next week; define monitoring and rollback triggers.”
Expected: a small-batch rollout plan, dashboards/alerts tied to guardrails, and explicit stop-the-line thresholds.

Boundary example: “Decide what we should build this quarter.”
Response: use

prioritizing-roadmap

(and/or

defining-product-vision

) first; then apply this skill to the chosen initiative’s release.

示例1（B2B SaaS发布）： “我们将于下月为管理员推出基于角色的访问控制。创建一份包含分阶段上线、上线/不上线标准和支持团队赋能材料的上线交付包。”
预期输出：分阶段上线计划（明确准入条件）、包含权限边界案例的PQL、Launch执行手册 + 沟通计划。

示例2（消费类应用迭代）： “下周向10%的用户通过功能开关交付‘保存搜索’功能；定义监控和回滚触发条件。”
预期输出：小批量上线计划、与防护指标关联的仪表盘/告警、明确的紧急叫停阈值。

边界示例： “决定我们本季度应该构建什么。”
回应：先使用

prioritizing-roadmap

（和/或

defining-product-vision

）；然后将本技能应用于选定举措的发布环节。