Note di rilascio e aggiornamento per gli stakeholder, la stessa funzionalità
5 min di lettura
Il modo più veloce di annunciare una funzionalità rilasciata è copiare il changelog di ingegneria in un'e-mail e inviarla a tutti. Così l'aggiornamento parte, ma significa anche che gli utenti ricevono dettagli di implementazione di cui non hanno bisogno e la dirigenza non ottiene l'inquadramento di business che vuole davvero. Un PM che ha appena rilasciato una funzionalità di esportazione in blocco può inviare lo stesso paragrafo, che descrive endpoint API e limiti di frequenza, sia alle note di rilascio rivolte ai clienti sia al canale Slack della dirigenza, e vederlo accolto male in entrambi i posti.
Attenzione
Un solo riepilogo tecnico inviato a ogni pubblico non è comunicazione, è distribuzione. Un changelog scritto per ingegneri suona come rumore per gli utenti e come un non aver capito il punto per la dirigenza.
La funzionalità è stata rilasciata una volta. Cosa significa dipende interamente da chi ne sta leggendo.
Perché un solo riepilogo serve male ogni lettore
Un changelog è scritto per essere preciso su ciò che è cambiato tecnicamente. Quella precisione è esattamente ciò di cui un utente non ha bisogno e ciò che un aggiornamento per la dirigenza vuole tradotto in risultati, non in implementazione. Un utente che legge “aggiunto il supporto alla paginazione all'endpoint di esportazione” non ha idea che significhi poter ora esportare più di 10.000 righe in una volta, e una dirigenza che legge la stessa frase non ha idea se sia una piccola pulizia tecnica o la correzione della principale lamentela dei clienti del trimestre.
Immagina una funzionalità di esportazione in blocco rilasciata dopo settimane di lavoro di ingegneria per rimuovere un limite rigido di 10.000 righe che generava ticket di supporto da mesi. La voce del changelog, accurata e precisa, descrive la modifica tecnica in termini di paginazione e ottimizzazione delle query. Né l'utente, che vuole solo sapere che ora può esportare l'intero set di dati, né la dirigenza, che vuole sapere che questo chiude una fonte ricorrente di rischio di abbandono, ottiene ciò che gli serve da quella stessa frase.
Prima: copiare il changelog di ingegneria, incollarlo in un'e-mail, inviarlo a utenti e dirigenza allo stesso modo.
Dopo: dare a Claude il riepilogo tecnico una volta sola e chiedere una versione rimodellata per ciascun pubblico: cosa è cambiato e perché conta per loro in particolare.
Un processo per rimodellare un aggiornamento per due pubblici
- 1
Parti dal vero changelog, non da un ricordo della funzionalità
Il changelog ha l'ambito reale di ciò che è stato rilasciato. Lavorare a memoria rischia di esagerare ciò che è nuovo o di omettere un dettaglio che conta per uno dei pubblici.
- 2
Nomina ciò che sta davvero a cuore a ciascun pubblico
Dillo esplicitamente: agli utenti interessa cosa è cambiato per loro e come usarlo; alla dirigenza interessa cosa muove, adozione, ricavi, una metrica del documento di roadmap. Senza nominarlo, entrambe le versioni scivolano verso l'inquadramento tecnico.
- 3
Dai una lunghezza reale a ciascuna versione
Un numero preciso di frasi o parole forza la compressione verso ciò che conta di più per quel pubblico, invece di una versione appena sfoltita della stessa spiegazione.
- 4
Controlla che nessuna versione esageri ciò che è stato rilasciato
Confronta entrambi gli output con il changelog reale. Una nota di rilascio rivolta agli utenti, in particolare, può scivolare verso un linguaggio di marketing che promette più di ciò che è davvero online.
Trasforma questo changelog di ingegneria della nostra nuova funzionalità di esportazione in blocco in una nota di rilascio di 3 frasi per gli utenti e in un aggiornamento di stato di 100 parole per la dirigenza.
”Se la funzionalità si lega direttamente a una metrica che la dirigenza sta seguendo, il volume dei ticket di supporto, un rischio di abbandono segnalato in una precedente revisione della roadmap, vale la pena nominare esplicitamente quel collegamento perché la versione per la dirigenza si apra con il risultato invece di seppellirlo.
Questa funzionalità risponde specificamente alle lamentele sul limite di esportazione che avevamo segnalato come rischio di abbandono nella revisione della roadmap del trimestre scorso. Assicurati che la versione per la dirigenza si apra con quel collegamento, non solo con una descrizione generale della funzionalità.
”
Dentro Claude Tutorial
Rimodellare un aggiornamento per ciò che sta davvero a cuore a ogni lettore è trasferibile.
Adattare le stesse informazioni di fondo alle preoccupazioni reali di lettori diversi, invece di inviare una sola versione a tutti, vale ben oltre le note di rilascio. L'app ha una lezione completa al riguardo, con esercizi che si applicano a qualsiasi aggiornamento con più di un pubblico.
Quando la funzionalità non è stata rilasciata del tutto
Non ogni aggiornamento è un lancio pulito. Se una funzionalità è stata rilasciata parzialmente, dietro un flag o a un gruppo limitato, entrambe le versioni devono dirlo onestamente invece di lasciar intendere una disponibilità generale. Una nota di rilascio che esagera la disponibilità genera un costo specifico e prevedibile: utenti che non trovano la funzionalità e aprono un ticket chiedendo dove sia finita.
Consiglio
Di' esplicitamente a Claude cosa è davvero online e cosa è ancora in distribuzione, e chiedi che entrambe le versioni lo riflettano con precisione. Una nota di rilascio che promette troppo sulla disponibilità crea più ticket di supporto di quanti ne eviti.
Questa funzionalità è online per il 20% degli utenti dietro un flag, non ancora disponibile a tutti. Riscrivi la nota di rilascio e l'aggiornamento per gli stakeholder per riflettere questo con precisione, senza sminuire il fatto che è un progresso reale.
”Vale anche la pena preparare una breve nota per il supporto o il customer success prima di un rilascio graduale come questo, così hanno una risposta accurata pronta quando un utente senza il flag chiede di una funzionalità che ha visto menzionata altrove.
Scrivi una breve nota interna per il team di supporto che spieghi il rilascio graduale, così hanno una risposta accurata pronta se un utente senza il flag chiede di questa funzionalità.
”Continua a leggere
- Scrivere un documento di roadmap che spieghi i compromessi: dove è iniziata questa funzionalità rilasciata, come voce di roadmap ordinata e motivata.
- Trasformare i ticket di supporto in temi prioritizzati: chiudere il cerchio con gli utenti i cui ticket avevano originariamente fatto emergere la necessità di questa funzionalità.
- Affilare un PRD prima di inviarlo in revisione: la stessa disciplina, testare con un lettore privo del tuo contesto, applicata prima nella vita di questa funzionalità.