SaaS
Du släpper varannan vecka och skriver om det två gånger om året
Mjukvaruteam saknar inte saker att säga. De saknar personen som säger dem, för skrivandet är alltid den uppgift som flyttas när releasen försenas — och den flyttas varje gång, tills bloggens senaste inlägg är elva månader gammalt och säger "vi introducerar".
Felet är strukturellt, inte redaktionellt
Varje team vet att det borde skriva mer. Ingenjörerna kan skriva; grundaren kan skriva; någon brukar tycka det är roligt. Problemet är att skrivandet har ingen egen deadline, och allt utan deadline förlorar mot allt med en, varannan vecka, för alltid.
En plan levererar den saknade deadlinen. En tidsatt tid med tema och skribent kopplad är ett löfte som gjordes en lugn vecka och verkställs en vecka som inte är lugn, och utkastet dyker upp oavsett om någon kom ihåg det. Att godkänna det tar minuter; att skriva det från noll tar en eftermiddag som aldrig kommer.
Det är hela argumentet. Det är inte att en modell skriver bättre än ditt team — det gör den inte. Det är att ett utkast du redigerar på tisdagen finns, medan ett inlägg du tänkte skriva inte gör det.
En färdplan är en plan du redan har skrivit
Större delen av sex månader är redan bestämd. Du vet ungefär vad som släpps under de kommande två kvartalen, vilka delar av produkten som missförstås, vilka integrationer du ständigt efterfrågas om och vilka frågor som kommer in till supporten varje vecka.
Vart och ett av dem är ett tema. Roadmappen ger takten — en release blir en rad platser i stället för en enda changelog-post — och supporten ger den ständigt aktuella halvan, för en fråga som ställs tjugo gånger i månaden är en text värd att skriva en gång och länka till för alltid.
Lämna luckor. Releaser försenas, och en plan utan tomma platser gör att en försenad release blir tre inlägg om något som inte finns ännu. Ett kvartal av platserna lämnat öppet är inte slöhet; det är den del av planen som överlever mötet med ditt verkliga schema.
- 1BloggVad som släpptes och varför det finns. Problemet först, funktionen sedan.
- 2Facebook / InstagramVersionen i en mening, för dem som aldrig öppnar en changelog.
- 3BloggHur någon faktiskt använde den. Konkret, med de besvärliga delarna kvar.
- ·Om den försenasPlatserna flyttas med releasen. Inget annonserar något som inte finns.
- 4BloggSupportfrågan som den här releasen äntligen besvarar, skriven en gång.
Roadmappen sätter taktenSupporten sätter temana
Din changelog är inte innehåll. Det är ett kvitto.
Två skribenter, ibland tre
Den som förklarar produkten, och den som pratar om företaget
Det är genuint olika röster, och att slå ihop dem ger den särskilda tråkighet som mjukvarubloggar är kända för — ett inlägg som varken är en teknisk förklaring eller en mänsklig berättelse om något.
Den tekniska skribenten
Förklarar vad något gör, precist, utan adjektiv. Vet vad din produkt är till för och inte till för, och får säga det. Det är skribenten vars inlägg länkas till från supportärenden.
Företagsrösten
Skriver om beslut, avvägningar och vad ni bygger mot. Användbar på ett sätt som är svårt att mäta men uppenbart i rekrytering, i säljmöten och i skälet till att någon väljer en liten leverantör framför en stor.
Den som svarar
Hanterar kommentarer enligt din policy. Svarar på det den kan, flaggar det den inte kan, och spekulerar aldrig i en roadmap. Allt som liknar ett supportärende går direkt till en människa.
Godkännandespärren gör verkligt arbete här
För ett bageri är ett ogodkänt inlägg en liten pinsamhet. För ett mjukvaruföretag är det en supportbörda, ett säljinvändning eller ett åtagande ingen gått med på. Ett utkast som beskriver en begränsning lite fel citeras tillbaka till dig av en kund, och ett utkast som antyder ett datum behandlas som ett löfte.
Så det här är fallet där autopilot förtjänar störst försiktighet. En rimlig ordning är autopilot på de korta sociala platserna som upprepar något redan publicerat, och godkännande på allt som gör ett påstående om produkten. Allt om prissättning, kapacitet eller datum bör läsas av en människa permanent, och det är värt att skriva in det i skribentens regler så att utkast av det slaget hålls kvar och flaggas i stället för att köas.
Vad rapporten berättar för ett litet team
Planerat kontra publicerat är siffran som spelar roll, och för ett mjukvaruteam är den oftast obekväm under första kvartalet. Den är också det enda ärliga måttet på om skrivandet har slutat förlora mot releasen igen.
Mottagandet spelar mindre roll än det ser ut. En teknisk text hittar sin publik över månader, inte dagar, och att bedöma den i vecka två får dig att lägga ner just de texter som skulle fungera. Temabalansen är mer användbar tidigt: den visar om du bara skriver om det som släppts, vilket är standardsättet att misslyckas och skälet till att så många mjukvarubloggar läses som en changelog med stycken.
Det ärliga: om din produkt verkligen är teknisk behöver de djupaste texterna fortfarande en ingenjör en eftermiddag. Det en plan ändrar är att de eftermiddagarna blir schemalagda och att de andra åttio procenten av skrivandet slutar konkurrera med dem.