product-delivery
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseProduct Delivery System
产品交付体系
"The goal isn't shipping. The goal is learning whether your bet was right."
This skill covers the Delivery System — how we ship, measure, and learn. It runs discovery and delivery in parallel (dual-track), ships with staged rollouts, measures with a clear hierarchy, reflects through retrospectives, and executes GTM with precision.
Part of: Modern Product Operating Model — a collection of composable product skills.
Related skills: , , , ,
product-strategyproduct-discoveryproduct-architectureai-native-productproduct-leadership"我们的目标不是发布产品,而是验证你的Bet是否正确。"
本技能围绕交付体系展开——即我们如何发布、衡量与学习。它采用探索与交付并行的双轨模式,通过分阶段发布产品、清晰的指标层级进行衡量、复盘总结经验,并精准执行GTM流程。
所属合集: Modern Product Operating Model — 一套可组合的产品技能合集。
相关技能: , , , ,
product-strategyproduct-discoveryproduct-architectureai-native-productproduct-leadershipWhen to Use This Skill
适用场景
Use this skill when:
- Planning how to roll out a new feature or product
- Designing a metrics hierarchy for a bet or product
- Running bet retrospectives after shipping
- Executing GTM launches
- Setting up dual-track development rhythm
- Deciding when to scale, iterate, or kill a bet
Cadence: Continuous | Owner: Product Trio + GTM Team
适用于以下场景:
- 规划新功能或新产品的发布策略
- 为Bet或产品设计指标层级
- 产品发布后开展Bet复盘
- 执行GTM发布
- 搭建双轨开发节奏
- 决定是否扩大投入、迭代优化或终止某个Bet
节奏: 持续进行 | 负责人: 产品三人组 + GTM团队
The Problem This Solves
解决的问题
Most teams either:
- Ship features and never measure impact
- Measure vanity metrics that don't connect to outcomes
- Do "big bang" launches that create risk
- Never officially conclude bets—zombies live forever
- Treat GTM as marketing's problem after PM ships
The Delivery System ensures shipping is the beginning of learning, not the end.
大多数团队存在以下问题之一:
- 发布功能后从不衡量其影响
- 关注虚荣指标(vanity metrics),这些指标与业务成果无关
- 采用“一次性全量发布”,带来极高风险
- 从不正式终结Bet——“僵尸项目”长期存在
- 将GTM视为产品经理发布后的营销问题
交付体系确保发布是学习的开始,而非结束。
Philosophy
核心理念
Core Beliefs
核心信念
- Discovery and delivery run in parallel — Don't pause discovery to deliver
- Staged rollouts are the default — Ship to 10% before 100%
- Metrics exist in hierarchy — Leading → Core → Lagging
- Every bet gets a retrospective — Explicit scale/iterate/kill decision
- GTM is a product responsibility — PM owns adoption, not just availability
- 探索与交付并行 — 不要为了交付而暂停探索
- 分阶段发布为默认策略 — 先向10%用户发布,再逐步扩展到100%
- 指标存在层级关系 — 先行指标 → 核心指标 → 滞后指标
- 每个Bet都要复盘 — 明确做出扩大投入、迭代优化或终止的决策
- GTM是产品团队的责任 — 产品经理不仅要确保产品可用,还要对用户采用率(adoption)负责
What This Framework Rejects
本框架反对的做法
- Ship and forget (no measurement)
- Big bang launches (maximum risk)
- Vanity metrics (activity without outcome)
- Zombie bets (never concluded, never killed)
- Throwing features over the wall to marketing
- 发布后不管不顾(不进行衡量)
- 一次性全量发布(风险最大化)
- 虚荣指标(仅有活动量,无实际成果)
- 僵尸Bet(从不正式终结或终止)
- 将功能甩给营销团队就不管
Framework Components
框架组成部分
1. Dual-Track Development
1. 双轨开发模式
The Core Idea:
Discovery and delivery happen simultaneously. While one bet is being built, the next bet is being shaped.
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6
─────────────────────────────────────────────────────────
[ Discover Bet B ][ Shape Bet B ][ Discover Bet C ]
[ Build Bet A ][ Build Bet B ]
[ Ship A ] [ Ship B ]How It Works:
| Track | Activities | Who |
|---|---|---|
| Discovery Track | Interviews, OST updates, solution exploration, assumption tests | Full trio (PM heavy) |
| Delivery Track | Building, testing, shipping, measuring | Full trio (Eng heavy) |
Time Allocation (Example):
| Role | Discovery | Delivery |
|---|---|---|
| PM | 60% | 40% |
| Designer | 50% | 50% |
| Tech Lead | 30% | 70% |
Coordination Points:
- Weekly sync: What's in flight on each track
- Handoff moment: When a bet moves from "shaped" to "building"
- Learning moment: When shipped bet results inform discovery
0→1 Mode: Tracks may blur. Everyone does everything. Speed > separation.
Scaling Mode: Clear separation. Dedicated discovery time. Research ops support.
核心思想:
探索与交付同时进行。在开发一个Bet的同时,就开始规划下一个Bet。
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6
─────────────────────────────────────────────────────────
[ Discover Bet B ][ Shape Bet B ][ Discover Bet C ]
[ Build Bet A ][ Build Bet B ]
[ Ship A ] [ Ship B ]运作方式:
| 轨道 | 活动内容 | 负责人 |
|---|---|---|
| 探索轨道 | 用户访谈、OST更新、解决方案探索、假设验证 | 完整产品三人组(以产品经理为主) |
| 交付轨道 | 开发、测试、发布、衡量 | 完整产品三人组(以工程师为主) |
时间分配示例:
| 角色 | 探索工作占比 | 交付工作占比 |
|---|---|---|
| 产品经理 | 60% | 40% |
| 设计师 | 50% | 50% |
| 技术负责人 | 30% | 70% |
协同节点:
- 每周同步会:同步各轨道的进展情况
- 交接时刻:当Bet从“规划完成”进入“开发阶段”时
- 学习时刻:已发布Bet的结果为后续探索提供参考
从0到1阶段:轨道边界可能模糊,团队成员身兼数职,速度优先于分工。
规模化阶段:轨道边界清晰,探索工作有专门时间,配备研究运营支持。
2. Staged Rollout
2. 分阶段发布
The Core Idea:
Never ship to everyone at once. Start small, learn, expand.
Default Rollout Stages:
| Stage | Audience | Duration | Purpose |
|---|---|---|---|
| Stage 0: Internal | Team dogfooding | 1-3 days | Find obvious bugs |
| Stage 1: Alpha | 5-10 friendly customers | 1 week | Qualitative feedback |
| Stage 2: Beta | 10% of users | 1-2 weeks | Quantitative signal |
| Stage 3: GA | 100% of users | Ongoing | Full measurement |
Progression Criteria:
| From | To | Criteria |
|---|---|---|
| Internal → Alpha | Ready for external | No P0 bugs, core flow works |
| Alpha → Beta | Validated experience | Positive qualitative feedback, no major usability issues |
| Beta → GA | Metrics acceptable | Leading metrics trending right, no guardrail breaches |
Feature Flags:
- Every significant feature ships behind a flag
- Flags enable instant rollback
- Flags enable % rollout control
- Flags are cleaned up after GA (don't accumulate debt)
Rollback Triggers:
- Guardrail metric breached
- Error rate > threshold
- Customer-reported critical issue
- Leading metrics trending wrong
0→1 Mode: Stages can be compressed. Alpha might be 3 customers for 2 days.
Scaling Mode: Formal stage gates. Release management. Beta programs.
核心思想:
绝不一次性向所有用户发布。从小范围开始,学习验证后再逐步扩展。
默认发布阶段:
| 阶段 | 受众 | 持续时间 | 目标 |
|---|---|---|---|
| Stage 0: 内部测试 | 团队内部试用 | 1-3天 | 发现明显Bug |
| Stage 1: Alpha测试 | 5-10位友好客户 | 1周 | 获取定性反馈 |
| Stage 2: Beta测试 | 10%的用户 | 1-2周 | 获取定量数据信号 |
| Stage 3: 正式发布(GA) | 100%的用户 | 持续进行 | 全面衡量效果 |
阶段推进标准:
| 从 | 到 | 标准 |
|---|---|---|
| 内部测试 → Alpha测试 | 对外可用 | 无P0级Bug,核心流程正常 |
| Alpha测试 → Beta测试 | 体验得到验证 | 定性反馈积极,无重大可用性问题 |
| Beta测试 → 正式发布 | 指标达标 | 先行指标趋势良好,无护栏指标触发 |
功能开关(Feature Flags):
- 所有重要功能都通过功能开关发布
- 开关支持即时回滚
- 开关支持按百分比控制发布范围
- 正式发布后清理开关(避免积累技术债务)
回滚触发条件:
- 护栏指标被突破
- 错误率超过阈值
- 用户反馈严重问题
- 先行指标趋势恶化
从0到1阶段:阶段可压缩,比如Alpha测试可能仅针对3位客户,持续2天。
规模化阶段:有正式的阶段评审 gates,配备发布管理,拥有成熟的Beta测试项目。
3. Metrics Hierarchy
3. 指标层级
The Three-Tier Model:
┌─────────────────────────────────────────────────────┐
│ LAGGING METRICS │
│ (Revenue, Retention, NPS) │
│ Move slowly, hard to attribute │
├─────────────────────────────────────────────────────┤
│ CORE METRICS │
│ (Activation, Engagement, Conversion) │
│ The outcomes your bets target │
├─────────────────────────────────────────────────────┤
│ LEADING METRICS │
│ (Feature adoption, Task completion) │
│ Move fast, early signal │
└─────────────────────────────────────────────────────┘Metric Types:
| Type | Definition | Example | Use For |
|---|---|---|---|
| Leading | Early signal, fast-moving, directly influenced by feature | Feature adoption rate, task completion rate | Weekly decisions, rollout gates |
| Core | Primary outcome you're targeting | Activation rate, conversion rate, engagement score | Bet success criteria |
| Lagging | Business results, slow-moving, influenced by many factors | Revenue, retention, NPS | Quarterly/annual planning |
| Guardrail | Metrics you won't let degrade | Performance, error rate, support tickets | Rollout gates, rollback triggers |
Hierarchy Example (Activation Bet):
Lagging: Revenue growth (quarterly)
↑
Core: Activation rate (weekly)
↑
Leading: Onboarding completion (daily)
First value action (daily)
↑
Guardrail: Support tickets (daily)
Error rate (real-time)Metric Selection Criteria:
| Criterion | Question |
|---|---|
| Measurable | Can we actually track this? |
| Actionable | Can we influence it with our work? |
| Attributable | Can we connect changes to our bet? |
| Timely | Will we see signal fast enough to decide? |
Dashboard Design:
- Leading metrics: Real-time or daily
- Core metrics: Weekly view with trend
- Lagging metrics: Monthly/quarterly view
- Guardrails: Alerting, not just reporting
三层模型:
┌─────────────────────────────────────────────────────┐
│ 滞后指标(LAGGING METRICS) │
│ (收入、留存率、NPS) │
│ 变化缓慢,难以归因 │
├─────────────────────────────────────────────────────┤
│ 核心指标(CORE METRICS) │
│ (激活率、参与度、转化率) │
│ Bet瞄准的核心业务结果 │
├─────────────────────────────────────────────────────┤
│ 先行指标(LEADING METRICS) │
│ (功能采用率、任务完成率) │
│ 变化快速,提供早期信号 │
└─────────────────────────────────────────────────────┘指标类型:
| 类型 | 定义 | 示例 | 用途 |
|---|---|---|---|
| 先行指标 | 早期信号,变化快速,受功能直接影响 | 功能采用率、任务完成率 | 周度决策、发布阶段评审 |
| 核心指标 | 瞄准的核心业务结果 | 激活率、转化率、参与度得分 | Bet成功的判断标准 |
| 滞后指标 | 业务最终结果,变化缓慢,受多种因素影响 | 收入、留存率、NPS | 季度/年度规划 |
| 护栏指标 | 不允许出现恶化的指标 | 性能、错误率、支持工单数量 | 发布阶段评审、回滚触发条件 |
指标层级示例(激活Bet):
滞后指标: 收入增长(季度)
↑
核心指标: 激活率(周度)
↑
先行指标: 完成新手引导(日度)
首次价值动作(日度)
↑
护栏指标: 支持工单数量(日度)
错误率(实时)指标选择标准:
| 标准 | 对应问题 |
|---|---|
| 可衡量 | 我们能否实际追踪该指标? |
| 可行动 | 我们的工作能否影响该指标? |
| 可归因 | 我们能否将指标变化与Bet关联? |
| 及时性 | 我们能否及时获取信号以做出决策? |
仪表盘设计:
- 先行指标:实时或日度更新
- 核心指标:周度视图,展示趋势
- 滞后指标:月度/季度视图
- 护栏指标:设置告警,而非仅做报告
4. Bet Retrospectives
4. Bet复盘
The Core Idea:
Every bet concludes with an explicit decision: Scale, Iterate, or Kill.
Retrospective Format:
BET RETROSPECTIVE: [Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Timebox: [Duration] | Shipped: [Date]
HYPOTHESIS REVIEW
Original: "We believed [X] would result in [Y]"
Result: [ ] Confirmed [ ] Disproved [ ] Inconclusive
METRICS REVIEW
| Metric | Target | Actual | Verdict |
|-----------|--------|--------|---------|
| Primary | [X] | [Y] | ✅ / ❌ |
| Secondary | [X] | [Y] | ✅ / ❌ |
| Guardrail | [X] | [Y] | ✅ / ❌ |
KEY LEARNINGS
• [Learning 1]
• [Learning 2]
• [Learning 3]
DECISION: [ ] SCALE [ ] ITERATE [ ] KILL
NEXT STEPS
• [Action 1]
• [Action 2]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Decision Framework:
| Outcome | Criteria | Action |
|---|---|---|
| SCALE | Primary metric hit, no guardrail issues | Expand rollout, invest more |
| ITERATE | Signal positive but not at target | Refine and re-test (one more cycle) |
| KILL | Hypothesis disproved or too costly | Stop investment, document learning |
Iteration Limits:
- Maximum 2-3 iteration cycles before forcing Scale or Kill
- Each iteration must have a new hypothesis
- Time-bound iterations (don't let them drag)
Retrospective Cadence:
- Run at timebox end, regardless of "completion"
- Include full trio + relevant stakeholders
- 30-60 minutes maximum
- Document in central repository
0→1 Mode: Informal but still explicit. Even a Slack message: "Bet X result: [Y]. Decision: [Z]."
Scaling Mode: Formal retrospective meetings. Learning database. Cross-team sharing.
核心思想:
每个Bet都要以明确的决策收尾:扩大投入(Scale)、迭代优化(Iterate)或终止(Kill)。
复盘格式:
BET RETROSPECTIVE: [Bet名称]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
时间限制: [时长] | 发布日期: [日期]
假设回顾
原假设: "我们认为[X]将带来[Y]"
结果: [ ] 验证成立 [ ] 验证不成立 [ ] 无法确定
指标回顾
| 指标 | 目标值 | 实际值 | 结论 |
|-----------|--------|--------|---------|
| 核心指标 | [X] | [Y] | ✅ / ❌ |
| 次要指标 | [X] | [Y] | ✅ / ❌ |
| 护栏指标 | [X] | [Y] | ✅ / ❌ |
关键学习
• [学习点1]
• [学习点2]
• [学习点3]
决策: [ ] 扩大投入 [ ] 迭代优化 [ ] 终止
下一步行动
• [行动1]
• [行动2]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━决策框架:
| 结果 | 标准 | 行动 |
|---|---|---|
| 扩大投入 | 核心指标达标,无护栏指标问题 | 扩大发布范围,增加投入 |
| 迭代优化 | 信号积极但未达目标 | 优化后重新测试(最多1个周期) |
| 终止 | 假设不成立或成本过高 | 停止投入,记录学习成果 |
迭代限制:
- 最多允许2-3次迭代,之后必须做出扩大投入或终止的决策
- 每次迭代都要有新的假设
- 迭代有时间限制(避免无限拖延)
复盘节奏:
- 到时间节点就开展,无论是否“完成”
- 参与人员包括完整产品三人组及相关利益相关者
- 时长控制在30-60分钟
- 记录在中央知识库
从0到1阶段:形式灵活但决策明确,哪怕只是Slack消息:“Bet X结果: [Y]。决策: [Z]。”
规模化阶段:正式的复盘会议,拥有学习数据库,跨团队分享经验。
5. GTM Execution
5. GTM执行
The Core Idea:
PM owns adoption, not just availability. GTM is part of delivery, not an afterthought.
GTM Components:
| Component | Owner | Timing |
|---|---|---|
| Positioning & messaging | PMM / PM | During solution shaping |
| Sales enablement | PMM / PM | Before beta |
| Documentation | PM / Tech Writer | Before beta |
| Support training | PM / Support Lead | Before GA |
| Launch communications | PMM / Marketing | At GA |
| Customer success playbook | CS / PM | Before GA |
Launch Tiers:
| Tier | Definition | GTM Effort |
|---|---|---|
| Tier 1 | Major new capability, strategic priority | Full GTM: press, event, sales training, campaign |
| Tier 2 | Significant improvement, notable value | Moderate GTM: blog, email, sales brief |
| Tier 3 | Incremental improvement, quality of life | Light GTM: changelog, in-app, support brief |
| Tier 4 | Bug fix, minor enhancement | No GTM: release notes only |
Launch Checklist (Tier 1/2):
| Phase | Tasks |
|---|---|
| Pre-launch | Positioning defined, Sales trained, Support trained, Docs ready, Success playbook ready |
| Launch | Announcement sent, In-app messaging live, Sales notified, Support notified |
| Post-launch | Feedback monitored, Metrics tracked, Issues triaged, Iteration planned |
Adoption Metrics (PM Responsibility):
| Metric | Definition |
|---|---|
| Awareness | % of target users who know feature exists |
| Trial | % of aware users who try feature |
| Adoption | % of trial users who continue using |
| Habit | % of adopters using regularly |
0→1 Mode: PM does GTM. Scrappy launches. Focus on learning, not polish.
Scaling Mode: PMM partnership. Launch playbooks. Integrated marketing calendar.
核心思想:
产品经理对用户采用率负责,而非仅确保产品可用。GTM是交付的一部分,而非事后工作。
GTM组成部分:
| 组成部分 | 负责人 | 时间 |
|---|---|---|
| 定位与 messaging | 产品营销经理/产品经理 | 方案规划阶段 |
| 销售赋能 | 产品营销经理/产品经理 | Beta测试前 |
| 文档 | 产品经理/技术文档工程师 | Beta测试前 |
| 支持团队培训 | 产品经理/支持负责人 | 正式发布前 |
| 发布传播 | 产品营销经理/营销团队 | 正式发布时 |
| 客户成功手册 | 客户成功经理/产品经理 | 正式发布前 |
发布层级:
| 层级 | 定义 | GTM投入 |
|---|---|---|
| Tier 1 | 重大新功能,战略优先级 | 完整GTM:媒体发布、活动、销售培训、营销活动 |
| Tier 2 | 重要改进,价值显著 | 中等GTM:博客、邮件、销售简报 |
| Tier 3 | 增量改进,提升体验 | 轻度GTM:更新日志、应用内通知、支持简报 |
| Tier 4 | Bug修复、小增强 | 无GTM:仅发布说明 |
发布检查清单(Tier 1/2):
| 阶段 | 任务 |
|---|---|
| 发布前 | 定位明确、销售培训完成、支持团队培训完成、文档就绪、客户成功手册就绪 |
| 发布中 | 发送公告、应用内消息上线、通知销售团队、通知支持团队 |
| 发布后 | 监控反馈、追踪指标、处理问题、规划迭代 |
采用率指标(产品经理负责):
| 指标 | 定义 |
|---|---|
| 认知度 | 知道该功能存在的目标用户占比 |
| 试用率 | 知道功能的用户中尝试使用的占比 |
| 采用率 | 试用用户中持续使用的占比 |
| 习惯养成 | 采用用户中定期使用的占比 |
从0到1阶段:产品经理负责GTM,发布方式灵活,重点在学习而非完美。
规模化阶段:与产品营销经理协作,拥有发布手册,整合营销日历。
Key Outputs
关键产出
| Output | Description | Update Cadence |
|---|---|---|
| Rollout plan | Staged rollout with progression criteria | Per bet |
| Metrics dashboard | Leading, core, lagging, guardrail metrics | Continuous |
| Bet retrospective | Scale/Iterate/Kill decision with learnings | At timebox end |
| GTM checklist | Launch activities by tier | Per launch |
| Learning repository | Archive of bet results and learnings | After each retrospective |
| 产出 | 描述 | 更新节奏 |
|---|---|---|
| 发布计划 | 带阶段推进标准的分阶段发布方案 | 每个Bet对应一份 |
| 指标仪表盘 | 包含先行、核心、滞后、护栏指标的仪表盘 | 持续维护 |
| Bet复盘文档 | 包含扩大/迭代/终止决策及学习成果的文档 | 时间节点结束后完成 |
| GTM检查清单 | 按层级划分的发布活动清单 | 每个发布对应一份 |
| 学习知识库 | Bet结果与学习成果的存档 | 每次复盘后更新 |
Templates
模板
This skill includes templates in the directory:
templates/- — Staged rollout checklist
rollout-plan.md - — Metrics design template
metrics-hierarchy.md - — Retrospective format and decision framework
bet-retrospective.md - — GTM execution checklist by tier
launch-checklist.md
本技能在目录下提供以下模板:
templates/- — 分阶段发布检查清单
rollout-plan.md - — 指标设计模板
metrics-hierarchy.md - — 复盘格式与决策框架
bet-retrospective.md - — 按层级划分的GTM执行检查清单
launch-checklist.md
Using This Skill with Claude
与Claude配合使用
Ask Claude to:
- Design rollout plan: "Create a staged rollout plan for [feature]"
- Build metrics hierarchy: "Design a metrics hierarchy for [bet/product]"
- Set success criteria: "What metrics should determine success for [bet]?"
- Plan retrospective: "Create a retrospective agenda for [bet] that shipped [X]"
- Analyze results: "Given these metrics, should we scale, iterate, or kill?"
- Design launch tier: "What launch tier should [feature] be? What GTM is needed?"
- Create launch checklist: "Build a GTM checklist for [Tier X] launch"
- Identify guardrails: "What guardrail metrics should we watch for [bet]?"
- Plan dual-track: "Help me design a dual-track rhythm for [team size]"
- Write changelog: "Write release notes for [feature] at [tier]"
你可以让Claude:
- 设计发布计划: "为[功能]创建分阶段发布计划"
- 搭建指标层级: "为[Bet/产品]设计指标层级"
- 设定成功标准: "[Bet]的成功应该用哪些指标衡量?"
- 规划复盘: "为[X日期发布的Bet]创建复盘议程"
- 分析结果: "基于这些指标,我们应该扩大投入、迭代还是终止?"
- 确定发布层级: "[功能]应该属于哪个发布层级?需要哪些GTM工作?"
- 创建发布检查清单: "为[X层级]发布创建GTM检查清单"
- 识别护栏指标: "[Bet]需要关注哪些护栏指标?"
- 规划双轨节奏: "帮我为[团队规模]设计双轨开发节奏"
- 撰写更新日志: "为[层级]发布的[功能]撰写发布说明"
Connection to Other Skills
与其他技能的关联
| When you need to... | Use skill |
|---|---|
| Define what metrics ladder up to | |
| Validate before delivery | |
| Define what you're delivering | |
| Adapt delivery for AI products | |
| Scale delivery across teams | |
| 当你需要... | 使用技能 |
|---|---|
| 定义指标对应的业务目标 | |
| 交付前验证需求 | |
| 定义交付内容 | |
| 为AI产品适配交付流程 | |
| 跨团队规模化交付 | |
Anti-Patterns to Avoid
需避免的反模式
| Anti-Pattern | Why It Fails | Instead |
|---|---|---|
| Ship and forget | No learning, no improvement | Measure and retrospect |
| Big bang launch | Maximum risk, no learning | Staged rollout |
| Vanity metrics | Activity ≠ outcome | Hierarchical metrics |
| Zombie bets | Resources trapped, no clarity | Explicit Scale/Iterate/Kill |
| GTM afterthought | Features available but not adopted | GTM as part of delivery |
| Perfectionism | Never ships, never learns | Timebox and ship |
| 反模式 | 问题所在 | 正确做法 |
|---|---|---|
| 发布后不管不顾 | 无学习,无改进 | 衡量并复盘 |
| 一次性全量发布 | 风险最大化,无学习 | 分阶段发布 |
| 虚荣指标 | 活动量≠成果 | 采用层级化指标 |
| 僵尸Bet | 资源被占用,无清晰方向 | 明确做出扩大/迭代/终止决策 |
| GTM事后工作 | 产品可用但无人使用 | 将GTM纳入交付流程 |
| 完美主义 | 永远不发布,永远不学习 | 设定时间盒并发布 |
Quick Reference: Delivery Quality Checklist
快速参考:交付质量检查清单
Before GA:
- Rollout staged — Not shipping to 100% first
- Feature flagged — Can roll back instantly
- Metrics instrumented — Can measure leading/core/lagging
- Guardrails defined — Know what triggers rollback
- GTM prepared — Docs, training, comms ready
- Retrospective scheduled — Date on calendar at timebox end
- Success criteria agreed — Team knows what Scale/Iterate/Kill means
正式发布前:
- 分阶段发布 — 不直接全量发布
- 功能开关 — 可即时回滚
- 指标埋点 — 可衡量先行/核心/滞后指标
- 护栏指标定义 — 明确回滚触发条件
- GTM准备就绪 — 文档、培训、传播材料就绪
- 复盘已排期 — 时间节点已加入日历
- 成功标准达成共识 — 团队明确扩大/迭代/终止的判断标准
Sources & Influences
参考资料与灵感来源
- Marty Cagan — INSPIRED, EMPOWERED
- Eric Ries — The Lean Startup
- Teresa Torres — Continuous Discovery Habits
- April Dunford — Obviously Awesome (for GTM)
Part of the Modern Product Operating Model by Yannick Maurice
- Marty Cagan — 《INSPIRED》《EMPOWERED》
- Eric Ries — 《精益创业》
- Teresa Torres — 《持续探索习惯》
- April Dunford — 《Obviously Awesome》(GTM相关)
本技能属于Yannick Maurice的Modern Product Operating Model合集