Come annunciare una nuova funzionalità (senza silenzio)

La maggior parte degli annunci di funzionalità muore in un canale che nessuno legge due volte: un tweet che scorre via, un’email del giorno del rilascio sepolta sotto le altre dodici ricevute da un’iscritta quella settimana, un messaggio Slack in un canale che metà del team ha silenziato mesi fa. La funzionalità è stata rilasciata. Quasi nessuno che l’avrebbe usata lo ha scoperto. Risolvere questo ha meno a che fare con lo scrivere un annuncio migliore e più con lo scegliere il canale giusto per la lettrice giusta, e raggiungere direttamente chi l’ha chiesta esplicitamente invece di contare sul fatto che noti un annuncio generico.

Dove dovrebbe essere annunciata davvero una nuova funzionalità?

In più di un posto, perché “tutti leggono lo stesso canale” non è mai vero. Una voce di changelog o feed serve la lettrice che controlla secondo i propri tempi e vuole il registro permanente e datato. Un avviso in-app serve la lettrice che sta già usando il prodotto e userebbe la funzionalità oggi stesso se sapesse che esiste. L’email serve la lettrice che non è attualmente nel prodotto ma tornerebbe per l’aggiornamento giusto. I social servono la copertura oltre le utenti esistenti, quasi senza targeting.

Nessuno dei quattro basta da solo. Il changelog è l’unico documento che dovrebbe portare ogni rilascio a prescindere dalla dimensione, perché è il registro a cui tutto il resto rimanda; gli altri tre sono amplificazione aggiunta sopra, scelta in base a quanto è davvero grande la funzionalità.

Cosa dovrebbe dire per primo l’annuncio?

Il risultato, non il meccanismo. “Abbiamo aggiunto un layer di cache all’endpoint dei report” descrive cosa ha costruito il team. “I report ora si caricano in meno di un secondo” descrive cosa è cambiato per la lettrice, ed è la frase che porta al click, perché risponde a “cosa ci guadagno” nella prima proposizione invece che nella terza. Il meccanismo appartiene alla voce di changelog o alla pagina di dettaglio, non al titolo.

Dati concreti prima degli aggettivi. “Un’esperienza report più veloce e potente” non dice alla lettrice nulla su cui agire; “i report ora si caricano in meno di un secondo e si possono filtrare per stato” le dice esattamente cosa è cambiato e cosa provare. La seconda versione risulta anche più credibile, perché un’affermazione vaga suona esattamente come suona il testo di marketing quando non c’è niente di concreto da dire.

In cosa differisce da un’email di aggiornamento prodotto?

Sovrapposti ma non identici. Email di aggiornamento prodotto copre il canale email nello specifico, inclusi cadenza, oggetti, e quando un digest batte un invio singolo. Un annuncio di nuova funzionalità è l’evento sottostante; l’email è uno dei quattro canali sopra che potrebbe portarlo, scelto quando la funzionalità è abbastanza grande da giustificare un invio dedicato invece di viaggiare nel prossimo digest. Una funzionalità piccola si guadagna una voce di changelog e forse un avviso in-app. Una significativa si guadagna tutti e quattro i canali, coordinati nel tempo.

Come si raggiungono le persone specifiche che l’hanno chiesta?

Questo è l’annuncio con il miglior rapporto tra sforzo e risultato, e quasi tutti i team lo saltano. Se dieci clienti hanno chiesto una funzionalità per nome, quelle dieci persone meritano una nota diretta e personale nel momento in cui viene rilasciata, indipendentemente da qualsiasi annuncio più ampio in uscita. Chiudere il ciclo di feedback con il cliente copre la meccanica per intero; il riassunto qui è che funziona solo se la richiesta originale è rimasta collegata a chi l’ha fatta, che è più un problema di tracciamento che un problema di annuncio. In changeloop, quando un feedback dal widget è diventato un issue GitHub e la pull request mergiata lo chiude (fixes #142), approvare la voce di changelog pubblica su quell’issue il commento “Shipped —

Come si scrive la voce stessa?

La stessa disciplina di qualsiasi altra voce di note di rilascio: iniziare con cosa può fare ora chi legge, seguire con la configurazione necessaria, saltare la giustificazione interna. Come scrivere note di rilascio copre il metodo completo; un annuncio di nuova funzionalità è il caso con la posta più alta, perché è la voce con più probabilità di essere catturata in uno screenshot, inoltrata, e letta da chi non ha mai visto il changelog del prodotto.

Quando non conviene annunciare ampiamente?

Quando la funzionalità è ancora in rollout verso un sottoinsieme di account, è davvero una beta, o ha un prezzo o un blocco tale che nove lettrici su dieci di un annuncio ampio non potrebbero ancora usarla. Un annuncio ampio per una funzionalità che nove lettrici su dieci non possono usare si legge come un’esca, e brucia la fiducia nel prossimo annuncio più di quanto costruisca entusiasmo in questo. La soluzione non è il silenzio, è la portata: informare direttamente gli account idonei e trattenere i canali ampi finché la disponibilità non raggiunge l’annuncio.

FAQ

Ogni nuova funzionalità merita il proprio annuncio? Ognuna si guadagna una voce di changelog. Solo quelle abbastanza significative da cambiare come qualcuno usa il prodotto, o quelle chieste esplicitamente per nome, si guadagnano i canali più ampi come email o social.

Qual è il canale migliore per una funzionalità piccola? Solo il changelog, più un avviso in-app se la funzionalità è scopribile dentro un flusso in cui l’utente si trova già. Email e social valgono la pena per funzionalità che giustificano il chiedere attenzione.

Come si annuncia una funzionalità alle persone che l’hanno specificamente chiesta? Mantenere la richiesta collegata a chi l’ha fatta dal momento in cui viene registrata, poi notificare individualmente al rilascio, separatamente da qualsiasi annuncio più ampio. Un’etichetta di stato condivisa che chi ha chiesto può controllare da solo riduce anche quanti messaggi individuali servono in primo luogo.

Un annuncio di funzionalità ha bisogno di uno screenshot? Per qualsiasi cosa visiva, sì; una funzionalità descritta ma non vista viene saltata molto più spesso di una di cui le lettrici possono vedere un’anteprima. Per un’API o una capacità backend, un breve esempio di codice svolge lo stesso lavoro di uno screenshot per un cambiamento UI.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Esempi di changelog, Documentazione per sviluppatori