Autor techniczny
Tłumaczy, co coś robi, precyzyjnie i bez przymiotników. Wie, do czego Twój produkt jest, a do czego nie jest, i wolno mu to powiedzieć. To jego wpisy linkuje się potem ze zgłoszeń do wsparcia.
SaaS
Wydajesz co dwa tygodnie,a piszesz o tymdwa razy w roku.
Zespołom software'owym nie brakuje tematów. Brakuje im osoby, która je opisze, bo pisanie zawsze jest tym zadaniem, które wypada, gdy wydanie się opóźnia — i wypada za każdym razem, aż najnowszy wpis na blogu ma jedenaście miesięcy i zaczyna się od słowa „przedstawiamy”.
Ta porażka jest strukturalna,
nie redakcyjna.
Każdy zespół wie, że powinien pisać więcej. Programiści umieją pisać, założyciel umie pisać, ktoś zwykle nawet to lubi. Problem polega na tym, że pisanie nie ma własnego terminu, a cokolwiek bez terminu przegrywa z czymkolwiek z terminem — co dwa tygodnie, w nieskończoność.
Plan dostarcza brakujący termin. Datowany slot z tematem i autorem to zobowiązanie podjęte w spokojnym tygodniu, zastosowane w tygodniu, który spokojny nie jest — a szkic pojawia się niezależnie od tego, czy ktoś pamiętał. Zatwierdzenie zajmuje minuty; napisanie od zera zajmuje popołudnie, które nigdy nie nadchodzi.
To cały argument. Nie chodzi o to, że model pisze lepiej niż Twój zespół — nie pisze. Chodzi o to, że szkic, który redagujesz we wtorek, istnieje, a wpis, który zamierzałeś napisać, nie.
Roadmapa to plan,
który już napisałeś.
Większość tych sześciu miesięcy jest już zdecydowana. Wiesz z grubsza, co wychodzi w kolejnych dwóch kwartałach, które części produktu są źle rozumiane, o które integracje ciągle Cię pytają i jakie pytania przychodzą do wsparcia co tydzień.
Każde z tych to temat. Roadmapa daje rytm — wydanie staje się serią slotów, a nie jednym wpisem w changelogu — a wsparcie daje drugą, ponadczasową połowę, bo pytanie zadawane dwadzieścia razy w miesiącu warto opisać raz i linkować do niego na zawsze.
Zostawiaj luki. Wydania się przesuwają, a plan bez pustych slotów zamienia opóźnione wydanie w trzy wpisy o czymś, czego jeszcze nie ma. Jedna czwarta slotów zostawiona wolna to nie luz — to ta część planu, która przeżywa kontakt z Twoim realnym harmonogramem.
Jedno wydanie, trzy wpisyIlustracja
- 1BlogCo wyszło i po co istnieje. Najpierw problem, potem funkcja.
- 2Facebook / InstagramWersja na jedno zdanie, dla tych, którzy nigdy nie otworzą changelogu.
- 3BlogJak ktoś naprawdę tego użył. Konkretnie, z niewygodnymi fragmentami.
- ·Jeśli się przesunieSloty jadą razem z wydaniem. Nic nie ogłasza czegoś, czego nie ma.
- 4BlogPytanie ze wsparcia, na które to wydanie wreszcie odpowiada. Napisane raz.
Roadmapa ustawia rytmWsparcie ustawia tematy
Twój changelog to nie treść.
To paragon.
Dwóch autorów, czasem trzech
Ten, który tłumaczy produkt,
i ten, który mówi o firmie.
To naprawdę różne głosy, a ich sklejenie daje ten charakterystyczny bezsmak, z którego znane są blogi firm software'owych — wpis, który nie jest ani wyjaśnieniem technicznym, ani ludzką opowieścią o czymkolwiek.
Głos firmy
Pisze o decyzjach, kompromisach i o tym, dokąd zmierzacie. Użyteczny w sposób trudny do zmierzenia i oczywisty w rekrutacji, w rozmowach sprzedażowych i w powodzie, dla którego ktokolwiek wybiera małego dostawcę zamiast dużego.
Ten, który ogłasza
Pisze krótkie wpisy wskazujące na wydanie, na Facebooku i Instagramie: jedno zdanie, jedno zdjęcie. Gdy ktoś je skomentuje, pisze odpowiedzi w skrzynce FABLS; wysyła je właściciel albo menedżer z Twojego zespołu, a skarga albo potencjalny klient zawsze na jednego z nich czeka.
Bramka zatwierdzania
robi tu realną robotę.
Dla piekarni niezatwierdzony wpis to drobne zażenowanie. Dla firmy software'owej to obciążenie wsparcia, obiekcja w sprzedaży albo zobowiązanie, na które nikt się nie zgodził. Szkic, który odrobinę źle opisze limit, zostanie Ci zacytowany przez klienta, a szkic sugerujący datę zostanie potraktowany jak obietnica.
To więc przypadek, w którym autopilot zasługuje na największą ostrożność. Rozsądny układ to autopilot na kanale, który tylko powtarza to, co już opublikowane, i zatwierdzanie na każdym kanale, który stawia tezy o produkcie. Cokolwiek o cenach, wydajności czy terminach powinno na stałe przechodzić przez człowieka — i po to są uwagi przy każdym szkicu: autor wypisuje, co człowiek powinien sprawdzić.
Co raport mówi małemu zespołowi
Liczy się zestawienie planu z publikacjami i dla zespołu software'owego bywa ono w pierwszym kwartale niewygodne. Jest też jedyną uczciwą miarą tego, czy pisanie przestało znowu przegrywać z wydaniem.
Odbiór znaczy mniej, niż się wydaje. Tekst techniczny znajduje swoją publiczność przez miesiące, nie przez dni, a ocenianie go w drugim tygodniu skłoni Cię do wycofania właśnie tych, które miały zadziałać. Wcześniej bardziej przydaje się kalendarz planu: jedno spojrzenie pokazuje, czy piszesz wyłącznie o tym, co wyszło — to standardowy tryb awarii i powód, dla którego tyle blogów firm software'owych czyta się jak changelog z akapitami.
Uczciwie: jeśli Twój produkt jest naprawdę techniczny, najgłębsze teksty i tak wymagają programisty na popołudnie. Plan zmienia to, że te popołudnia są zaplanowane, a pozostałe osiemdziesiąt procent pisania przestaje z nimi konkurować.
Jak działa sezonowość i luki