SaaS
Du leverer hver anden uge og skriver om det to gange om året
Softwareteams mangler ikke ting at sige. De mangler personen, der siger dem, fordi skrivning altid er den opgave, der rykker, når releasen er forsinket — og den rykker hver gang, indtil bloggens seneste indlæg er elleve måneder gammelt og siger "introducing".
Fejlen er strukturel, ikke redaktionel
Hvert team ved, at det burde skrive mere. Ingeniørerne kan skrive; stifteren kan skrive; som regel er der én, der synes, det er sjovt. Problemet er, at skrivning ikke har nogen deadline i sig selv, og alt uden deadline taber til alt med en — hver anden uge, for altid.
En plan leverer den manglende deadline. En dateret plads med et tema og en skribent knyttet til er en forpligtelse, der indgås i en rolig uge og anvendes i en uge, der ikke er rolig, og udkastet dukker op, uanset om nogen huskede det. At godkende det tager minutter; at skrive det fra bunden tager en eftermiddag, der aldrig kommer.
Det er hele argumentet. Det er ikke, at en model skriver bedre end dit team — det gør den ikke. Det er, at et udkast, du redigerer på tirsdag, findes, og et indlæg, du havde tænkt dig at skrive, gør ikke.
En roadmap er en plan, du allerede har skrevet
Det meste af de seks måneder er allerede besluttet. Du ved nogenlunde, hvad der leveres i de næste to kvartaler, hvilke dele af produktet der misforstås, hvilke integrationer du hele tiden bliver bedt om, og hvilke spørgsmål der kommer i support hver eneste uge.
Hvert af dem er et tema. Roadmappen leverer rytmen — en release bliver en række pladser i stedet for én changelog-post — og supporten leverer den eviggrønne halvdel, fordi et spørgsmål, der stilles tyve gange om måneden, er et stykke, der er værd at skrive én gang og linke til for altid.
Efterlad huller. Releases glider, og en plan uden tomme pladser forvandler en glidende release til tre indlæg om noget, der ikke findes endnu. En fjerdedel af pladserne holdt åben er ikke sløvhed; det er den del af planen, der overlever mødet med din faktiske kalender.
- 1BlogHvad der blev leveret, og hvorfor det findes. Problemet først, featuren bagefter.
- 2Facebook / InstagramVersionen i én sætning, til folk der aldrig åbner en changelog.
- 3BlogHvordan nogen faktisk brugte det. Konkret, med de akavede dele med.
- ·Hvis det gliderPladserne flytter sig med udgivelsen. Intet annoncerer noget, der ikke findes.
- 4BlogSupportspørgsmålet, som denne udgivelse endelig besvarer, skrevet én gang.
Roadmappen sætter rytmenSupporten sætter temaerne
Din changelog er ikke indhold. Den er en kvittering.
To skribenter, nogle gange tre
Én der forklarer produktet, og én der taler om virksomheden
Det er reelt to forskellige stemmer, og at blande dem giver den særlige fladhed, softwareblogs er kendt for — et indlæg, der hverken er en teknisk forklaring eller et menneskeligt beretning om noget.
Den tekniske skribent
Forklarer præcist, hvad noget gør, uden adjektiver. Ved, hvad dit produkt er til og ikke er til, og må sige det. Det er skribenten, hvis indlæg bliver linket til fra supporttickets.
Virksomhedsstemmen
Skriver om beslutninger, afvejninger og det, I bygger hen imod. Nyttig på en måde, der er svær at måle og tydelig i ansættelser, i salgsmøder og i grunden til, at nogen vælger en lille leverandør frem for en stor.
Den der svarer
Håndterer kommentarer under din politik. Svarer på det, den kan, markerer det, den ikke kan, og spekulerer aldrig i en roadmap. Alt, der ligner en supporthændelse, går straks videre til et menneske.
Godkendelsesporten gør rigtig arbejde her
For et bageri er et ugodkendt indlæg en lille pinlighed. For en softwarevirksomhed er det en supportbyrde, en salgsindvending eller et løfte, ingen har sagt ja til. Et udkast, der beskriver en grænse en smule forkert, bliver citeret tilbage til dig af en kunde, og et udkast, der antyder en dato, bliver behandlet som et løfte.
Så det her er tilfældet, hvor autopilot fortjener mest forsigtighed. En fornuftig ordning er autopilot på de korte sociale pladser, der gentager noget allerede udgivet, og godkendelse på alt, der fremsætter et påstand om produktet. Alt om priser, kapacitet eller datoer bør læses af et menneske permanent, og det er værd at skrive ind i skribentens regler, så udkast af den slags tilbageholdes og markeres i stedet for at stå i kø.
Hvad rapporten fortæller et lille team
Planlagt versus udgivet er det tal, der tæller, og for et softwareteam er det normalt ubehageligt i det første kvartal. Det er også det eneste ærlige mål for, om skrivningen er holdt op med at tabe til udgivelsen igen.
Modtagelsen betyder mindre, end den ser ud til. Et teknisk stykke finder sit publikum over måneder, ikke dage, og at bedømme det i uge to får dig til at skrotte de stykker, der ville virke. Temabalance er mere nyttig tidligt: Den viser, om du kun skriver om det, der er blevet udgivet, hvilket er standardsvigtet og grunden til, at så mange softwareblogs læses som en changelog med afsnit.
Det ærlige: hvis dit produkt reelt er teknisk, har de dybeste stykker stadig brug for en ingeniør en eftermiddag. Det, en plan ændrer, er, at de eftermiddage bliver planlagt, og at de andre firs procent af skrivningen holder op med at konkurrere med dem.