SaaS
你每两周发布一次，却半年才写一次
软件团队不缺可写的东西，缺的是那个动笔的人，因为写作永远是版本延期时最先被挪开的任务——而且每次都被挪开，直到博客最新一篇是十一个月前发的、标题还写着“隆重推出”。
这是结构性问题，不是编辑问题
每个团队都知道该多写。工程师会写，创始人会写，通常还有人乐在其中。问题在于写作没有自己的截止日期，而没有截止日期的事永远输给有截止日期的事，每两周一次，永无止境。
计划补上了缺失的截止日期。一个带日期、带主题、带写手的档期，是在从容的一周里做出的承诺，在不从容的那一周被执行，草稿无论有没有人记得都会出现。审核它只需几分钟；从零写一篇，则需要一个永远不会到来的下午。
这就是全部论证。并不是说模型写得比你的团队好——它并不。而是你在周二编辑过的草稿是存在的，而你打算写的那篇帖子不存在。
路线图就是你已经写好的计划
这六个月的大部分内容其实已经定了。你大致知道接下来两个季度会发布什么、产品的哪些部分被误解、哪些集成总被要求、哪些问题每周都会出现在支持工单里。
其中每一项都是一个主题。路线图提供节奏——一次发布变成一串档期，而不是一条更新日志——客服支持提供常青的那一半，因为一个月被问二十次的问题，值得写一次然后永久链接过去。
留出空档。发布总会延期，一个没有空档的计划会把一次延期变成三篇关于还不存在的东西的文章。四分之一的档期空着不是偷懒；那是计划里能扛住你真实日程的那一部分。
- 1博客发布了什么，为什么存在。先讲问题，再讲功能。
- 2Facebook / Instagram一句话版本，给那些永远不会打开更新日志的人。
- 3博客某个人实际怎么用它。具体，保留那些别扭的部分。
- ·如果延期了档期跟着发布走。没有任何东西会去宣布一个还不存在的东西。
- 4博客这次发布终于回答的那个客服问题，写一次就够了。
路线图定节奏客服定主题
你的更新日志不是内容。它是一张收据。
两个写手，有时三个
一个解释产品，一个讲述公司
这确实是两种不同的声音，把它们合并就会产生软件博客特有的那种平淡——一篇文章既不是技术讲解，也不是对任何事情的真人叙述。
技术写手
精确地解释一个东西做什么，不用形容词。知道你的产品适合什么、不适合什么，而且被允许说出来。这就是那种文章会被客服工单引用的写手。
公司声音
写决策、取舍，以及你们正在朝什么方向努力。它的用处难以量化，却在招聘、销售电话、以及任何人选择小供应商而非大供应商的理由中显而易见。
答疑者
按照你的政策处理评论。能答的答，不能答的标记出来，绝不猜测路线图。任何像客服事故的内容都立即转给真人。
审批关卡在这里真正起了作用
对一家面包店来说，一篇未经审批的文章只是小小的尴尬。对一家软件公司来说，它是一份客服负担、一个销售异议，或一个没人同意过的承诺。一篇把某个限制写得稍有偏差的草稿，会被客户原话引用回来；一篇暗示了日期的草稿，会被当成承诺。
所以这正是自动驾驶最需要谨慎的场景。一个合理的安排是：自动驾驶只负责那些复述已发布内容的短社交档期，而所有对产品做出断言的内容都要经过审批。任何涉及定价、容量或日期的内容，应该永远由真人阅读，而且值得把这一点写进写手的规则里，让这类草稿被扣下并标记，而不是直接进入队列。
这份报告告诉小团队什么
计划与已发布之比才是重要的数字，对软件团队来说，第一个季度它通常让人不舒服。它也是唯一诚实的衡量，能看出写作是否又输给了发布。
反响的重要性比看起来低。一篇技术文章是按月而不是按天找到它的读者的，在第二周就评判它，会让你砍掉那些本来会成功的文章。主题平衡在早期更有用：它能看出你是否只在写已发布的东西——这是标准的失败模式，也是那么多软件博客读起来像带段落的更新日志的原因。
诚实的那部分：如果你的产品确实技术性强，最深度的文章仍然需要一位工程师花一个下午。计划改变的是：这些下午会被排进日程，而其余百分之八十的写作不再和它们抢时间。