SaaS
Rilasci ogni due settimane e ne scrivi due volte l'anno
I team software non mancano di cose da dire. Manca la persona che le dice, perché la scrittura è sempre il compito che viene spostato quando il rilascio è in ritardo — e viene spostato ogni volta, finché il post più recente del blog ha undici mesi e dice "presentiamo".
Il fallimento è strutturale, non editoriale
Ogni team sa che dovrebbe scrivere di più. Gli ingegneri sanno scrivere; il fondatore sa scrivere; di solito a qualcuno piace. Il problema è che la scrittura non ha una scadenza propria, e tutto ciò che non ha scadenza perde contro tutto ciò che ne ha una, ogni due settimane, per sempre.
Un piano fornisce la scadenza mancante. Uno slot datato con un tema e uno scrittore assegnati è un impegno preso in una settimana tranquilla, applicato in una settimana che non lo è, e la bozza appare che qualcuno se ne sia ricordato o no. Approvarla richiede minuti; scriverla da zero richiede un pomeriggio che non arriva mai.
Questo è l'intero argomento. Non è che un modello scriva meglio del tuo team — non lo fa. È che una bozza che modifichi di martedì esiste, e un post che intendevi scrivere no.
Una roadmap è un piano che hai già scritto
Gran parte dei sei mesi è già decisa. Sai più o meno cosa uscirà nei prossimi due trimestri, quali parti del prodotto sono fraintese, quali integrazioni ti vengono chieste continuamente e quali domande arrivano in supporto ogni singola settimana.
Ognuna di queste è un tema. La roadmap fornisce la cadenza — un rilascio diventa una serie di slot anziché una voce nel changelog — e il supporto fornisce la metà evergreen, perché una domanda posta venti volte al mese è un contenuto che vale la pena scrivere una volta e linkare per sempre.
Lascia spazi vuoti. I rilasci slittano, e un piano senza slot liberi trasforma un rilascio slittato in tre post su una cosa che non esiste ancora. Un quarto degli slot lasciato aperto non è pigrizia; è la parte del piano che sopravvive al contatto con il tuo calendario reale.
- 1BlogCosa è stato rilasciato e perché esiste. Prima il problema, poi la funzionalità.
- 2Facebook / InstagramLa versione in una frase, per chi non aprirà mai un changelog.
- 3BlogCome qualcuno l'ha davvero usato. Concreto, con le parti scomode lasciate dentro.
- ·Se slittaGli slot si muovono con la release. Nulla annuncia una cosa che non esiste.
- 4BlogLa domanda di assistenza che questa release risponde finalmente, scritta una volta sola.
La roadmap fissa la cadenzaL'assistenza fissa i temi
Il tuo changelog non è contenuto. È una ricevuta.
Due scrittori, a volte tre
Quello che spiega il prodotto, e quello che parla dell'azienda
Sono davvero due voci diverse, e fonderle produce quella particolare banalità per cui sono noti i blog sul software — un post che non è né una spiegazione tecnica né il racconto umano di qualcosa.
Il redattore tecnico
Spiega cosa fa una cosa, con precisione, senza aggettivi. Sa per cosa il tuo prodotto è e non è adatto, e gli è permesso dirlo. È il redattore i cui post vengono linkati dai ticket di assistenza.
La voce aziendale
Scrive di decisioni, compromessi e di ciò verso cui stai costruendo. Utile in un modo difficile da misurare ed evidente nelle assunzioni, nelle chiamate di vendita e nel motivo per cui qualcuno sceglie un piccolo fornitore invece di uno grande.
Chi risponde
Gestisce i commenti secondo la tua policy. Risponde a ciò che può, segnala ciò che non può, e non fa mai speculazioni sulla roadmap. Qualsiasi cosa somigli a un incidente di assistenza va subito a una persona.
Il cancello di approvazione qui sta facendo un lavoro vero
Per una panetteria, un post non approvato è una piccola figuraccia. Per un'azienda di software è un carico di assistenza, un'obiezione di vendita, o un impegno che nessuno ha accettato. Una bozza che descrive leggermente male un limite ti verrà riportata alla lettera da un cliente, e una bozza che accenna a una data sarà trattata come una promessa.
Quindi questo è il caso in cui il pilota automatico merita la massima cautela. Un accordo ragionevole è il pilota automatico sugli slot social brevi che ripetono qualcosa di già pubblicato, e l'approvazione su tutto ciò che fa un'affermazione sul prodotto. Qualsiasi cosa su prezzi, capacità o date dovrebbe essere letta da una persona in permanenza, e vale la pena scriverlo nelle regole del redattore, così che le bozze di quel tipo vengano trattenute e segnalate invece che messe in coda.
Cosa dice il report a un piccolo team
Pianificato rispetto a pubblicato è il numero che conta, e per un team di software di solito è scomodo nel primo trimestre. È anche l'unica misura onesta di se la scrittura ha smesso di perdere contro la release.
L'accoglienza conta meno di quanto sembri. Un pezzo tecnico trova il suo pubblico in mesi, non in giorni, e giudicarlo alla seconda settimana ti farà ritirare i pezzi che avrebbero funzionato. L'equilibrio dei temi è più utile all'inizio: mostra se scrivi solo di ciò che è stato rilasciato, che è la modalità di guasto standard e il motivo per cui così tanti blog sul software sembrano un changelog con i paragrafi.
La parte onesta: se il tuo prodotto è davvero tecnico, i pezzi più profondi hanno ancora bisogno di un ingegnere per un pomeriggio. Ciò che cambia con un piano è che quei pomeriggi vengono messi in calendario e l'altro ottanta per cento della scrittura smette di farsi concorrenza con loro.