SaaS
Lansați la fiecare două săptămâni și scrieți despre asta de două ori pe an
Echipele de software nu rămân fără lucruri de spus. Le lipsește persoana care le spune, pentru că scrierea este mereu sarcina amânată când lansarea întârzie — și este amânată de fiecare dată, până când cea mai recentă postare de pe blog are unsprezece luni și începe cu „prezentăm”.
Eșecul este structural, nu editorial
Fiecare echipă știe că ar trebui să scrie mai mult. Inginerii pot scrie; fondatorul poate scrie; de obicei cuiva chiar îi place. Problema este că scrierea nu are un termen limită propriu, iar orice fără termen limită pierde în fața oricui are unul, la fiecare două săptămâni, la nesfârșit.
Un plan furnizează termenul limită lipsă. Un interval datat, cu o temă și un autor atașate, este un angajament luat într-o săptămână liniștită și respectat într-o săptămână agitată, iar schița apare indiferent dacă cineva și-a amintit sau nu. Aprobarea durează minute; scrierea de la zero durează un after-două care nu vine niciodată.
Acesta este întregul argument. Nu este că un model scrie mai bine decât echipa dumneavoastră — nu o face. Ci că o schiță pe care o editați marți există, iar o postare pe care intenționați să o scrieți nu.
O foaie de parcurs este un plan pe care deja l-ați scris
Cea mai mare parte a celor șase luni este deja decisă. Știți aproximativ ce se lansează în următoarele două trimestre, care părți ale produsului sunt greșit înțelese, ce integrări vi se cer încontinuu și ce întrebări ajung în suport în fiecare săptămână.
Fiecare dintre acestea este o temă. Foaia de parcurs furnizează ritmul — o lansare devine un șir de sloturi, nu o singură intrare în jurnalul de modificări — iar suportul furnizează jumătatea veșnic actuală, pentru că o întrebare pusă de douăzeci de ori pe lună este o piesă care merită scrisă o dată și legată pentru totdeauna.
Lăsați goluri. Lansările întârzie, iar un plan fără sloturi libere transformă o lansare întârziată în trei articole despre un lucru care nu există încă. Un sfert din sloturi lăsat deschis nu este lene; este partea planului care supraviețuiește întâlnirii cu programul dumneavoastră real.
- 1BlogCe s-a lansat și de ce există. Mai întâi problema, apoi funcționalitatea.
- 2Facebook / InstagramVersiunea într-o singură frază, pentru cei care nu vor deschide niciodată jurnalul de modificări.
- 3BlogCum a folosit-o efectiv cineva. Concret, cu părțile incomode lăsate pe loc.
- ·Dacă întârzieSloturile se mută odată cu lansarea. Nimic nu anunță un lucru care nu există.
- 4BlogÎntrebarea din suport la care această lansare răspunde în sfârșit, scrisă o singură dată.
Foaia de parcurs stabilește ritmulSuportul stabilește temele
Jurnalul dumneavoastră de modificări nu este conținut. Este o chitanță.
Doi autori, uneori trei
Cel care explică produsul și cel care vorbește despre companie
Acestea sunt cu adevărat voci diferite, iar contopirea lor produce acea blândețe specifică blogurilor de software — un articol care nu este nici o explicație tehnică, nici o relatare umană a vreunui lucru.
Autorul tehnic
Explică ce face un lucru, precis, fără adjective. Știe pentru ce este și pentru ce nu este produsul dumneavoastră și are voie să spună acest lucru. Este autorul ale cărui articole sunt legate din tichetele de suport.
Vocea companiei
Scrie despre decizii, compromisuri și spre ce construiți. Util într-un mod greu de măsurat, dar evident în recrutare, în apelurile de vânzări și în motivul pentru care cineva alege un furnizor mic în locul unuia mare.
Cel care răspunde
Gestionează comentariile conform politicii dumneavoastră. Răspunde la ce poate, semnalează ce nu poate și nu speculează niciodată despre foaia de parcurs. Orice seamănă cu un incident de suport ajunge imediat la o persoană.
Poarta de aprobare face aici o muncă reală
Pentru o brutărie, un articol neaprobat este o mică jenă. Pentru o companie de software este o sarcină de suport, o obiecție de vânzări sau un angajament pe care nimeni nu l-a acceptat. O ciornă care descrie ușor greșit o limită va fi citată înapoi de un client, iar o ciornă care sugerează o dată va fi tratată ca o promisiune.
De aceea acesta este cazul în care pilotul automat merită cea mai mare prudență. Un aranjament rezonabil este pilotul automat pe sloturile scurte de social media care reformulează ceva deja publicat, și aprobarea pentru tot ce face o afirmație despre produs. Orice ține de prețuri, capacitate sau date ar trebui citit permanent de o persoană, și merită scris acest lucru în regulile autorului, astfel încât ciornele de acest fel să fie reținute și semnalate, nu puse în coadă.
Ce îi spune raportul unei echipe mici
Planificat versus publicat este cifra care contează, iar pentru o echipă de software este de obicei inconfortabilă în primul trimestru. Este, de asemenea, singura măsurătoare onestă a faptului dacă scrierea a încetat din nou să piardă în fața lansării.
Recepția contează mai puțin decât pare. Un articol tehnic își găsește publicul în luni, nu în zile, iar judecarea lui în săptămâna a doua vă va face să retrageți piesele care urmau să funcționeze. Echilibrul temelor este mai util la început: arată dacă scrieți doar despre ce s-a lansat, ceea ce este modul standard de eșec și motivul pentru care atât de multe bloguri de software arată ca un jurnal de modificări cu paragrafe.
Partea onestă: dacă produsul dumneavoastră este cu adevărat tehnic, cele mai profunde piese mai au nevoie tot de un inginer pentru o după-amiază. Ce schimbă un plan este că acele după-amiezi ajung în program, iar restul de optzeci la sută din scriere nu mai concurează cu ele.