SaaS
You release every two weeks and write about am two times every year
Software teams no lack wetin to talk. Dem lack di person wey go talk am, because writing na di task wey dem always push when release late — and dem push am every time, until di blog latest post reach eleven months old and e say "introducing".
Di failure na structural, no be about writing style
Every team know say dem suppose write more. Di engineers fit write; di founder fit write; somebody usually enjoy am. Di problem be say writing no get im own deadline, and anything wey no get deadline go lose to anything wey get one, every two weeks, forever.
Plan supply di deadline wey miss. Dated slot with topic and writer join na commitment wey dem make for calm week, apply for week wey no calm, and di draft go appear whether anybody remember or no remember. To approve am take minutes; to write am from nothing take afternoon wey no ever come.
Na di whole argument be dat. No be say model write pass your team — e no write pass. Na say draft wey you edit on Tuesday dey exist, and post wey you plan to write no dey.
Roadmap na plan wey you don already write
Most of di six months don already decide. You know small small wetin go release for di next two quarters, which part of di product people no understand well, which integrations dem dey always ask you for, and which questions dey come to support every single week.
Each of dem na one topic. Di roadmap supply di rhythm — one release become plenty slots instead of one changelog entry — and support supply di evergreen half, because question wey dem ask twenty times every month na piece wey worth am to write once and link to forever.
Leave space. Releases dey slip, and plan wey no get empty slot go turn one slipped release into three posts about thing wey no even exist yet. To leave one quarter of di slots open no be laziness; na di part of di plan wey survive when e meet your real schedule.
- 1BlogWetin dem ship and why e dey exist. Di problem first, di feature second.
- 2Facebook / InstagramDi one-sentence version, for people wey no go ever open changelog.
- 3BlogHow person really use am. Clear, with di awkward parts still inside.
- ·If e delayDi slots dey move with di release. Nothing go announce wetin no dey exist.
- 4BlogDi support question wey dis release don finally answer, written once.
Di roadmap dey set di cadenceSupport dey set di themes
Your changelog no be content. Na receipt.
Two writers, sometimes e fit be three
Di one wey explain di product, and di one wey dey talk about di company
Dem be two different voices truly, and if you merge dem you go get dat kain blandness wey software blogs sabi — one post wey no be technical explanation and no be human story at all.
Di technical writer
E explain wetin one thing dey do, sharp sharp, without adjectives. E know wetin your product dey for and wetin e no dey for, and dem allow am to talk am. Na dis writer posts dem dey link from support tickets.
Di company voice
E write about decisions, trade-offs and wetin una dey build go reach. E useful for one way wey hard to measure but e dey show for hiring, for sales calls, and for di reason why anybody go choose small vendor pass big one.
Di one wey dey answer
E handle comments under your policy. E answer wetin e fit, e flag wetin e no fit, and e no go ever guess about roadmap. Anything wey resemble support incident go straight to person immediately.
Di approval gate dey do real work here
For bakery, one post wey dem no approve na small shame. For software company na support load, sales objection, or commitment wey nobody agree to. Draft wey describe one limit small wrong go come back from customer mouth, and draft wey hint one date go be promise.
So na here autopilot suppose get di most caution. One sensible arrangement na autopilot on di short social slots wey dey repeat wetin don already publish, and approval on everything wey dey make claim about di product. Anything about pricing, capacity or dates, person suppose dey read am forever, and e good to write am inside di writer rules so drafts of dat kind go dey hold and flag, no be queue.
Wetin di report dey tell small team
Planned versus published na di number wey matter, and for software team e usually no sweet for first quarter. E still be di only honest measure of whether writing don stop to lose to di release again.
Reception no matter like e look. One technical piece dey find im audience over months, no be days, and if you judge am for week two you go drop di pieces wey suppose work. Di theme balance dey more useful early: e show whether na only wetin ship you dey write about, na di standard failure mode be dat and di reason why plenty software blogs dey read like changelog with paragraphs.
Di honest part: if your product really technical, di deepest pieces still need engineer for one afternoon. Wetin one plan change na say dem go schedule dose afternoons and di other eighty per cent of di writing go stop to compete with dem.