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