该怎样发布一条新功能公告（而不是悄无声息）
阅读约 1 分钟
大多数新功能公告，最后都死在了一个没人会读第二遍的渠道里：一条一晃而过就消失的推文，一封被那一周订阅者收到的另外十二封邮件压在最底下的发布日邮件，一条发在半个团队几个月前就已经静音的频道里的 Slack 消息。功能确实已经发布了。可几乎没有一个本该会用它的人真正知道这件事。要解决这个问题，与其说是要写一份更好的公告，不如说更多是要为正确的读者选对正确的渠道，直接触达那些明确提出过这个请求的人，而不是指望她们会碰巧注意到一条通用消息。
一条新功能到底应该在哪里发布
不止一个地方，因为”所有人都读同一个渠道”这种情况从来都不成立。一条体验日志或者订阅源里的记录，服务的是那种按自己节奏来查看、想要一份永久保留且带日期的记录的读者。一条应用内提醒，服务的是那种已经在用这个产品、只要知道这个功能存在，今天就会去用它的读者。一封邮件，服务的是那种目前不在产品里、但只要更新内容对了就会回来的读者。社交媒体，服务的则是覆盖到现有用户之外的触达，只是几乎没有任何精准定向可言。
| 渠道 | 最适合的对象 | 弱点 |
|---|---|---|
| 体验日志 / 订阅源 | 永久性的记录；按自己节奏查看的读者 | 被动；对从来不主动查看的人毫无用处 |
| 应用内提醒 | 已经在使用、今天就会采取行动的用户 | 完全触达不到当下没有登录的人 |
| 邮件 | 目前不活跃、但会为此专门回来的用户 | 很容易被其他邮件淹没；需要一个真正有吸引力的标题 |
| 社交媒体 | 覆盖到现有用户之外的触达 | 几乎没有精准定向；生命周期很短 |
这四种渠道，单独拿出任何一种都不够用。体验日志是唯一一个不管发布内容大小、都理应承载每一次发布的文档，因为它是其他所有渠道最终都会回头去引用的那份记录；其余三种，只是在此基础上叠加上去的放大手段，具体要不要用，取决于这个功能实际上到底有多大。
公告应该先说什么
先说结果，而不是实现机制。“我们给报表接口加了一层缓存”描述的是团队具体做了什么。“报表现在能在一秒之内加载出来”描述的则是对读者来说到底发生了什么变化，而正是这句话能拿到点击，因为它在第一句话里就回答了”这跟我有什么关系”，而不是拖到第三句话才说。实现机制该放进体验日志记录或者详情页里，不该放在标题里。
具体的信息要排在形容词前面。“更快、更强大的报表体验”没有告诉读者任何她可以据此采取行动的东西；“报表现在能在一秒之内加载出来，还能按状态筛选”则准确说出了到底变了什么、值得去试试看什么。第二种写法读起来也更可信，因为一句含糊的断言，听起来就和没什么具体内容可说时的营销文案一模一样。
这和一封产品更新邮件到底有什么不同
两者有重叠，但并不完全等同。产品更新邮件专门讲解了邮件这个渠道，包括发送频率、标题写法，以及什么时候用摘要邮件会比单独发一封更好。一条新功能公告，是背后那个真正的事件本身；邮件只是上面四种渠道之一，当这个功能足够大、值得为它专门发一封邮件，而不是搭顺风车放进下一份摘要邮件里的时候，才会被选中。一个小功能，配得上一条体验日志记录，也许再加一条应用内提醒。一个重大功能，则配得上这全部四种渠道，而且要在时间上互相配合好。
该怎样触达那些真正提出过这个请求的人
这是投入产出比最高的一种公告方式，可几乎所有团队都会跳过它。如果有十个客户点名要求过某个功能，那这十个人就值得在功能发布的那一刻，得到一条直接、私人化的通知，跟外面正在发出的任何更广泛的公告都没有关系。闭环：从客户反馈到告知客户完整讲解了背后的机制；这里要说的重点是，这件事只有在原始请求始终和提出它的人保持关联的情况下才能真正生效，而这其实更像是一个追踪问题，而不是一个公告问题。在 changeloop 里，当小组件反馈变成了一个 GitHub issue，而合并的 pull request 关闭了它（fixes #142）时，批准这条体验日志记录就会在那个 issue 上发布一条只发一次的”Shipped —
记录本身该怎么写
和任何一条发布说明记录一样的自律：先从读者现在能做到的事情说起，接着补上必要的设置步骤，跳过内部理由的说明。如何写发布说明完整讲解了这套方法；一条新功能公告是其中风险最高的一种情况，因为它是最有可能被截图、被转发、被一个从来没见过这个产品体验日志的人读到的那种记录。
什么时候不该大范围发布公告
当这个功能还只是逐步向一部分账户推出、确实还是一个测试版，或者定价、访问权限的限制使得十个大范围公告的读者里有九个根本还用不上它的时候。对一个十个读者里有九个都还用不上的功能大范围发布公告，读起来就像一个诱饵，烧掉的对下一次公告的信任，比它在这一次带来的兴奋感还要多。解决办法不是保持沉默，而是控制范围：直接通知符合条件的账户，把大范围的渠道留到可用性真正追上公告内容的那一刻。
FAQ
是不是每一个新功能都值得拥有一条专属公告? 每一个都值得拥有一条体验日志记录。只有那些重要到足以改变别人使用这个产品方式的功能，或者是被点名明确要求过的功能，才值得动用邮件或社交媒体这样更广泛的渠道。
小功能最适合用哪个渠道? 只用体验日志就够了，如果这个功能能在用户本来就已经身处其中的流程里被自然发现，再加一条应用内提醒。邮件和社交媒体，值得留给那些配得上主动请求关注度的功能。
该怎样向那些明确提出过请求的人发布这条功能的公告? 从请求被记录下来的那一刻起，就让它始终和提出请求的人保持关联，等到发布时，再和任何更广泛的公告分开、单独通知她。一个提出请求的人自己就能查到的共享状态标签，也能从根本上减少一开始需要发送多少条单独的通知。
功能公告需要配一张截图吗? 只要是和视觉相关的功能，就需要；一个只有文字描述、却看不到实际效果的功能，被跳过的概率，会比一个读者能看到预览效果的功能高得多。如果是 API 或者后端能力，一段简短的代码示例，起到的作用就和 UI 变更配一张截图完全一样。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。