SaaS
Lliureu cada quinze dies i n'escriviu dues vegades l'any
Als equips de programari no els manquen coses per dir. Els falta la persona que les digui, perquè escriure és sempre la tasca que es desplaça quan el llançament s'endarrereix — i es desplaça cada vegada, fins que l'entrada més recent del blog té onze mesos i diu «presentem».
El fracàs és estructural, no editorial
Cada equip sap que hauria d'escriure més. Els enginyers saben escriure; el fundador sap escriure; normalment a algú li agrada. El problema és que escriure no té un termini propi, i qualsevol cosa sense termini perd contra qualsevol cosa amb un, cada quinze dies, per sempre.
Un pla aporta el termini que falta. Una casella datada amb un tema i un escriptor assignats és un compromís pres en una setmana tranquil·la, aplicat en una setmana que no ho és, i l'esborrany apareix tant si algú se'n recorda com si no. Aprovar-lo triga minuts; escriure'l des de zero triga una tarda que mai arriba.
Aquest és tot l'argument. No és que un model escrigui millor que el vostre equip — no ho fa. És que un esborrany que editeu dimarts existeix, i una entrada que teníeu intenció d'escriure no.
Una fulla de ruta és un pla que ja heu escrit
La majoria dels sis mesos ja està decidida. Sabeu més o menys què es llançarà els propers dos trimestres, quines parts del producte s'entenen malament, quines integracions us demanen constantment i quines preguntes arriben al suport cada setmana.
Cadascuna d'aquestes és un tema. La fulla de ruta aporta la cadència — un llançament es converteix en una sèrie de caselles en lloc d'una sola entrada al registre de canvis — i el suport aporta la meitat perenne, perquè una pregunta feta vint vegades al mes és una peça que val la pena escriure una vegada i enllaçar per sempre.
Deixeu buits. Els llançaments s'endarrereixen, i un pla sense caselles buides converteix un llançament endarrerit en tres entrades sobre una cosa que encara no existeix. Una quarta part de les caselles buides no és mandra; és la part del pla que sobreviu al contacte amb el vostre calendari real.
- 1BlogQuè s'ha llançat i per què existeix. Primer el problema, després la funció.
- 2Facebook / InstagramLa versió d'una frase, per a la gent que mai obrirà un registre de canvis.
- 3BlogCom l'ha fet servir algú de veritat. Concret, amb les parts incòmodes deixades-hi.
- ·Si s'endarrereixLes franges es mouen amb el llançament. Res no anuncia una cosa que no existeix.
- 4BlogLa pregunta de suport que aquest llançament finalment respon, escrita una sola vegada.
La fulla de ruta marca el ritmeEl suport marca els temes

El teu registre de canvis no és contingut. És un rebut.
Dos escriptors, a vegades tres
El que explica el producte, i el que parla de l'empresa
Són veus genuïnament diferents, i fusionar-les produeix aquella insipidesa tan coneguda dels blogs de programari: una entrada que no és ni una explicació tècnica ni un relat humà de res.
L'escriptor tècnic
Explica què fa una cosa, amb precisió i sense adjectius. Sap per a què serveix el teu producte i per a què no, i se li permet dir-ho. És l'escriptor les entrades del qual s'enllacen des dels tiquets de suport.
La veu de l'empresa
Escriu sobre decisions, compromisos i cap a què esteu construint. Útil d'una manera difícil de mesurar i evident en la contractació, en les trucades de vendes i en el motiu pel qual algú tria un proveïdor petit en lloc d'un gran.
El que respon
Gestiona els comentaris sota la teva política. Respon el que pot, senyalitza el que no pot, i mai especula sobre la fulla de ruta. Qualsevol cosa que s'assembli a una incidència de suport passa immediatament a una persona.
Aquí la porta d'aprovació fa una feina de veritat
Per a una fleca, una entrada no aprovada és una petita vergonya. Per a una empresa de programari és una càrrega de suport, una objecció de vendes, o un compromís que ningú ha acceptat. Un esborrany que descriu una limitació una mica malament et serà citat per un client, i un esborrany que insinua una data es tractarà com una promesa.
Per això aquest és el cas on el pilot automàtic mereix més precaució. Un arranjament raonable és pilot automàtic a les franges socials curtes que reiteren alguna cosa ja publicada, i aprovació per a tot el que fa una afirmació sobre el producte. Qualsevol cosa sobre preus, capacitat o dates hauria de ser llegida per una persona permanentment, i val la pena escriure-ho a les regles de l'escriptor perquè els esborranys d'aquest tipus es retinguin i se senyalitzin en lloc de posar-se a la cua.
Què diu l'informe a un equip petit
Planificat enfront de publicat és la xifra que compta, i per a un equip de programari sol ser incòmode el primer trimestre. També és l'única mesura honesta de si l'escriptura ha deixat de perdre contra el llançament.
L'acollida importa menys del que sembla. Una peça tècnica troba el seu públic al llarg de mesos, no de dies, i valorar-la a la segona setmana et farà retirar les peces que anaven a funcionar. L'equilibri de temes és més útil al principi: mostra si només escrius sobre el que s'ha llançat, que és el mode de fallada estàndard i el motiu pel qual tants blogs de programari es llegeixen com un registre de canvis amb paràgrafs.
La part honesta: si el teu producte és genuïnament tècnic, les peces més profundes encara necessiten un enginyer durant una tarda. El que canvia un pla és que aquestes tardes s'agenden i que el vuitanta per cent restant de l'escriptura deixi de competir-hi.