SaaS
Lanças versões a cada duas semanas e escreves sobre isso duas vezes por ano
As equipas de software não têm falta de coisas para dizer. Têm falta da pessoa que as diz, porque escrever é sempre a tarefa que é adiada quando o lançamento atrasa — e é adiada todas as vezes, até que a publicação mais recente do blog tenha onze meses e diga "apresentamos".
A falha é estrutural, não editorial
Toda a equipa sabe que devia escrever mais. Os engenheiros sabem escrever; o fundador sabe escrever; normalmente há alguém que gosta. O problema é que escrever não tem prazo próprio, e tudo o que não tem prazo perde para tudo o que tem, a cada duas semanas, para sempre.
Um plano fornece o prazo que falta. Um espaço datado com um tema e um escritor associados é um compromisso feito numa semana calma, aplicado numa semana que não é calma, e o rascunho aparece quer alguém se lembre quer não. Aprová-lo leva minutos; escrevê-lo do zero leva uma tarde que nunca chega.
Esse é todo o argumento. Não é que um modelo escreva melhor do que a tua equipa — não escreve. É que um rascunho que editas na terça-feira existe, e uma publicação que tinhas intenção de escrever não.
Um roadmap é um plano que já escreveste
A maior parte dos seis meses já está decidida. Sabes aproximadamente o que sai nos próximos dois trimestres, que partes do produto são mal compreendidas, que integrações te são pedidas repetidamente e que questões chegam ao suporte todas as semanas.
Cada uma dessas coisas é um tema. O roadmap fornece a cadência — um lançamento torna-se uma sequência de espaços em vez de uma única entrada no changelog — e o suporte fornece a metade perene, porque uma pergunta feita vinte vezes por mês é uma peça que vale a pena escrever uma vez e ligar para sempre.
Deixa espaços em branco. Os lançamentos atrasam-se, e um plano sem espaços vazios transforma um lançamento atrasado em três artigos sobre uma coisa que ainda não existe. Um quarto dos espaços deixado em aberto não é folga; é a parte do plano que sobrevive ao contacto com o teu calendário real.
- 1BlogueO que foi lançado e por que razão existe. Primeiro o problema, depois a funcionalidade.
- 2Facebook / InstagramA versão numa frase, para quem nunca vai abrir um changelog.
- 3BlogueComo alguém realmente o usou. Concreto, com as partes desconfortáveis incluídas.
- ·Se se atrasarOs espaços movem-se com o lançamento. Nada anuncia uma coisa que não existe.
- 4BlogueA pergunta de suporte que este lançamento finalmente responde, escrita uma única vez.
O roadmap define a cadênciaO suporte define os temas
O teu changelog não é conteúdo. É um recibo.
Dois escritores, às vezes três
O que explica o produto, e o que fala da empresa
São genuinamente vozes diferentes, e fundi-las produz aquela particular insipidez pela qual os blogs de software são conhecidos — um artigo que não é nem uma explicação técnica nem um relato humano de coisa alguma.
O escritor técnico
Explica o que uma coisa faz, com precisão, sem adjetivos. Sabe para que serve o teu produto e para que não serve, e tem licença para o dizer. É o escritor cujos artigos são ligados a partir de tickets de suporte.
A voz da empresa
Escreve sobre decisões, compromissos e o que estás a construir. Útil de uma forma difícil de medir e óbvia nas contratações, nas reuniões de vendas e na razão pela qual alguém escolhe um fornecedor pequeno em vez de um grande.
O que responde
Trata dos comentários segundo a tua política. Responde ao que pode, sinaliza o que não pode e nunca especula sobre um roadmap. Qualquer coisa que se pareça com um incidente de suporte vai imediatamente para uma pessoa.
O portão de aprovação está a fazer um trabalho real aqui
Para uma padaria, um artigo não aprovado é um pequeno embaraço. Para uma empresa de software é uma carga de suporte, uma objeção de vendas ou um compromisso que ninguém aceitou. Um rascunho que descreva um limite ligeiramente errado será citado de volta por um cliente, e um rascunho que insinue uma data será tratado como uma promessa.
Por isso este é o caso em que o piloto automático merece mais cautela. Um arranjo razoável é piloto automático nos espaços sociais curtos que reafirmam algo já publicado, e aprovação em tudo o que faz uma afirmação sobre o produto. Qualquer coisa sobre preços, capacidade ou datas deve ser lida por uma pessoa permanentemente, e vale a pena escrever isso nas regras do escritor, para que rascunhos desse tipo sejam retidos e sinalizados em vez de ficarem em fila.
O que o relatório diz a uma equipa pequena
Planeado versus publicado é o número que importa, e para uma equipa de software costuma ser desconfortável no primeiro trimestre. É também a única medida honesta de se a escrita deixou de perder para o lançamento.
A receção importa menos do que parece. Uma peça técnica encontra o seu público ao longo de meses, não de dias, e julgá-la na segunda semana far-te-á abandonar os artigos que iam funcionar. O equilíbrio de temas é mais útil no início: mostra se só estás a escrever sobre o que foi lançado, que é o modo de falha padrão e a razão pela qual tantos blogs de software parecem um changelog com parágrafos.
A parte honesta: se o teu produto é genuinamente técnico, as peças mais profundas ainda precisam de um engenheiro durante uma tarde. O que um plano muda é que essas tardes passam a ser agendadas e os outros oitenta por cento da escrita deixam de competir com elas.