The technical writer
Explains what a thing does, precisely, without adjectives. Knows what your product is and is not for, and is allowed to say so. This is the writer whose posts get linked to from support tickets.
SaaS
You ship every fortnightand write about ittwice a year.
Software teams are not short of things to say. They are short of the person who says them, because writing is always the task that gets moved when the release is late — and it gets moved every time, until the blog's most recent post is eleven months old and says "introducing".
The failure is structural,
not editorial.
Every team knows it should write more. The engineers can write; the founder can write; somebody usually enjoys it. The problem is that writing has no deadline of its own, and anything without a deadline loses to anything with one, every fortnight, forever.
A plan supplies the missing deadline. A dated slot with a theme and a writer attached is a commitment made in a calm week, applied in a week that is not calm, and the draft appears whether or not anybody remembered. Approving it takes minutes; writing it from nothing takes an afternoon that never arrives.
That is the whole argument. It is not that a model writes better than your team — it does not. It is that a draft you edit on Tuesday exists, and a post you meant to write does not.
A roadmap is a plan
you already wrote.
Most of the six months is already decided. You know roughly what ships in the next two quarters, which parts of the product are misunderstood, which integrations you keep being asked for, and which questions arrive in support every single week.
Each of those is a theme. The roadmap supplies the cadence — a release becomes a run of slots rather than one changelog entry — and support supplies the evergreen half, because a question asked twenty times a month is a piece worth writing once and linking to forever.
Leave gaps. Releases slip, and a plan with no empty slots turns a slipped release into three posts about a thing that does not exist yet. A quarter of the slots left open is not slack; it is the part of the plan that survives contact with your actual schedule.
One release, three postsIllustration
- 1BlogWhat shipped and why it exists. The problem first, the feature second.
- 2Facebook / InstagramThe one-sentence version, for people who will never open a changelog.
- 3BlogHow somebody actually used it. Concrete, with the awkward parts left in.
- ·If it slipsThe slots move with the release. Nothing announces a thing that does not exist.
- 4BlogThe support question this release finally answers, written once.
The roadmap sets the cadenceSupport sets the themes
Your changelog is not content.
It is a receipt.
Two writers, sometimes three
The one who explains the product,
and the one who talks about the company.
Those are genuinely different voices, and merging them produces the particular blandness that software blogs are known for — a post that is neither a technical explanation nor a human account of anything.
The company voice
Writes about decisions, trade-offs and what you are building towards. Useful in a way that is hard to measure and obvious in hiring, in sales calls and in the reason anyone chooses a small vendor over a large one.
The one who announces
Writes the short posts that point at a release, on Facebook and Instagram: one sentence, one picture. When people comment under them, it drafts the replies in FABLS's inbox; an owner or a manager on your team sends them, and a complaint or a lead always waits for one of them.
The approval gate
is doing real work here.
For a bakery, an unapproved post is a small embarrassment. For a software company it is a support load, a sales objection, or a commitment nobody agreed to. A draft that describes a limit slightly wrongly will be quoted back to you by a customer, and a draft that hints at a date will be treated as a promise.
So this is the case where autopilot deserves the most caution. A reasonable arrangement is autopilot on a channel that only restates what is already published, and approval on every channel that makes claims about the product. Anything about pricing, capacity or dates should be read by a person permanently — which is what each draft's caveats are for: the writer lists what a person should check.
What the report tells a small team
Planned versus published is the number that matters, and for a software team it is usually uncomfortable in the first quarter. It is also the only honest measure of whether writing has stopped losing to the release again.
Reception matters less than it looks. A technical piece finds its audience over months, not days, and judging it in week two will make you retire the pieces that were going to work. The plan's calendar is more useful early: one look shows whether you are only ever writing about what shipped, which is the standard failure mode and the reason so many software blogs read like a changelog with paragraphs.
The honest bit: if your product is genuinely technical, the deepest pieces still need an engineer for an afternoon. What a plan changes is that those afternoons get scheduled and the other eighty per cent of the writing stops competing with them.
How seasonality and gaps work