Fatto: La comunicazione del rilascio del prodotto è problematica

Lo scopo delle note di rilascio del prodotto è far sapere ai tuoi team interni (dall'ingegneria al supporto clienti) e ai tuoi stakeholder esterni (clienti e partner) che ci sono stati cambiamenti nel prodotto. Nel settore tecnologico, dove tutto si muove a velocità della luce, fornire aggiornamenti sui prodotti tramite note di rilascio è praticamente un problema antico.

Ogni azienda in cui ho lavorato ha lottato per ottenere le note di rilascio "giuste". Ma è difficile farlo bene; l'importanza di ogni cambiamento o lancio di prodotto varia a seconda del pubblico, di come quel cambiamento altera l'interazione di un particolare gruppo con la funzionalità e di come quel gruppo utilizza il prodotto complessivamente ogni giorno.

Queste comunicazioni di rilascio del prodotto (comunemente note come note di rilascio) devono essere fornite a pubblici che si preoccupano di cose diverse. Come leader nell'Empowerment delle Entrate di Guru, i miei soggetti principali sono chiunque la cui capacità di svolgere il proprio lavoro sia influenzata dalla roadmap del prodotto, inclusi:

• I team di Prodotto/Design/Ingegneria
• Il Team Vendite (Sales ops, Vendite interne, Account Executive in tutti i segmenti)
• Esperienza Clienti (Success Manager e rappresentanti del supporto)
• Team Marketing (Marketing di Prodotto, Marketing di Crescita, Brand, Contenuti che guideranno la strategia GTM e comunicazione stampa per il prodotto)
• Sviluppo Business e Partner

Tutti questi partner devono assimilare gli aggiornamenti del prodotto e capire immediatamente in che misura devono applicare quegli aggiornamenti ai loro lavori. Devono anche considerare come possono aiutare gli utenti finali a comprendere l'impatto che qualsiasi cambiamento avrà su di loro.

La persona (o il team) che elabora le comunicazioni di rilascio deve considerare tutti i pubblici che consumeranno le informazioni sul prodotto. Quali sono le implicazioni del rilascio per un ingegnere backend rispetto a un cliente potenziale nel settore retail?

Come Non Approcciare le Note di Rilascio

Sebbene sia difficile tenere conto delle esigenze di diversi pubblici, non è neanche scalabile per un Product Manager o un Product Marketing Manager (PMM) scrivere cinque diverse versioni di note di rilascio interne. Dalla mia esperienza, le note di rilascio sono o troppo lunghe e fuori contesto oppure non hanno abbastanza competenze tecniche. Le note di rilascio statiche non ci forniscono queste intuizioni e sono spesso scritte per l'autore, non per la persona che deve capire quali cambiamenti ci sono stati. A dire il vero, sono solitamente opportunità mancate.  

Ho partecipato a chiamate settimanali sulle note di rilascio di un'ora in cui una voce monotona dalla gestione del prodotto parla dei punti chiave sulle diapositive. Dopo che la chiamata termina, quel stesso product manager riceve email, telefonate (ricorda quelle?), Slacks, ecc., da chiunque, dal supporto clienti a vendite, che vogliono sapere cosa significano i cambiamenti per loro, i loro clienti e i prospetti. Se hai perso la chiamata, hai perso le sfumature e il contesto e hai ricevuto solo il changelog grezzo.

Ma non è compito del product manager fare questa sacra traduzione; il loro compito è costruire un prodotto che risolva un problema per il mercato. È compito del PMM tradurre quella intenzione affinché il mercato ne comprenda il valore.

Il segreto per scrivere ottime note di rilascio del software

Sono un grande fan de La famiglia Glück (scioccante, lo so) e come professionista dell'abilitazione, le lezioni senza tempo del film sono vere. “Iniziamo dall'inizio/è un ottimo punto di partenza,” mi passa per la testa ogni settimana. Quindi, nel dare forma o rimodellare un processo di consegna del prodotto, devi imparare il linguaggio prima di poter insegnare l'argomento.

1. Sviluppa un glossario interno

Il primo passo per approfondire questo processo significa ottenere il team intero che parla la stessa lingua. Socializzare la terminologia condivisa sembra ovvio, ma potrebbe non accadere nella tua organizzazione. Non sapere gli acronimi e fraintendere il linguaggio può isolare, creando confusione e silos tra i team.

Esempio: Il nostro team di marketing utilizza il termine “lancio” per descrivere quando e come andremo a mercato con una funzione. Il team di ingegneri tuttavia, usa la parola “lancio” per descrivere quando una funzione è stata rilasciata nel nostro ambiente di staging. Il lancio specifico della funzione è “finito” per l'ingegneria prima che i nostri clienti ne sappiano. Questo era confuso e internamente conflittuale.

Nessuno vuole essere quello che si fa avanti pubblicamente ammettendo di non sapere cosa significa qualcosa chiedendo definizioni. La nostra soluzione: In un gruppo di lavoro interfunzionale (con rappresentanza da ingegneria, prodotto, marketing di prodotto), abbiamo approfondito la sfumatura e documentato le nostre definizioni di rilascio del prodotto:

Nota: Se alcune delle schede non riescono a caricarsi, basta ricaricare la pagina!

2. Cosa includere nelle tue note di rilascio

La cosa più semplice da fare è creare un modello riutilizzabile per scrivere note di rilascio. La cosa più semplice da fare è creare un modello riutilizzabile per scrivere note di rilascio. In questo modo, i soggetti interessati si familiarizzano con il formato dopo alcune iterazioni, e ti evita il problema di dover reinventare la ruota ogni volta.

Al minimo, buone note di rilascio includono:

• Le date di rilascio
• Interno ed esterno
• Una descrizione della funzionalità o del bug
• Il(i) prodotto(i) che sono impattati (se ne hai più di uno)
• Se hai più prodotti software, potresti anche voler includere i numeri di versione
• Dove possono essere fatte domande internamente

Tuttavia, ottime note di rilascio includono anche:

• Domande frequenti previste (FAQ)
• Collegamento a nuova documentazione pubblica, se disponibile
• Per funzionalità:
• Il nome della funzionalità
• Screenshot di come appare la funzionalità
• Video di come dimostrare la funzionalità
• Perché la funzionalità esiste
• Come impatta le relevant buyer/customer personas

Ecco il modello che usiamo internamente (sentiti libero di copiare!):

💡Nota: È utile assegnare individui direttamente responsabili per questo compito (piuttosto che lasciarlo a uno sforzo di gruppo dove nessuno lo possiede). Gli ingegneri o i Product Manager dovrebbero possedere il lato tecnico delle note (nome/versione/prodotto/date/screenshot), mentre i Product Marketing Manager o i Sales Engineer dovrebbero possedere le informazioni contestuali (buyer personas/perché è importante).

Implementare una strategia di processo di consegna del prodotto

Creare un formato di comunicazione consistente

Ora che hai unificato la terminologia e scritto il tuo modello, il passo successivo è concordare un mezzo di consegna consistente (cioè: Slack, email, Loom, Guru, Google Docs) e metodologia. Un mezzo di consegna consistente assicura che i tuoi soggetti delle note di rilascio sappiano dove dovrebbero andare o guardare o abbonarsi (per ottenere) per essere a conoscenza di un rilascio.

Questo è anche essenziale per la gestione del cambiamento perché normalmente devi dire a qualcuno qualcosa più volte per assicurarti che lo assorba completamente. A seconda del tipo di rilascio, delle modifiche all'interfaccia utente/esperienza utente (UI/UX) e dell'impatto al cliente, il tuo pubblico delle note di rilascio avrà bisogno di essere spinto a conoscere il prodotto (per spingere). Noi di Guru adottiamo entrambe le metodologie push e pull.

Il Pull: Dove trovare la conoscenza

Per noi, i soggetti interessati possono seguire nel nostro canale Slack #release-notes, dove c'è un formato costante e digeribile per tutto, dalle correzioni di bug a nuove funzionalità. Tieni presente che i tuoi rispettivi pubblici non solo devono essere a conoscenza che i rilasci stanno avvenendo (tramite il pull in Slack o email) ma più importante, devono sapere perché quel rilascio è importante nel contesto.

La conoscenza che un rilascio semplicemente sarà realizzato o è stato realizzato non ha valore a meno che il tuo team possa fare effettivamente qualcosa con essa. Per sviluppare un formato consistente che fornisca il contesto appropriato, ho intervistato rappresentanti di vendita, rappresentanti di sviluppo account, persone di sviluppo business (il lavoro), per stabilire il nostro modello per la consegna del prodotto che chiamiamo “Scheda di Analisi delle Funzionalità”, che puoi trovare sopra.

Quando un Manager di Ingegneria inizia a sviluppare una nuova funzionalità, persone direttamente responsabili vengono avvisate tramite Asana per creare la Scheda di Analisi delle Funzionalità specifica utilizzando il modello delle note di rilascio. La nuova scheda di analisi delle funzionalità diventa la robusta, unica fonte di verità o il “cervello della funzionalità” che stiamo rilasciando. Gli esperti di materia (SME) — come PMM e ingegneri di vendita — includono dettagli su perché il rilascio è prezioso, per chi è più significativo e dove applicabile, indicazioni su come dimostrare la funzionalità come parte di una storia più grande.

Gli stakeholder delle note di rilascio, in particolare gli Account Executive, tornano continuamente sulle stesse schede perché hanno imparato che la conoscenza dinamica sulla Scheda di Analisi delle Funzionalità è fidata, pertinente e applicabile. Ora i pubblici parlano la stessa lingua e leggono dallo stesso (dinamico) playbook. Un ritorno alla Scheda di Analisi delle Funzionalità è comunque parte di un metodo “pull” perché è autogestito e viene effettuato per prepararsi a una chiamata di vendita o supporto, o se un prospetto ha una domanda sulla roadmap.

Il Push: Fornire proattivamente conoscenza

Il metodo Push entra in gioco quando la conoscenza su un rilascio è sensibile al tempo e critica per team specifici. Qui, ciò è realizzato attraverso la funzionalità annunci di Guru. In base all'impatto sui miei pubblici interni, io spingo un annuncio tramite Guru a un gruppo pertinente. Posso quindi vedere un rapporto di coloro che hanno riconosciuto o letto l'alert e pubblicamente vergognarmeli, ricordare a coloro che non l'hanno fatto.  

Perché una cultura guidata dalla conoscenza è la chiave 🗝

Nonostante tutto quanto sopra, non è effettivamente così semplice come concordare sulla terminologia, scrivere note di rilascio sorprendenti e creare un meccanismo per la consegna dinamica del prodotto. I team devono essere in grado di collaborare sulla conoscenza e dare feedback nel tempo. Fornire feedback e migliorare la conoscenza condividendola è parte dei ruoli e delle responsabilità di tutti nel team.

Per noi, ciò significa che quando i consumatori di conoscenza (in questo caso, gli stakeholder delle note di rilascio) hanno una domanda o imparano qualcosa di nuovo, commentano sulla Scheda di Analisi delle Funzionalità. Incorporiamo anche le domande poste e risposte in Slack commentando come modo per migliorare continuamente la conoscenza. L'esperto di materia (tipicamente il PMM) esaminerà e incorporerà quella nuova conoscenza o domanda pertinente, mettendola in contesto nella particolare scheda di analisi delle funzionalità.

Rendiamo anche tutte le nostre note di rilascio facilmente accessibili mettendole nelle sezioni in arrivo o lanciate del nostro Tabellone di Analisi delle Funzionalità, dove possono essere ulteriormente organizzate internamente. In questo modo, saranno facili da seguire a colpo d'occhio. Se non stai utilizzando Guru, ti consigliamo di provare a creare una pagina di note di rilascio, o un changelog collegato.

Come per qualsiasi altro processo, questo è in continua evoluzione. La consegna del prodotto e le note di rilascio non sono mai semplici come "una volta e basta". Con l'evoluzione delle esigenze della tua azienda, il tuo processo, le responsabilità e i modelli dovrebbero cambiare di conseguenza. Ma puntando a una facile comprensione, contesto e usabilità, non puoi perdere.