L'esperienza del prodotto non appare dall'oggi al domani. L'intero processo di sviluppo del prodotto è ciò che crea "esperti" attorno a determinate caratteristiche e funzionalità, ed è la base per tutta la documentazione che precede e segue il loro rilascio.

I team che utilizzano Guru per l'abilitazione del prodotto riconoscono l'importanza di avere un'unica fonte di verità per le informazioni conoscitive che abbracciano l'intero ciclo di vita del rilascio del prodotto—dallo sviluppo iniziale al supporto e manutenzione continuativi. Dando a ogni dipartimento un luogo affidabile concordato per inserire informazioni verificate da esperti, tutti i coinvolti in questi processi trasversali possono lavorare meglio. Vediamo insieme un recente rilascio di funzionalità in Guru come esempio di abilitazione del prodotto in azione.

Durante il mese di gennaio, il nostro nuovo pod di Monetizzazione ha lavorato sulla prima parte di un aggiornamento all'esperienza di fatturazione in Guru. Questo progetto ha coinvolto il solito team di sviluppo del prodotto—gestione del prodotto, design, ingegneria e marketing del prodotto—insieme a diversi altri stakeholder tra cui finanza, supporto e operazioni di vendita. Questo era un aggiornamento tecnico che richiedeva una comunicazione e coordinamento stretti tra tutti i team coinvolti, oltre a un sostanziale lavoro preparatorio per consentire ai nostri colleghi a contatto con i clienti di parlare con sicurezza di queste modifiche. Le seguenti tre fasi racchiudono i principali modi in cui utilizziamo Guru per l'abilitazione del prodotto attorno a rilasci di funzionalità come questo.

Fase 1: Pianificazione e sviluppo delle funzionalità

L'abilitazione del prodotto inizia davvero nel momento in cui il progetto di un team di prodotto riceve il via libera. Questo potrebbe riguardare un miglioramento di funzionalità minore, una riprogettazione di pagina, o una funzionalità completamente nuova. Dal momento in cui le specifiche del progetto vengono redatte da un Product Manager (PM) e condivise con i loro ingegneri, designer e altri stakeholder, tutti necessitano di accesso a documentazione affidabile e aggiornata da diversi autori.

La nostra pianificazione è iniziata a dicembre, con i nostri PM che identificavano alcuni punti chiave all'interno delle nostre esperienze di fatturazione e checkout che necessitavano di un aggiornamento. Da lì, hanno stilato un piano di progetto e iniziato a redigere le prime specifiche delle funzionalità per il primo progetto della serie. Una volta pronti a condividere con il team, hanno programmato un incontro di avvio per illustrare al team le modifiche proposte e discutere delle tempistiche. Da questo momento in poi, era fondamentale che tutti i coinvolti nel progetto avessero accesso a tutti i documenti correlati, incluse le specifiche del progetto, i design, la documentazione di fatturazione correlata e altro.

Poiché questi documenti cambiano frequentemente e possono essere integrati spesso durante le prime fasi di un progetto, è importante avere una fonte di verità affidabile a cui il team può tornare. Per assicurarci che tutti avessero un unico luogo per condividere e accedere a queste risorse, abbiamo creato una Scheda Risorse Progetto Attivo da condividere con il team. Abbiamo posizionato questo all'interno del Board del Pod di Monetizzazione, dove tutti gli stakeholder appropriati hanno accesso come autori.

Durante il processo di sviluppo, i nostri ingegneri non dovevano preoccuparsi di aggiungere ai segnalibri i file di design o di controllare se il testo fornito loro la settimana scorsa fosse ancora aggiornato. Invece, potevano fare riferimento alla Scheda Risorse Progetto Attivo mentre lavoravano, assicurandosi di basarsi sulle informazioni più aggiornate. Scopri come i team di ingegneria utilizzano Guru.

Fase 2: Preparazione al rilascio

Per noi, i rilasci di funzionalità sono uno sport di squadra in Guru. Man mano che ci avviciniamo alla fine dello sviluppo, dobbiamo assicurarci di aver soddisfatto tutti i requisiti, testato i potenziali punti critici per i clienti e comunicato adeguatamente le prossime modifiche ai nostri team a contatto con i clienti. Poiché questa è la fase in cui le informazioni sono più propense a cambiare rapidamente, garantire che tutta la conoscenza sia verificata dagli esperti rispettivi è di importanza fondamentale.

Per il nostro recente progetto di fatturazione, abbiamo assegnato una settimana al team e ai nostri stakeholder per condurre controlli di qualità (QA) e testare la nuova esperienza cliente prima di andare dal vivo. Poiché questo era un progetto particolarmente tecnico, ci sono stati diversi passaggi coinvolti nell'impostare gli ambienti e renderli pronti per il testing, inclusa l'attivazione delle funzionalità e la lavorazione attraverso un insieme specifico di passaggi replica del checkout. Per assicurarsi che tutti avessero tutte le informazioni necessarie per partecipare ai test, il nostro team di ingegneria ha creato una Scheda con le istruzioni passo-passo per partecipare alla QA. Abbiamo inviato questa Scheda al nostro Pod e agli stakeholder tramite un annuncio per assicurarci che l'avessero letta prima di iniziare i test.

Durante il processo di QA, era anche importante informare i nostri team a contatto con i clienti delle prossime modifiche per prepararli a eventuali domande che i potenziali clienti o i clienti potrebbero avere. Sebbene queste modifiche si concentrassero principalmente sulla facilità d'uso e sull'affidabilità (rispetto a una modifica più ampia dell'interfaccia), alcune parti dell'esperienza di fatturazione legacy sarebbero state alterate con questo progetto. Per comunicare queste modifiche con ampio anticipo per la revisione e per porre domande, abbiamo aggiornato la nostra Scheda di divisione delle funzionalità di fatturazione.

Noterai che questa è la prima volta nel processo in cui stiamo usando la parola aggiorna anziché crea, ed è intenzionale. Utilizziamo Schede di divisione delle funzionalità come fonte di verità vivente sulle funzionalità per i nostri team a contatto con i clienti, il che significa che esiste una per tutte le nostre funzionalità attive in qualsiasi momento. 

Quando aggiorniamo e miglioriamo una funzionalità esistente, aggiorniamo e miglioriamo di conseguenza la Scheda di divisione delle funzionalità. Questo previene il vecchio problema di un rappresentante di vendita incerto se stia guardando documentazione obsoleta su una funzionalità e di contattare gli ingegneri in preda al panico durante una chiamata. Possono essere certi che la Scheda sulla pagina di fatturazione di cui si erano affidati lo scorso anno sia altrettanto accurata quest'anno, come verificato dal team che lavora sulle migliorie.

Fase 3: Rilascio e oltre

L'applicazione più ovvia dell'abilitazione del prodotto potrebbe davvero riguardare il lancio della nuova funzionalità o di quella migliorata. Da panoramiche come la Scheda di divisione delle funzionalità sopra a domande e risposte altamente tecniche e specifiche, molto va nel garantire che i team a contatto con i clienti siano dotati di tutto ciò di cui hanno bisogno per vendere e supportare ogni rilascio. E man mano che le funzionalità vengono iterate e migliorate nel tempo, rimane fondamentale che tutta la documentazione sia mantenuta aggiornata e riflettente lo stato attuale del prodotto.

Non stupisce che le pagine di fatturazione siano incredibilmente complesse e sfumate, il che significa che non mancano le eventuali domande che i clienti potrebbero avere mentre completano un processo di checkout. Sebbene la nostra esperienza di fatturazione non sia qualcosa di cui il nostro team vendite avrà probabilmente bisogno di parlare in troppi dettagli, è un'area in cui il nostro team di supporto spesso aiuta i clienti a orientarsi. Per prepararsi a questo lancio e ad ulteriori miglioramenti all'esperienza di checkout, il nostro team di ingegneria ha lavorato con il nostro campione di supporto clienti per curare un elenco di FAQ tecniche, che viene aggiornato man mano che sorgono nuove domande. Questo fornisce non solo al team di supporto, ma a chiunque risponda alle domande dei clienti su fatturazione un luogo coerente da controllare prima di contattare il nostro team (e poi, aggiungere alla Scheda FAQ tecniche!).

Oltre a mantenere la Scheda FAQ aggiornata man mano che procedono le iterazioni, anche la Scheda di divisione delle funzionalità viene mantenuta evergreen. Oltre a notare la data ufficiale di lancio e i punti salienti importanti sull'esperienza di fatturazione nuova, collegheremo altre Schede e risorse correlate, proprio come questo post del blog. Creando un punto di accesso unico per accedere a tutte le informazioni disponibili su una funzionalità, diamo ai nostri team a contatto con i clienti la sicurezza di parlargli con una prospettiva completamente informata.

Per chiudere questo cerchio, non possiamo dimenticare come il feedback dei clienti e del mercato svolga un ruolo importante nel ciclo di sviluppo del prodotto. Man mano che i nostri team portano nuove e migliorate funzionalità ai nostri clienti esistenti e al nostro mercato, raccogliamo informazioni preziose su ciò che li aiuta a svolgere un lavoro migliore e su cosa sperano di vederci concentrare in futuro. Documentare e condividere queste informazioni con il nostro team di prodotto è una parte importante del nostro processo di sviluppo iterativo e ci aiuta a fornire il massimo valore possibile ai nostri clienti. E la documentazione su come condividere diversi modi di feedback (registrazioni di chiamate, email, ecc.) è mantenuta in—l'hai indovinato—Guru.