Jak ogłosić nową funkcję (bez ciszy)

Większość ogłoszeń funkcji umiera w kanale, którego nikt nie czyta dwa razy: tweet, który przewija się i znika, e-mail z dnia wydania pogrzebany pod dwunastoma innymi, które subskrybentka dostała tego tygodnia, wiadomość na Slacku w kanale, który połowa zespołu wyciszyła miesiące temu. Funkcja została wydana. Prawie nikt, kto by z niej skorzystał, o tym nie wiedział. Naprawienie tego ma mniej wspólnego z napisaniem lepszego ogłoszenia, a więcej z wybraniem właściwego kanału dla właściwej czytelniczki, i dotarciem bezpośrednio do tych, które wyraźnie o to poprosiły, zamiast liczyć, że zauważą ogólne ogłoszenie.

Gdzie naprawdę powinna być ogłaszana nowa funkcja?

W więcej niż jednym miejscu, bo “wszyscy czytają ten sam kanał” nigdy nie jest prawdą. Wpis w changelogu lub feedzie służy czytelniczce, która sprawdza we własnym rytmie i chce trwałego, datowanego zapisu. Powiadomienie w aplikacji służy czytelniczce, która już korzysta z produktu i skorzystałaby z funkcji dziś, gdyby wiedziała, że istnieje. E-mail służy czytelniczce, która obecnie nie jest w produkcie, ale wróciłaby dla właściwej aktualizacji. Media społecznościowe służą zasięgowi poza istniejącymi użytkowniczkami, niemal bez targetowania.

Żaden z czterech nie wystarczy sam. Changelog to jedyny dokument, który powinien nieść każde wydanie niezależnie od rozmiaru, bo to zapis, do którego odsyła wszystko inne; pozostałe trzy to wzmocnienie dołożone na wierzch, wybrane według tego, jak naprawdę duża jest funkcja.

Co ogłoszenie powinno powiedzieć najpierw?

Rezultat, nie mechanizm. “Dodaliśmy warstwę cache do endpointu raportów” opisuje, co zbudował zespół. “Raporty ładują się teraz w mniej niż sekundę” opisuje, co zmieniło się dla czytelniczki, i to zdanie zdobywa kliknięcie, bo odpowiada na “co ja z tego mam” w pierwszym zdaniu zamiast trzecim. Mechanizm należy do wpisu w changelogu lub strony ze szczegółami, nie do nagłówka.

Konkrety przed przymiotnikami. “Szybsze, bardziej wydajne doświadczenie raportów” nie mówi czytelniczce niczego, na czym mogłaby działać; “raporty ładują się teraz w mniej niż sekundę i można je filtrować według statusu” mówi dokładnie, co się zmieniło i co wypróbować. Druga wersja jest też bardziej wiarygodna, bo niejasne twierdzenie brzmi dokładnie tak, jak brzmi tekst marketingowy, gdy nie ma nic konkretnego do powiedzenia.

Czym różni się od e-maila z aktualizacją produktu?

Nakładają się, ale nie są identyczne. E-mail z aktualizacją produktu opisuje kanał e-mailowy szczegółowo, w tym częstotliwość, tematy, i kiedy digest bije pojedynczą wysyłkę. Ogłoszenie nowej funkcji to leżące u podstaw wydarzenie; e-mail to jeden z czterech kanałów powyżej, który mógłby je nieść, wybrany, gdy funkcja jest wystarczająco duża, żeby uzasadnić dedykowaną wysyłkę zamiast jechać w kolejnym digeście. Mała funkcja zasługuje na wpis w changelogu i może powiadomienie w aplikacji. Znacząca zasługuje na wszystkie cztery kanały, skoordynowane w czasie.

Jak dotrzeć do konkretnych osób, które o to poprosiły?

To ogłoszenie o najlepszym stosunku wysiłku do efektu, i prawie każdy zespół je pomija. Jeśli dziesięć klientek poprosiło o funkcję z nazwy, tych dziesięć osób zasługuje na bezpośrednią, osobistą notatkę w momencie wydania, niezależnie od jakiegokolwiek szerszego ogłoszenia, które wychodzi. Zamykanie pętli feedbacku z klientem opisuje mechanikę w całości; podsumowanie tutaj jest takie, że działa to tylko wtedy, gdy oryginalna prośba pozostała powiązana z osobą proszącą, co jest bardziej problemem śledzenia niż problemem ogłaszania. W changeloop, gdy feedback z widżetu stał się issue na GitHubie, a zmergowany pull request je zamyka (fixes #142), zatwierdzenie wpisu w changelogu publikuje na tym issue, jednorazowo, komentarz “Shipped —

Jak napisać sam wpis?

Ta sama dyscyplina co każdy inny wpis w notatkach wydania: zacznij od tego, co czytelniczka może teraz zrobić, kontynuuj potrzebną konfiguracją, pomiń wewnętrzne uzasadnienie. Jak pisać notatki wydania opisuje pełną metodę; ogłoszenie nowej funkcji to przypadek z najwyższą stawką, bo to wpis najbardziej narażony na zrzut ekranu, przekazanie dalej, i przeczytanie przez kogoś, kto nigdy nie widział changeloga produktu.

Kiedy nie należy ogłaszać szeroko?

Gdy funkcja jest wciąż wdrażana do podzbioru kont, jest naprawdę wersją beta, lub jest wyceniona albo zablokowana tak, że dziewięć na dziesięć czytelniczek szerokiego ogłoszenia nie mogłoby jej jeszcze użyć. Szerokie ogłoszenie funkcji, której dziewięć na dziesięć czytelniczek nie może użyć, czyta się jak przynęta, i wypala zaufanie do następnego ogłoszenia bardziej, niż buduje entuzjazm w tym. Rozwiązaniem nie jest cisza, tylko zasięg: bezpośrednio poinformuj uprawnione konta i wstrzymaj szerokie kanały, dopóki dostępność nie dogoni ogłoszenia.

FAQ

Czy każda nowa funkcja zasługuje na własne ogłoszenie? Każda zasługuje na wpis w changelogu. Tylko te wystarczająco znaczące, żeby zmienić, jak ktoś korzysta z produktu, lub wyraźnie zamówione z nazwy, zasługują na szersze kanały jak e-mail czy media społecznościowe.

Jaki jest najlepszy kanał dla małej funkcji? Sam changelog, plus powiadomienie w aplikacji, jeśli funkcja jest odkrywalna w przepływie, w którym użytkowniczka już się znajduje. E-mail i media społecznościowe opłacają się dla funkcji, które uzasadniają proszenie o uwagę.

Jak ogłosić funkcję osobom, które wyraźnie o to poprosiły? Trzymaj prośbę powiązaną z osobą proszącą od momentu zarejestrowania, potem powiadom indywidualnie przy wydaniu, oddzielnie od jakiegokolwiek szerszego ogłoszenia. Wspólna etykieta statusu, którą osoba proszącą może sama sprawdzić, zmniejsza też, ile indywidualnych wiadomości jest w ogóle potrzebnych.

Czy ogłoszenie funkcji potrzebuje zrzutu ekranu? Dla wszystkiego wizualnego, tak; funkcja opisana, ale niewidoczna, jest pomijana znacznie częściej niż taka, której podgląd mogą zobaczyć czytelniczki. Dla API lub zdolności backendowej krótki przykład kodu wykonuje tę samą pracę co zrzut ekranu przy zmianie UI.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Przykłady changeloga, Dokumentacja dla deweloperów