product-delivery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product 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-strategy
,
product-discovery
,
product-architecture
,
ai-native-product
,
product-leadership

"我们的目标不是发布产品,而是验证你的Bet是否正确。"
本技能围绕交付体系展开——即我们如何发布、衡量与学习。它采用探索与交付并行的双轨模式,通过分阶段发布产品、清晰的指标层级进行衡量、复盘总结经验,并精准执行GTM流程。
所属合集: Modern Product Operating Model — 一套可组合的产品技能合集。
相关技能:
product-strategy
,
product-discovery
,
product-architecture
,
ai-native-product
,
product-leadership

When 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:
  1. Ship features and never measure impact
  2. Measure vanity metrics that don't connect to outcomes
  3. Do "big bang" launches that create risk
  4. Never officially conclude bets—zombies live forever
  5. Treat GTM as marketing's problem after PM ships
The Delivery System ensures shipping is the beginning of learning, not the end.

大多数团队存在以下问题之一:
  1. 发布功能后从不衡量其影响
  2. 关注虚荣指标(vanity metrics),这些指标与业务成果无关
  3. 采用“一次性全量发布”,带来极高风险
  4. 从不正式终结Bet——“僵尸项目”长期存在
  5. 将GTM视为产品经理发布后的营销问题
交付体系确保发布是学习的开始,而非结束

Philosophy

核心理念

Core Beliefs

核心信念

  1. Discovery and delivery run in parallel — Don't pause discovery to deliver
  2. Staged rollouts are the default — Ship to 10% before 100%
  3. Metrics exist in hierarchy — Leading → Core → Lagging
  4. Every bet gets a retrospective — Explicit scale/iterate/kill decision
  5. GTM is a product responsibility — PM owns adoption, not just availability
  1. 探索与交付并行 — 不要为了交付而暂停探索
  2. 分阶段发布为默认策略 — 先向10%用户发布,再逐步扩展到100%
  3. 指标存在层级关系 — 先行指标 → 核心指标 → 滞后指标
  4. 每个Bet都要复盘 — 明确做出扩大投入、迭代优化或终止的决策
  5. 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:
TrackActivitiesWho
Discovery TrackInterviews, OST updates, solution exploration, assumption testsFull trio (PM heavy)
Delivery TrackBuilding, testing, shipping, measuringFull trio (Eng heavy)
Time Allocation (Example):
RoleDiscoveryDelivery
PM60%40%
Designer50%50%
Tech Lead30%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:
StageAudienceDurationPurpose
Stage 0: InternalTeam dogfooding1-3 daysFind obvious bugs
Stage 1: Alpha5-10 friendly customers1 weekQualitative feedback
Stage 2: Beta10% of users1-2 weeksQuantitative signal
Stage 3: GA100% of usersOngoingFull measurement
Progression Criteria:
FromToCriteria
Internal → AlphaReady for externalNo P0 bugs, core flow works
Alpha → BetaValidated experiencePositive qualitative feedback, no major usability issues
Beta → GAMetrics acceptableLeading 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:
TypeDefinitionExampleUse For
LeadingEarly signal, fast-moving, directly influenced by featureFeature adoption rate, task completion rateWeekly decisions, rollout gates
CorePrimary outcome you're targetingActivation rate, conversion rate, engagement scoreBet success criteria
LaggingBusiness results, slow-moving, influenced by many factorsRevenue, retention, NPSQuarterly/annual planning
GuardrailMetrics you won't let degradePerformance, error rate, support ticketsRollout 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:
CriterionQuestion
MeasurableCan we actually track this?
ActionableCan we influence it with our work?
AttributableCan we connect changes to our bet?
TimelyWill 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:
OutcomeCriteriaAction
SCALEPrimary metric hit, no guardrail issuesExpand rollout, invest more
ITERATESignal positive but not at targetRefine and re-test (one more cycle)
KILLHypothesis disproved or too costlyStop 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:
ComponentOwnerTiming
Positioning & messagingPMM / PMDuring solution shaping
Sales enablementPMM / PMBefore beta
DocumentationPM / Tech WriterBefore beta
Support trainingPM / Support LeadBefore GA
Launch communicationsPMM / MarketingAt GA
Customer success playbookCS / PMBefore GA
Launch Tiers:
TierDefinitionGTM Effort
Tier 1Major new capability, strategic priorityFull GTM: press, event, sales training, campaign
Tier 2Significant improvement, notable valueModerate GTM: blog, email, sales brief
Tier 3Incremental improvement, quality of lifeLight GTM: changelog, in-app, support brief
Tier 4Bug fix, minor enhancementNo GTM: release notes only
Launch Checklist (Tier 1/2):
PhaseTasks
Pre-launchPositioning defined, Sales trained, Support trained, Docs ready, Success playbook ready
LaunchAnnouncement sent, In-app messaging live, Sales notified, Support notified
Post-launchFeedback monitored, Metrics tracked, Issues triaged, Iteration planned
Adoption Metrics (PM Responsibility):
MetricDefinition
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 4Bug修复、小增强无GTM:仅发布说明
发布检查清单(Tier 1/2):
阶段任务
发布前定位明确、销售培训完成、支持团队培训完成、文档就绪、客户成功手册就绪
发布中发送公告、应用内消息上线、通知销售团队、通知支持团队
发布后监控反馈、追踪指标、处理问题、规划迭代
采用率指标(产品经理负责):
指标定义
认知度知道该功能存在的目标用户占比
试用率知道功能的用户中尝试使用的占比
采用率试用用户中持续使用的占比
习惯养成采用用户中定期使用的占比
从0到1阶段:产品经理负责GTM,发布方式灵活,重点在学习而非完美。 规模化阶段:与产品营销经理协作,拥有发布手册,整合营销日历。

Key Outputs

关键产出

OutputDescriptionUpdate Cadence
Rollout planStaged rollout with progression criteriaPer bet
Metrics dashboardLeading, core, lagging, guardrail metricsContinuous
Bet retrospectiveScale/Iterate/Kill decision with learningsAt timebox end
GTM checklistLaunch activities by tierPer launch
Learning repositoryArchive of bet results and learningsAfter each retrospective

产出描述更新节奏
发布计划带阶段推进标准的分阶段发布方案每个Bet对应一份
指标仪表盘包含先行、核心、滞后、护栏指标的仪表盘持续维护
Bet复盘文档包含扩大/迭代/终止决策及学习成果的文档时间节点结束后完成
GTM检查清单按层级划分的发布活动清单每个发布对应一份
学习知识库Bet结果与学习成果的存档每次复盘后更新

Templates

模板

This skill includes templates in the
templates/
directory:
  • rollout-plan.md
    — Staged rollout checklist
  • metrics-hierarchy.md
    — Metrics design template
  • bet-retrospective.md
    — Retrospective format and decision framework
  • launch-checklist.md
    — GTM execution checklist by tier

本技能在
templates/
目录下提供以下模板:
  • rollout-plan.md
    — 分阶段发布检查清单
  • metrics-hierarchy.md
    — 指标设计模板
  • bet-retrospective.md
    — 复盘格式与决策框架
  • launch-checklist.md
    — 按层级划分的GTM执行检查清单

Using This Skill with Claude

与Claude配合使用

Ask Claude to:
  1. Design rollout plan: "Create a staged rollout plan for [feature]"
  2. Build metrics hierarchy: "Design a metrics hierarchy for [bet/product]"
  3. Set success criteria: "What metrics should determine success for [bet]?"
  4. Plan retrospective: "Create a retrospective agenda for [bet] that shipped [X]"
  5. Analyze results: "Given these metrics, should we scale, iterate, or kill?"
  6. Design launch tier: "What launch tier should [feature] be? What GTM is needed?"
  7. Create launch checklist: "Build a GTM checklist for [Tier X] launch"
  8. Identify guardrails: "What guardrail metrics should we watch for [bet]?"
  9. Plan dual-track: "Help me design a dual-track rhythm for [team size]"
  10. Write changelog: "Write release notes for [feature] at [tier]"

你可以让Claude:
  1. 设计发布计划: "为[功能]创建分阶段发布计划"
  2. 搭建指标层级: "为[Bet/产品]设计指标层级"
  3. 设定成功标准: "[Bet]的成功应该用哪些指标衡量?"
  4. 规划复盘: "为[X日期发布的Bet]创建复盘议程"
  5. 分析结果: "基于这些指标,我们应该扩大投入、迭代还是终止?"
  6. 确定发布层级: "[功能]应该属于哪个发布层级?需要哪些GTM工作?"
  7. 创建发布检查清单: "为[X层级]发布创建GTM检查清单"
  8. 识别护栏指标: "[Bet]需要关注哪些护栏指标?"
  9. 规划双轨节奏: "帮我为[团队规模]设计双轨开发节奏"
  10. 撰写更新日志: "为[层级]发布的[功能]撰写发布说明"

Connection to Other Skills

与其他技能的关联

When you need to...Use skill
Define what metrics ladder up to
product-strategy
Validate before delivery
product-discovery
Define what you're delivering
product-architecture
Adapt delivery for AI products
ai-native-product
Scale delivery across teams
product-leadership

当你需要...使用技能
定义指标对应的业务目标
product-strategy
交付前验证需求
product-discovery
定义交付内容
product-architecture
为AI产品适配交付流程
ai-native-product
跨团队规模化交付
product-leadership

Anti-Patterns to Avoid

需避免的反模式

Anti-PatternWhy It FailsInstead
Ship and forgetNo learning, no improvementMeasure and retrospect
Big bang launchMaximum risk, no learningStaged rollout
Vanity metricsActivity ≠ outcomeHierarchical metrics
Zombie betsResources trapped, no clarityExplicit Scale/Iterate/Kill
GTM afterthoughtFeatures available but not adoptedGTM as part of delivery
PerfectionismNever ships, never learnsTimebox 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合集