Back to Details

feature-launch-playbook

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feature Launch Playbook

功能发布执行手册

A veteran PM-leader's playbook for launching features well, not just shipping them.
Most teams conflate shipping, releasing, and launching. Shipping means engineering work is complete. Releasing means users can access it, even if it is behind a flag at 1 percent. Launching is the discipline of positioning, internal alignment, customer comms, sales enablement, support readiness, rollout strategy, monitoring, and post-launch measurement that turns "feature exists" into "feature lands."
A feature that ships without launching costs you the same engineering investment but captures a fraction of the value. Sales does not know how to sell it. Support does not know how to help with it. Customers do not notice it. The metric you said you would move does not move because nobody knows the feature is there.
This skill is the operational playbook. It assumes you have already written the spec (
pm-spec-writing
), prioritized it onto the roadmap (
roadmap-planning
), instrumented it (
product-analytics-setup
), and possibly tested it (
experiment-design
). The launch is the next discipline: how to actually get the feature in front of the right users, with the right context, in a way that lets you measure whether it worked.
When to use this skill: planning a launch (any size, any segment), auditing an existing launch process, fixing the "we shipped it but the metric did not move" problem, or building a launch checklist for the team.
资深PM领导者出品的功能发布执行手册，聚焦如何让功能真正落地，而非仅仅完成交付。
大多数团队会混淆交付（shipping）、发布（releasing）与正式启动（launching）的概念。交付指工程工作完成；发布指用户可访问功能，哪怕仅通过功能灰度给1%的用户；正式启动则是一套包含定位、内部对齐、客户沟通、销售赋能、支持准备、发布策略、监控及发布后度量的规范，能将“功能已存在”转化为“功能真正落地生效”。
仅完成交付却未正式启动的功能，投入的工程成本相同，但能获取的价值却微乎其微。销售不知道如何推广，客服不知道如何提供支持，客户根本没注意到功能的存在。原本预期会提升的指标毫无变化，核心原因就是没人知道这个功能的存在。
本手册是一套操作执行指南，默认你已完成规格撰写（
pm-spec-writing
）、 roadmap规划（
roadmap-planning
）、埋点部署（
product-analytics-setup
），且可能完成了测试（
experiment-design
）。正式启动是下一阶段的核心：如何让功能触达目标用户，传递正确信息，并验证功能是否真正有效。
适用场景：规划各类规模与细分领域的发布、审计现有发布流程、解决“已交付但指标未达预期”的问题、为团队构建发布清单。

What this skill is for

本手册的适用范围

This skill spans the operational launch discipline. It composes with the rest of the Product skill suite.
  • pm-spec-writing
    defines the launch hypotheses; this skill validates them.
  • roadmap-planning
    provides the launch context (what came before, what comes next).
  • product-analytics-setup
    is the instrumentation prerequisite; without it you cannot measure the launch.
  • experiment-design
    and 
    data-warehouse-experimentation
    provide the methodology for testing whether the launch worked.
  • feature-flagging
    provides the rollout infrastructure this skill depends on.
This skill does not cover pricing decisions, brand campaigns, or full GTM strategy. Those need a marketing team partner; this is the PM operational playbook for the engineering and product side.
The audience is broad: every PM ships features, every PM has launched poorly at least once, every PM benefits from a checklist that stops the worst failure modes from recurring. The voice is veteran PM-leader to PM. Specific, opinionated, honest about what discipline matters at what stage.
本手册覆盖正式启动全流程的操作规范，可与其他产品技能模块配合使用：
  • pm-spec-writing
    定义了发布假设，本手册负责验证这些假设；
  • roadmap-planning
    提供发布背景（之前的规划、后续的方向）；
  • product-analytics-setup
    是度量的前提，没有埋点就无法衡量发布效果；
  • experiment-design
    和
    data-warehouse-experimentation
    提供验证发布效果的方法论；
  • feature-flagging
    是本手册依赖的灰度发布基础设施。
本手册不包含定价决策、品牌营销活动或完整的GTM策略，这些需要营销团队协作；本手册是面向产品与研发侧的PM操作指南。
受众广泛：每位PM都要交付功能，每位PM至少有过一次失败的发布经历，每位PM都能从这份清单中受益，避免重蹈覆辙。内容以资深PM领导者对PM的视角呈现，具体、有主见，坦诚不同阶段需要关注的核心规范。

Ship vs release vs launch

交付、发布与正式启动的区别

The keystone distinction. Three definitions.
Shipping means engineering completes the work. Code is on production. No users can access it yet, or only internal users via a flag. The PR is merged and deployed.
Releasing means users can access it. Could be 1 percent rollout, could be 100 percent. The feature is "live" in some technical sense. The flag is on for at least one user.
Launching means positioning, internal alignment, customer comms, sales enablement, support readiness, rollout strategy, monitoring, and post-launch measurement are all in flight. The feature has been introduced to the people who would benefit from it, with the context they need to use it.
The pathology. PMs report "we shipped feature X" when what happened is engineering completed the work. The feature might be released to 1 percent of users with no announcement, no documentation, no sales enablement, no measurement plan. From a value-capture perspective, that is an unlaunched feature.
The discipline. Use precise vocabulary. "Engineering shipped on Tuesday. We are releasing to 25 percent on Thursday. We are launching publicly next month." The vocabulary forces honest accounting of what has and has not happened.
Most "feature failed" diagnoses turn out to be "feature was unlaunched." This skill is structured around the launch dimension because that is where most teams under-invest.
这是核心定义区分：
交付（shipping）：工程完成开发工作，代码部署到生产环境，但用户无法访问（或仅内部用户可通过功能开关访问），PR已合并并部署。
发布（releasing）：用户可访问功能，可能是灰度给1%的用户，也可能是全量开放。功能在技术层面“上线”，至少有一位用户能通过功能开关访问。
正式启动（launching）：定位、内部对齐、客户沟通、销售赋能、支持准备、发布策略、监控及发布后度量全部落地执行。功能已触达目标用户，并传递了使用所需的信息。
常见误区：PM汇报“我们交付了功能X”，实际只是工程完成了开发工作。功能可能灰度给1%的用户，但没有任何公告、文档、销售赋能或度量计划。从价值获取的角度看，这属于未正式启动的功能。
规范做法：使用精准的术语。“工程在周二完成交付，我们将在周四灰度给25%的用户，正式对外启动将在下个月。”精准的术语能让团队清晰掌握各阶段的进展。
大多数“功能失败”的案例，本质都是“功能未正式启动”。本手册围绕正式启动环节展开，因为这是大多数团队投入不足的地方。

Launch tiers

发布层级

Not every feature needs the full playbook. Match the work to the feature.
Tier 1 (full launch). Net-new product, major feature reshaping the product narrative, pricing change, breaking change. Full playbook: positioning, all comms channels, sales enablement, customer success briefing, dedicated post-launch measurement, executive announcement.
Tier 2 (focused launch). Meaningful improvement that materially affects user value or competitive positioning. Subset of the playbook: in-app comms, blog post or release note, support readiness, rollout strategy, post-launch measurement.
Tier 3 (release note). Incremental improvement, bug fix made positive, polish. Minimal: changelog entry, release note, light monitoring.
The trap on either side.
  • Treating every release as Tier 1 produces comms fatigue. Customers tune out the announcement firehose; your real Tier 1 launches lose signal in the noise.
  • Treating every release as Tier 3 produces unlaunched features. The feature ships, the metric does not move, the team concludes "users do not want this" when the actual cause is "users were not told."
Match the tier to the feature. This skill primarily covers Tier 1 and Tier 2. Tier 3 is mostly the changelog discipline; the launch playbook applies but compressed to the changelog entry plus light monitoring.
Detail in 
references/launch-tier-decision.md
.
并非所有功能都需要完整执行本手册，需根据功能规模匹配投入：
一级发布（全流程启动）：全新产品、重塑产品叙事的重大功能、定价变更、破坏性变更。需执行完整手册：定位、全渠道沟通、销售赋能、客户成功培训、专属发布后度量、高管公告。
二级发布（聚焦式启动）：对用户价值或竞争定位有实质影响的重要改进。执行手册部分内容：应用内沟通、博客或发布说明、支持准备、发布策略、发布后度量。
三级发布（仅发布说明）：增量改进、正向修复的Bug、体验优化。仅需最小化操作：更新变更日志、发布说明、轻量监控。
常见陷阱：
  • 把所有发布都当作一级发布，会导致沟通疲劳，客户对公告麻木，真正的一级发布信号会被噪音掩盖；
  • 把所有发布都当作三级发布，会产生大量未正式启动的功能，交付后指标毫无变化，团队误以为“用户不需要这个功能”，实际原因是“用户根本不知道功能存在”。
需根据功能匹配发布层级。本手册主要覆盖一级和二级发布，三级发布核心是变更日志规范，仅需压缩版的启动流程（变更日志+轻量监控）。
详情见 
references/launch-tier-decision.md
。

Pre-launch: positioning

启动前：定位

Positioning answers: who is this for, what problem does it solve, why now, and what is the user-visible promise.
The positioning canvas. One page, filled out before any comms drafting.
  • Target user. Segment, role, jobs-to-be-done. Specific enough that a sales rep could describe the customer profile in one sentence.
  • Problem it solves. Specifically, in user words. Not "we improve productivity"; instead "the customer support manager who needs to triage 200 tickets a day cannot tell which are urgent without opening each one."
  • Current alternative. What users do today without this. The status quo is the real competition.
  • User-visible promise. One sentence. The promise the user will hear when they encounter the feature in the wild.
  • Proof points. Three to five specific capabilities or outcomes. Concrete, not adjectives.
  • Anti-positioning. What this is NOT, what it does not try to do. Prevents over-promising.
The most common positioning failure is a vague target user. "It is for PMs" is not a target. "It is for B2B SaaS PMs at companies with 50 to 500 customers who need to coordinate roadmap discussions across engineering and customer success" is a target. The specificity is what lets sales, marketing, and support speak the same language about who this is for.
Detail in 
references/positioning-canvas.md
.
定位需回答：面向谁、解决什么问题、为什么是现在、用户可见的价值承诺是什么。
定位画布：一页文档，需在任何沟通内容撰写前完成：
  • 目标用户：细分群体、角色、待完成任务。需具体到销售能一句话描述客户画像的程度；
  • 解决的问题：用用户的语言具体描述，而非“提升生产力”，例如“每天需处理200个工单的客服经理，不打开每个工单就无法判断优先级”；
  • 当前替代方案：用户在没有该功能时的现状，现状才是真正的竞品；
  • 用户可见的价值承诺：一句话总结，用户接触功能时能感知到的承诺；
  • 证明点：3-5个具体的能力或成果，需具象，而非形容词；
  • 反向定位：明确功能不面向谁、不解决什么问题，避免过度承诺。
最常见的定位失败是目标用户模糊。“面向PM”不是精准目标，“面向客户规模50-500人的B2B SaaS PM，需协调研发与客户成功的roadmap讨论”才是精准目标。精准的定位能让销售、营销、客服用统一的语言描述目标用户。
详情见 
references/positioning-canvas.md
。

Pre-launch: internal alignment

启动前：内部对齐

Stakeholders who need to know before launch.
  • Engineering leadership. Capacity for follow-ups, support escalations, post-launch fixes.
  • Sales leadership. Revenue forecast updates, deal coaching, pipeline impact.
  • Customer success leadership. Proactive customer notifications, deal saves at risk, expansion conversations.
  • Marketing leadership. Paid spend coordination, blog calendar, social timing.
  • Support leadership. Training, FAQ, escalation paths.
  • Executive sponsor. Visibility, public messaging, investor or board reporting.
The discipline. A single internal launch brief, distributed two to four weeks before launch (Tier 1) or one week before (Tier 2). The brief contains a one-page summary, an FAQ, a decision log of choices already made, and the launch calendar. The brief should answer "what do I need to do differently because of this launch."
The most common internal alignment failure: launching without sales knowing. Sales finds out from a customer asking about it. Trust erodes for the next launch. The fix is the launch brief plus a sales-specific briefing one to two weeks before customer-facing launch.
Detail in 
references/internal-alignment-checklist.md
.
需在启动前同步的利益相关方：
  • 研发负责人：后续跟进、支持升级、发布后修复的产能；
  • 销售负责人：营收预测更新、Deal辅导、 pipeline影响；
  • 客户成功负责人：主动客户通知、风险Deal挽救、扩容沟通；
  • 营销负责人：付费投放协调、博客日程、社交平台发布时机；
  • 客服负责人：培训、FAQ、升级路径；
  • 高管 sponsor：进度 visibility、对外口径、投资者或董事会汇报。
规范做法：一份统一的内部启动简报，一级发布提前2-4周分发，二级发布提前1周分发。简报包含一页摘要、FAQ、已做决策日志、发布日程，需明确回答“我需要因这次发布做出哪些改变”。
最常见的内部对齐失败：启动前未同步销售，销售从客户询问中才得知功能发布，这会影响下一次启动的信任度。解决方法是分发启动简报，并在客户面向发布前1-2周专门给销售做培训。
详情见 
references/internal-alignment-checklist.md
。

Pre-launch: customer comms plan

启动前：客户沟通计划

Channels and decision factors.
  • In-app. Highest reach for active users; right for product-internal features. Tooltips, banners, modals.
  • Email (transactional or campaign). High reach across active and inactive users; right for material changes that affect existing workflows.
  • Blog post. SEO plus lead gen plus narrative; right for Tier 1 launches with external story.
  • Release notes. Discoverable, archived, queryable; right for every Tier 2 and above. Often the canonical reference customers find later.
  • Social (LinkedIn, X, Bluesky). Reach beyond existing customers; right when launch has external narrative or competitive angle.
  • Webinar or customer call. Depth for enterprise customers; right for Tier 1 with material customer impact.
  • Sales-led briefing. High-touch for top accounts; right when launch affects pricing, contracts, or strategic positioning.
For each channel: who drafts, who approves, what is the timing, what is the call to action.
The comms calendar pattern. A single document with all channels and dates, distributed in the internal launch brief. Prevents the "blog post went out before sales got the briefing" failure. Ordering typically goes: sales briefing first, support training second, customer success outreach to top accounts third, public comms fourth.
Detail in 
references/customer-comms-playbook.md
.
沟通渠道及决策因素：
  • 应用内：触达活跃用户的最高效渠道，适用于产品内部功能，如提示框、横幅、弹窗；
  • 邮件（事务性或营销性）：触达活跃与非活跃用户，适用于影响现有工作流程的重大变更；
  • 博客：SEO、获客、传递叙事，适用于有外部故事的一级发布；
  • 发布说明：可发现、可存档、可查询，适用于所有二级及以上发布，通常是客户后续查询的权威参考；
  • 社交平台（LinkedIn、X、Bluesky）：触达现有客户之外的用户，适用于有外部叙事或竞争角度的发布；
  • ** webinar或客户会议**：面向企业客户的深度沟通，适用于对客户有重大影响的一级发布；
  • 销售主导的培训：面向顶级客户的高触达沟通，适用于影响定价、合同或战略定位的发布。
每个渠道需明确：撰写人、审批人、发布时间、行动号召。
沟通日程规范：一份包含所有渠道及日期的文档，随内部启动简报分发，避免“博客已发布但销售还未收到培训”的失误。通常顺序为：销售培训→客服培训→客户成功触达顶级客户→对外沟通。
详情见 
references/customer-comms-playbook.md
。

Pre-launch: sales enablement (B2B)

启动前：销售赋能（B2B）

For B2B products, sales enablement is not optional for Tier 1 and most Tier 2 launches. The deliverables.
  • One-page battlecard. Positioning, target customer, top objections, proof points. Sales can read it in two minutes and pitch the feature in five.
  • Demo script and recorded demo. A repeatable demo the rep can run with a customer; the recorded version is the fallback for reps who join after the launch.
  • Pricing change documentation if applicable. Sales reps cannot answer pricing questions accurately without explicit guidance.
  • Deal coaching guide. Which deals does this unblock, which does it complicate. Specific named accounts where appropriate.
  • Internal training session live or recorded, with Q&A archived. Sales reps need the chance to ask questions before they take the feature to a customer.
The "shadow launch" failure. Feature ships, sales hears about it from product team Slack, no battlecard, sales reps either ignore it or misrepresent it to customers. Customers churn because the feature was promised in a way that did not match reality.
For B2C and PLG products, this section is mostly skipped. The user is the buyer; there is no sales motion. Note this explicitly so PMs in those contexts do not feel they are missing the discipline.
Detail in 
references/sales-enablement-template.md
.
对于B2B产品，一级及多数二级发布必须做销售赋能，交付物包括：
  • 一页战斗卡片：定位、目标客户、常见异议、证明点。销售可在2分钟内读完，并在5分钟内完成功能演示；
  • 演示脚本与录屏：可重复使用的演示脚本，录屏版本供发布后加入的销售参考；
  • 定价变更文档（如有）：没有明确指导，销售无法准确回答定价问题；
  • Deal辅导指南：哪些Deal会被解锁，哪些会变得复杂，必要时明确具体客户；
  • 内部培训（直播或录屏）：包含存档的问答环节，销售需在面向客户前有机会提问。
“影子发布”失败案例：功能交付后，销售从产品Slack得知消息，但没有战斗卡片，销售要么忽略功能，要么向客户错误宣传，导致客户因预期不符而流失。
对于B2C和PLG产品，此部分可跳过，因为用户即购买者，没有销售流程。需明确说明，避免这类场景的PM误以为遗漏了规范。
详情见 
references/sales-enablement-template.md
。

Pre-launch: support readiness

启动前：支持准备

Support is often the first to encounter the failure modes of a new feature. They need.
  • Training live or recorded, with Q&A. The same content as the sales training adapted to support workflows.
  • FAQ document covering known questions, known limitations, and known bugs at launch. The FAQ updates daily during the first week as new questions surface.
  • Escalation path for issues that need engineering or PM. Named owners and turnaround time commitments.
  • Monitoring access or a way to ask for it. Support reps should be able to verify whether a customer's issue is feature-specific.
The discipline. The support team's confusion is the test customer's confusion. If support does not understand the feature, neither will customers. Train support before customer-facing launch comms go out.
Detail in 
references/support-readiness-checklist.md
.
客服往往是第一个遇到新功能问题的角色，他们需要：
  • 培训（直播或录屏）：内容与销售培训一致，但适配客服工作流程；
  • FAQ文档：涵盖已知问题、已知限制、发布时的已知Bug，启动第一周需每日更新；
  • 升级路径：明确需研发或PM介入的问题对接人及响应时间承诺；
  • 监控权限：或获取权限的渠道，客服需能验证客户问题是否为功能特定问题。
规范做法：客服的困惑就是测试客户的困惑，如果客服不理解功能，客户也不会理解。需在客户面向沟通发布前完成客服培训。
详情见 
references/support-readiness-checklist.md
。

Launch day: rollout strategy

启动日：发布策略

Four common patterns matched to feature type.
All-at-once (big bang). Zero to 100 percent in a single deploy. Right for marketing-coordinated launches where the announcement IS the rollout. Risky for anything where bugs would affect a meaningful customer base. Use sparingly.
Gradual percentage rollout. 1 percent, then 10 percent, then 25 percent, then 50 percent, then 100 percent over hours or days, monitored at each step. Right for most feature launches; the default unless there is a reason to deviate.
Flag-gated cohort rollout. Targeted to specific user segments. Free tier first, then paid. Small accounts first, then enterprise. Right for features with cohort-specific risk profiles.
Phased launch (multi-week). Launch to a subset of users, regions, or customers; gather feedback; iterate; expand. Right for Tier 1 launches with high uncertainty about user reception.
The decision framework. Feature blast radius times confidence in correctness times external commitments.
  • High blast radius plus low confidence plus no external commitment: phased.
  • Low blast radius plus high confidence plus external launch date: all-at-once.
  • The middle (most launches): gradual percentage rollout.
Detail in 
references/rollout-strategy-patterns.md
.
四种常见模式，需匹配功能类型：
全量发布（Big Bang）：从0到100%一次性部署。适用于营销协同的发布，公告即发布。但对于可能影响大量客户的功能风险极高，需谨慎使用。
渐进式灰度发布：按1%→10%→25%→50%→100%的比例，在数小时或数天内逐步灰度，每一步都监控。适用于大多数功能发布，是默认选择，除非有特殊理由。
功能开关分组灰度：定向给特定用户群体，比如先免费版再付费版，先小客户再企业客户。适用于有特定风险群体的功能。
分阶段发布（数周）：先给部分用户、区域或客户发布，收集反馈、迭代后再扩大范围。适用于用户接受度不确定性高的一级发布。
决策框架：功能影响范围 × 正确性信心 × 外部承诺。
  • 高影响范围 + 低信心 + 无外部承诺：分阶段发布；
  • 低影响范围 + 高信心 + 外部发布日期：全量发布；
  • 中间情况（大多数发布）：渐进式灰度发布。
详情见 
references/rollout-strategy-patterns.md
。

Launch day: monitoring

启动日：监控

Pre-launch, define what you will monitor and what alerts you. Common dimensions.
  • Error rates. Overall plus feature-specific.
  • Latency. Overall plus feature-specific.
  • Feature usage rate. People who SHOULD use it actually do.
  • Funnel completion. Users complete the new flow.
  • Support ticket volume. Especially feature-specific tags.
  • Customer satisfaction signals. NPS comments, feedback widget mentions.
Define the rollback trigger explicitly before launch. Examples.
  • "Error rate above 1 percent sustained for 5 minutes triggers rollback."
  • "Support tickets mentioning the feature exceed 50 in the first hour triggers escalation."
  • "Funnel completion drops below 50 percent of pre-launch baseline for any cohort triggers paused rollout."
The "no rollback trigger" failure. Launch goes sideways. The team debates whether to roll back for an hour while the issue compounds. Pre-defined triggers remove the debate; the rule fires automatically and the team executes the rollback.
Detail in 
references/monitoring-readiness-checklist.md
.
启动前需定义监控指标及告警规则，常见维度：
  • 错误率：全局及功能特定错误率；
  • 延迟：全局及功能特定延迟；
  • 功能使用率：目标用户是否真正使用；
  • 漏斗完成率：用户是否完成新流程；
  • 客服工单量：尤其是标记为功能相关的工单；
  • 客户满意度信号：NPS评论、反馈组件提及。
启动前需明确回滚触发条件，例如：
  • “错误率持续5分钟超过1%触发回滚”；
  • “启动第一小时内功能相关工单超过50个触发升级”；
  • “任何群体的漏斗完成率低于启动前基线的50%触发暂停灰度”。
“无回滚触发条件”失败案例：发布出现问题，团队花一小时争论是否回滚，导致问题扩大。预设触发条件能消除争论，自动执行回滚规则。
详情见 
references/monitoring-readiness-checklist.md
。

Launch day: comms execution

启动日：沟通执行

The comms calendar from the customer comms section executes on launch day. Each channel has a clear owner, a clear time, and a clear sequence.
  • In-app banner activates when rollout reaches X percent.
  • Email sends after a 4-hour stability check.
  • Blog post publishes at the time announced internally.
  • Sales briefing happens one day before public comms.
  • Support training happens one week before launch.
The "comms misfire" failure. Blog post auto-publishes at the scheduled time, but the rollout was paused two hours earlier due to an issue. Customers click through to a feature that is behind a flag for them. They lose trust; the launch story breaks.
The fix. Make external comms manually triggered, gated on a rollout health check. The comms timing in the calendar is the planned timing; the actual fire is conditional on the rollout passing the health check.
客户沟通计划中的日程需在启动日执行，每个渠道需明确负责人、时间及顺序：
  • 灰度到X%时激活应用内横幅；
  • 稳定性检查4小时后发送邮件；
  • 按内部通知时间发布博客；
  • 对外沟通前1天完成销售培训；
  • 启动前1周完成客服培训。
“沟通失误”失败案例：博客按预定时间自动发布，但2小时前因问题暂停了灰度，客户点击后发现功能对自己不可用，失去信任，发布叙事破裂。
解决方法：对外沟通需手动触发，以灰度健康检查为前提。日程中的时间是计划时间，实际发布需根据灰度健康情况决定。

Post-launch: measurement against spec hypotheses

启动后：基于规格假设的度量

The spec (per 
pm-spec-writing
) should have stated explicit hypotheses about what the feature would change. The launch measurement plan validates or invalidates each.
Four measurement dimensions.
  1. Adoption. Did the right users actually use it? The reach question. Is the feature visible to the target segment, and are they trying it.
  2. Engagement. Did users who tried it come back? The stickiness question. First use is necessary but not sufficient.
  3. Outcome. Did the metric the spec said this would move actually move? The effect question. The hypothesis the spec made.
  4. Side effects. Did any other metric move that was not supposed to? The safety question. Sometimes the feature works but breaks something else.
Time horizons. Most launches need two to four weeks of post-launch data for engagement signals, four to eight weeks for outcome signals. Do not declare success or failure too early.
The "no measurement plan" failure. Feature ships; the team moves on; six months later nobody knows if it worked. The feature becomes maintenance debt; the team cannot decide whether to invest in it further.
Detail in 
references/post-launch-measurement-framework.md
.
规格文档（
pm-spec-writing
）需明确功能预期带来的变化，发布度量计划需验证或推翻这些假设。
四个度量维度：
  1. ** adoption（用户采纳）**：目标用户是否真正使用？即触达问题，功能是否对目标群体可见，且他们是否尝试使用；
  2. ** engagement（用户参与）**：尝试使用的用户是否会回来？即粘性问题，首次使用是必要但不充分条件；
  3. ** outcome（业务结果）**：规格文档预期提升的指标是否真正变化？即效果问题，验证规格中的假设；
  4. ** side effects（副作用）**：是否有其他未预期的指标变化？即安全问题，有时功能生效但影响了其他环节。
时间周期：大多数发布需要2-4周数据观察参与信号，4-8周观察业务结果信号，不要过早宣布成功或失败。
“无度量计划”失败案例：功能交付后团队转向其他工作，6个月后没人知道功能是否有效，功能变成维护债务，团队无法决定是否继续投入。
详情见 
references/post-launch-measurement-framework.md
。

Post-launch: iteration and follow-ups

启动后：迭代与跟进

Within the first four weeks post-launch, expect.
  • Bug discoveries that did not surface in QA or limited rollout.
  • Usability issues that did not surface in user research.
  • Adoption gaps in cohorts you did not expect to under-adopt.
  • Feature requests for adjacent capabilities.
The discipline. Document every issue, triage weekly, prioritize fixes against the original measurement plan.
If adoption is below target, the question is. Is it a marketing problem (users do not know about the feature)? A usability problem (users try the feature and bounce)? A value problem (users try the feature and do not see value)? A wrong-segment problem (the target was not who we thought)?
Each diagnosis maps to a different fix.
  • Marketing problem: more comms, repeat comms, sales reactivation.
  • Usability problem: design or onboarding fix.
  • Value problem: feature redesign or repositioning.
  • Wrong-segment problem: re-target the comms to a different audience.
The "we declared victory" failure. The launch metric hits target in week 1 (often due to the launch announcement spike); the team moves on; the metric falls back to baseline by week 4. The launch was reported as successful but the feature did not actually land.
The fix. Declare success or failure based on a stable post-launch trend, not the launch-week spike. Most launches need at least a four-week stable trend before the success or failure call is reliable.
启动后前4周内，预期会出现：
  • QA或有限灰度未发现的Bug；
  • 用户研究未发现的可用性问题；
  • 未预期的用户群体采纳缺口；
  • 相邻功能的需求。
规范做法：记录所有问题，每周进行优先级排序，根据原始度量计划确定修复优先级。
如果采纳率低于目标，需分析原因：是营销问题（用户不知道功能）？可用性问题（用户尝试后放弃）？价值问题（用户尝试后未感知到价值）？目标群体错误（定位的用户并非真正需求群体）？
不同诊断对应不同解决方案：
  • 营销问题：增加沟通、重复触达、销售激活；
  • 可用性问题：优化设计或引导；
  • 价值问题：功能重新设计或定位；
  • 目标群体错误：调整沟通触达的受众。
“过早宣布胜利”失败案例：启动第一周指标达标（通常是发布公告带来的峰值），团队转向其他工作，到第四周指标回落至基线，发布被报告为成功，但功能并未真正落地。
解决方法：根据稳定的启动后趋势宣布成功或失败，而非启动周的峰值。大多数发布需要至少4周的稳定趋势才能可靠判断结果。

Common failure modes

常见失败模式

Twelve patterns recur across feature launches. Detail in 
references/common-launch-failures.md
.
  • "We shipped it but nothing happened." Unlaunched. No comms plan, no internal alignment, no measurement.
  • "Sales is confused and selling it wrong." No enablement. Battlecard, demo, training were skipped or rushed.
  • "Support is overwhelmed." No training, no FAQ. Support is encountering the feature for the first time when customers ask.
  • "We rolled out and immediately rolled back." No rollout strategy, no health check. The big-bang deploy hit production and broke.
  • "The blog post went out but the feature is broken." Comms misfire. The comms were not gated on rollout health.
  • "Adoption was great in week 1, now it is flat." Declared victory on the launch spike. The metric reverted to baseline.
  • "We do not know if it worked." No measurement plan tied to spec hypotheses.
  • "Customers say we did not tell them." Comms did not reach the right segments. Email went to active users only; inactive users were not notified.
  • "Enterprise customers found out from their account manager three days late." No high-touch tier in comms. Top accounts deserve sales-led briefing before public comms.
  • "Our metric moved but it was actually because of a different launch that week." No isolation. Cannot attribute the metric movement to this launch versus other concurrent changes.
  • "We launched the wrong feature." Positioning unclear. Customers expected something different from what shipped; the gap between expectation and reality reads as a failed launch even though the feature works.
  • "It worked but nobody knew about it internally." No internal alignment. Sales did not capitalize on the feature in deals; customer success did not save accounts that were churning over the gap this feature now closes.
功能发布有12种常见失败模式，详情见 
references/common-launch-failures.md
：
  • “交付了但毫无变化”：未正式启动，无沟通计划、无内部对齐、无度量；
  • “销售困惑，错误推广”：未做销售赋能，战斗卡片、演示、培训被跳过或仓促完成；
  • “客服不堪重负”：未做培训、无FAQ，客服在客户询问时才第一次接触功能；
  • “刚发布就回滚”：无发布策略、无健康检查，全量部署后出现问题；
  • “博客发布但功能故障”：沟通失误，沟通未以灰度健康检查为前提；
  • “第一周采纳率高，之后停滞”：基于启动峰值宣布胜利，指标回落至基线；
  • “不知道功能是否有效”：无基于规格假设的度量计划；
  • “客户说没收到通知”：沟通未触达目标群体，仅给活跃用户发了邮件，未通知非活跃用户；
  • “企业客户3天后才从客户经理处得知”：无高触达沟通层级，顶级客户需在对外沟通前接受销售主导的培训；
  • “指标变化但实际是其他发布导致”：未做隔离，无法将指标变化归因于本次发布还是同期其他变更；
  • “发布了错误的功能”：定位模糊，客户预期与实际交付不符，即便功能正常也被视为失败；
  • “功能有效但内部无人知晓”：无内部对齐，销售未在Deal中利用功能，客户成功未用功能挽救流失客户。

The framework: 12 considerations for a real launch

框架：真正启动的12项考量

When planning a launch, walk these 12 considerations. Skipping any of them produces one of the failure modes above.
  1. Tier the launch. Tier 1, Tier 2, or Tier 3. Match the effort to the feature.
  2. Position it. Target user, problem, promise, proof points, anti-positioning.
  3. Align internally. Single launch brief, distributed two to four weeks before launch.
  4. Plan customer comms. Channel mix, calendar, owners, gates.
  5. Enable sales. Battlecard, demo, training, deal coaching (B2B only).
  6. Ready support. Training, FAQ, escalation paths, monitoring access.
  7. Pick a rollout strategy. All-at-once, gradual, flag-gated, or phased.
  8. Define monitoring. Metrics, alerts, rollback triggers. Pre-defined, not in-the-moment.
  9. Sequence comms execution. Gated on health checks. Never auto-fire if the rollout is paused.
  10. Tie measurement to spec hypotheses. Adoption, engagement, outcome, side effects.
  11. Iterate post-launch. Weekly triage. Distinguish marketing, usability, value, and segment problems.
  12. Declare success or failure on a stable trend. Not the launch-week spike.
The output of the framework is a launch plan document. The positioning canvas, the internal launch brief, the comms calendar, the rollout strategy with health-check gates, the monitoring spec with rollback triggers, and the post-launch measurement plan tied to the spec hypotheses. The plan is reviewed two weeks before launch; gaps are filled before the launch date.
规划发布时，需逐一确认以下12项，跳过任何一项都可能导致上述失败模式：
  1. 确定发布层级：一级、二级或三级，匹配功能规模投入；
  2. 完成定位：目标用户、问题、价值承诺、证明点、反向定位；
  3. 内部对齐：一份启动简报，提前2-4周分发；
  4. 规划客户沟通：渠道组合、日程、负责人、触发条件；
  5. 销售赋能：战斗卡片、演示、培训、Deal辅导（仅B2B）；
  6. 支持准备：培训、FAQ、升级路径、监控权限；
  7. 选择发布策略：全量、渐进式、功能开关分组或分阶段；
  8. 定义监控规则：指标、告警、回滚触发条件，需提前设定而非临时决定；
  9. 沟通执行排序：以健康检查为前提，灰度暂停时绝不自动触发对外沟通；
  10. 度量绑定规格假设：用户采纳、参与、业务结果、副作用；
  11. 启动后迭代：每周优先级排序，区分营销、可用性、价值、群体问题；
  12. 基于稳定趋势判断成败：而非启动周峰值。
本框架的输出是一份发布计划文档，包含定位画布、内部启动简报、沟通日程、带健康检查的发布策略、带回滚触发的监控规范、绑定规格假设的发布后度量计划。计划需在启动前2周评审，填补所有缺口后再启动。

Reference files

参考文件

  • references/launch-tier-decision.md
     - Tier 1, 2, 3 decision framework with worked examples.
  • references/positioning-canvas.md
     - One-page positioning template with B2B SaaS, B2C, and developer feature examples.
  • references/internal-alignment-checklist.md
     - Stakeholders, brief structure, distribution timing by tier.
  • references/customer-comms-playbook.md
     - Channels, calendar, owners, gates.
  • references/sales-enablement-template.md
     - Battlecard, demo, deal coaching, training (B2B). Skip note for B2C and PLG.
  • references/support-readiness-checklist.md
     - Training, FAQ, escalation, monitoring access.
  • references/rollout-strategy-patterns.md
     - Four patterns matched to feature types. Decision framework: blast radius times confidence times external commitments.
  • references/monitoring-readiness-checklist.md
     - Metrics dimensions, alert thresholds, pre-defined rollback triggers.
  • references/post-launch-measurement-framework.md
     - Adoption, engagement, outcome, side effects. Time horizons. Tying back to spec hypotheses.
  • references/common-launch-failures.md
     - Twelve failure patterns with diagnoses and fixes.
  • references/launch-tier-decision.md
     - 一级、二级、三级发布决策框架及示例；
  • references/positioning-canvas.md
     - 一页定位模板，包含B2B SaaS、B2C、开发者功能示例；
  • references/internal-alignment-checklist.md
     - 利益相关方、简报结构、按层级的分发时间；
  • references/customer-comms-playbook.md
     - 沟通渠道、日程、负责人、触发条件；
  • references/sales-enablement-template.md
     - 战斗卡片、演示、Deal辅导、培训（B2B），含B2C和PLG产品跳过说明；
  • references/support-readiness-checklist.md
     - 培训、FAQ、升级路径、监控权限；
  • references/rollout-strategy-patterns.md
     - 四种发布模式及功能匹配，决策框架：影响范围×信心×外部承诺；
  • references/monitoring-readiness-checklist.md
     - 监控指标维度、告警阈值、预设回滚触发条件；
  • references/post-launch-measurement-framework.md
     - 用户采纳、参与、业务结果、副作用，时间周期，绑定规格假设；
  • references/common-launch-failures.md
     - 12种失败模式及诊断、解决方案。

Closing: most failed launches are unlaunched

结语：大多数失败的发布都是未正式启动

When a feature "fails," the most common diagnosis is not that the feature was wrong. It is that the launch was incomplete. Sales did not know. Customers were not told. Support could not help. The metric did not move because the launch did not reach the people who would have moved it.
Before declaring a feature failed, audit the launch against this playbook. Half the time the feature was fine; the launch never happened.
The discipline of separating shipping from releasing from launching is the single most useful PM vocabulary upgrade. Use it explicitly. Use it in stand-ups, in roadmap reviews, in launch retrospectives. The team that uses precise language about what has happened catches unlaunched features before declaring them failed and reallocates the engineering investment toward features that would actually capture value.
When in doubt about whether a launch is ready, ask: is the launch brief written and distributed? Has sales seen the battlecard? Does support have the FAQ? Is the rollout strategy chosen and the rollback trigger defined? Are the comms gated on a health check? Is the measurement plan tied to the spec hypotheses?
If any of those answers is no, the launch is not ready. Delaying the launch by a week to close the gaps is cheaper than launching incomplete and capturing a fraction of the value the feature could have delivered.
当一个“功能失败”时，最常见的原因并非功能本身错误，而是发布流程不完整。销售不知道，客户没收到通知，客服无法提供支持，指标毫无变化是因为发布未触达能带来价值的用户。
在宣布功能失败前，对照本手册审计发布流程。半数情况下，功能本身没问题，只是从未真正启动。
区分交付、发布与正式启动的规范，是PM最有用的术语升级。需明确使用，在站会、roadmap评审、发布回顾中使用。使用精准术语的团队能在宣布功能失败前发现未正式启动的问题，并重新分配工程资源到能真正获取价值的功能上。
不确定发布是否准备就绪时，问自己：启动简报是否撰写并分发？销售是否看过战斗卡片？客服是否有FAQ？是否选定了发布策略并定义了回滚触发条件？沟通是否以健康检查为前提？度量计划是否绑定规格假设？
如果任何一个问题的答案是否，那么发布尚未准备就绪。推迟一周发布以填补缺口，比仓促发布仅获取功能潜在价值的一小部分更划算。