Come organizzare un incontro di sperimentazione che trasformerà la tua azienda (e come lo faccio in Workato)

Per la maggior parte, odio le riunioni.

L'ho detto molte volte, in articoli, Tweet e ai miei colleghi.

Principalmente, non mi piace quando le persone usano le riunioni come una stampella per evitare di portare a termine il lavoro, o quando le persone gestiscono le riunioni male e fanno perdere tempo a tutti.

Ma come leader, riconosco l'importanza di alcuni incontri. In particolare, nel mio caso, l'incontro settimanale di sperimentazione.

Esatto, la pietra angolare del programma di sperimentazione di Workato è solo un incontro. Non eseguiamo standup giornalieri (li facciamo in modo asincrono su Slack); invece solo un incontro all'inizio della settimana con altri artefatti e rituali spruzzati per mantenere la macchina in movimento.

Questo sarà il mio primo e unico articolo che approfondisce i dettagli di come gestisco questo incontro, perché lo eseguo in quel modo e come lo bilanciamo con altri strumenti del programma di sperimentazione (come e-mail, database di condivisione delle conoscenze e letture).

Prima di illustrarti i minuti, vorrei iniziare ponendo una domanda di alto livello: perché questo incontro in primo luogo?

Qual è lo scopo di una riunione del team di sperimentazione?

Ogni incontro ha bisogno di uno scopo. Se non ha uno scopo, non dovrebbe accadere.

Le tre utilità del mio incontro settimanale di sperimentazione sono le seguenti:

• Apprendimento e condivisione di insight
• Priorità delle iniziative
• Identificazione ed eliminazione dei colli di bottiglia di processo

Ciò significa che eliminiamo dalla riunione la maggior parte degli altri punti di discussione che non li soddisfano.

La sperimentazione è accelerata dall'apprendimento

Quando inizi a costruire un programma di sperimentazione, devi fare il duro lavoro di gettare le basi.

• Ottenere uno strumento di test adeguato.
• Assicurati che sia integrato con il tuo strumento di analisi e stai tracciando i dati in modo appropriato.
• Comunicare con i dirigenti per stabilire le aspettative adeguate per la sperimentazione.

Una volta che inizi a ridimensionare la sperimentazione, tuttavia, ciò che impari su ciascun esperimento fungerà da potenziatore per il resto del tuo programma.

Man mano che superi 5-10 esperimenti al mese, quanto bene impari da vincitori, perdenti e inconcludenti influenzerà la percentuale di successo del prossimo batch di esperimenti che esegui. E tutto questo dovrebbe essere fondamentale nell'influenzare il modo in cui dai la priorità alla tua tabella di marcia.

Può sembrare una perdita di tempo, ma non lo è. Brian Balfour, fondatore di Reforge, sottolinea anche l'importanza degli apprendimenti nella gestione di un incontro di crescita:

Quindi trascorriamo gran parte del nostro incontro camminando attraverso gli apprendimenti e condividendo intuizioni.

Ciò è particolarmente utile se la tua riunione è interfunzionale o ha membri di altri team in chiamata, poiché spesso ottieni prospettive che normalmente non avresti.

Ad esempio, spesso invitiamo esperti di marketing di prodotti durante la nostra riunione di sperimentazione per partecipare e condividere le recenti scoperte dalla ricerca sui clienti o per condividere imminenti cambiamenti narrativi strategici.

Le cose cambiano; la definizione delle priorità è agile

Nella mia riunione, voglio chiarire dove miriamo, quali passi stiamo facendo per arrivarci e chi è responsabile e responsabile di cosa.

Questa è la parte successiva della riunione.

Da ciò che abbiamo imparato arriva la domanda: "cosa faremo dopo?"

Il nostro esperimento sulla home page è andato perso, quindi cosa abbiamo imparato e cosa faremo dopo?

Molte delle priorità vengono effettivamente eseguite in modo asincrono e su base trimestrale, almeno per i più grandi esperimenti e i più ampi bucket tematici dei nostri progetti.

Ma lasciamo molto spazio di manovra per piccoli cambiamenti e iterazioni alla tabella di marcia basata sui cambiamenti strategici e su ciò che abbiamo imparato dagli esperimenti passati, e utilizziamo parte della riunione per spostare le cose in modo da riflettere questo.

Identificazione ed eliminazione dei colli di bottiglia di processo

Infine, è importante scoprire i colli di bottiglia del processo, soprattutto se ci si trova nella fase di ridimensionamento di un programma di sperimentazione.

Ciò richiede un pensiero sistemico ed è il compito principale del team leader o del program manager. In effetti, dovrai identificare e misurare ogni fase del processo di sperimentazione dall'idea fino alla produzione.

Quali passaggi richiedono più tempo, o meglio, più tempo del previsto? E come puoi utilizzare questa riunione settimanale per identificare quei ritardi e ritardi in modo da assicurarti che il resto del processo non sia influenzato eccessivamente?

Questa è una parte fondamentale dell'incontro settimanale e, più in generale, per mantenere il tuo treno di sperimentazione sui binari.

Cosa evitare nelle riunioni di sperimentazione

Puoi gestire le tue riunioni come vuoi, ma per la riunione settimanale di sperimentazione del team, due cose tendono a essere un'enorme perdita di tempo.

• Estraendo dati ad hoc o chiedendo a chiunque di farlo
• Brainstorming e ideazione non strutturati

Quando estrai dati ad hoc o chiedi a qualcuno di farlo, prendine nota. Se richiedi ripetutamente alcuni dati, aggiungili alla checklist del processo. Non dovrebbe essere qualcosa che emerge ad ogni riunione (perde molto tempo e concentrazione). È qui che i dashboard e i report sono utili.

Sul brainstorming non strutturato, in realtà non sono un odiatore di questo in generale.

Ma c'è un tempo e un luogo e in genere un metodo per la follia.

Quando dedichi una quantità eccessiva di tempo a mettere in campo idee durante la tua riunione settimanale, riduci il tempo speso per identificare i colli di bottiglia del processo e assicurarti di eseguire gli esperimenti giusti.

Se viene fuori una buona idea a caso, va bene. Se si trasforma in una sessione di brainstorming strutturata in modo approssimativo, devi puntare i piedi e portarla offline.

Come conduco le mie riunioni settimanali del team di sperimentazione

Va bene, quindi come posso effettivamente gestire la mia riunione settimanale del team di sperimentazione?

Dovrò offuscare alcuni dettagli sugli esperimenti effettivi che conduciamo e sui risultati, ovviamente, ma tratterò ogni parte nel modo più dettagliato possibile.

Persone

Innanzitutto, le persone che frequentano ogni settimana fanno parte delle funzioni centrali di sperimentazione strategica. È un piccolo gruppo che include analisti, esperti di marketing delle prestazioni, sviluppatori web e product manager. Anche il mio manager è presente ogni tanto, ma non a tutte le chiamate.

Ho riunioni separate con il nostro team di progettazione poiché sono un centro di eccellenza nella nostra azienda.

Queste persone partecipano regolarmente e poi ogni tanto invito "ospiti" da team adiacenti come design, marketing del marchio o marketing del prodotto. Inoltre, per queste chiamate degli ospiti, di solito configuriamo una sessione separata, poiché il suo scopo è solitamente quello di presentare nuove idee, una migliore comunicazione del team o fare brainstorming.

Per renderlo più generico, nella maggior parte dei casi la riunione dell'esperimento dovrebbe includere persone che prendono decisioni sulla strategia e persone che eseguono quella strategia. Tipicamente, questo è:

• Leader/responsabile del programma
• Responsabile del prodotto
• Sviluppatori
• Designer
• Analisti

Il programma

Conduco questa riunione ogni lunedì alle 15:00 ora centrale. Il lunedì mattina è ottimo per preparare e portare a termine un lavoro approfondito o per risolvere le questioni in sospeso della settimana precedente. Nel pomeriggio, la squadra è ben preparata per discutere della prossima settimana. Questo ci consente anche di sapere su cosa dovremmo lavorare e dare priorità durante la settimana.

Quindi, per tutta la settimana, avremo controlli asincroni e incontri 1:1 per discutere i dettagli su ciò su cui abbiamo deciso di lavorare durante la riunione del team di lunedì.

Al momento non utilizziamo uno slide deck, ma potremmo incorporarlo. In tal caso, manterrò le singole sezioni legate ai nostri limiti di tempo sopra elencati e il mazzo verrà inviato il venerdì della settimana precedente (con l'obiettivo di non spendere più di 20 minuti lunedì mattina per mettere insieme le sezioni di ogni persona) . Al momento, esaminiamo principalmente il nostro database Airtable, che utilizziamo per la gestione dei progetti.

L'agenda

Ecco il mio preciso ordine del giorno:

Durata della riunione: 45 minuti

• Recupero informale: 5-10 minuti
• Apprendimenti da esperimenti/ricerche conclusi: <10 minuti
• Assegnare priorità/ripulire l'arretrato: <10 minuti
• Identificazione di colli di bottiglia/bloccanti: resto del tempo (10-15 minuti)

Esamineremo già ciascuna delle sezioni precedenti e il loro scopo.

Ti fornirò alcuni strumenti e framework che possono aiutare anche con ciascuno dei precedenti.

Apprendimenti da esperimenti/ricerche conclusi.

La cosa principale di cui hai bisogno qui è un buon sistema di documentazione.

Prima di eseguire un esperimento, è necessario compilare un documento dell'esperimento con le seguenti sezioni:

• Sfondo
• Obiettivo di apprendimento
• Ipotesi
• Previsione (che è diversa da un'ipotesi).
• Progettazione dell'esperimento (quantità e creatività)
• Follow up (cosa succede alla conclusione)

Quindi, dopo l'esecuzione dell'esperimento, vengono compilate altre due sezioni:

• Risultati
• Apprendimenti

E nel nostro incontro, tratteremo brevemente i risultati e approfondiremo la sezione sugli apprendimenti. Chiunque sia stato il "proprietario" dell'esperimento è colui che presenta gli apprendimenti, e poi c'è una breve discussione su come applicarli. A volte questo significa testare su una scala più ampia o semplicemente adattare gli apprendimenti a esperienze simili. A volte questo significa iterare in modo significativo.

I tuoi due strumenti preferiti in questo passaggio dovrebbero essere:

• Il documento dell'esperimento (clicca qui per rubare il mio modello)
• Il sistema di condivisione della conoscenza dell'esperimento / Wiki

Assegnare priorità/ripulire l'arretrato: <10 minuti

C'è un dibattito sull'utilità di questa parte, ma mi piace tenerla una discussione di gruppo perché, a differenza della semplice produzione web o della gestione del prodotto, la sperimentazione è soggetta a molte pressioni esterne, blocchi e capricci.

Ad esempio, potremmo non avere il buy-in per un esperimento particolarmente ampio che avevamo pianificato o potremmo avere un blocco dal design. Ma vogliamo comunque mantenere la nostra cadenza di test, quindi in tal caso, possiamo rimanere agili e spostare un'idea di sforzo inferiore dal backlog.

In alcune organizzazioni, questo processo decisionale è affidato esclusivamente al leader del team di sperimentazione. Mi piace aprire la discussione al gruppo.

Come mai?

Primo, non voglio schiacciare la squadra sotto il peso dei miei punteggi di priorità. Parte del valore della sperimentazione sta nell'imparare cose che non ti aspettavi di imparare e, consentendo l'autonomia di definizione delle priorità dagli altri membri del team, otteniamo idee sul tavolo che non avrei messo lì. Questo aiuta anche a migliorare la comunicazione e il rapporto generale del team.

In secondo luogo, le persone sono più entusiaste di lavorare su cose su cui hanno scelto di lavorare. Se inizio ad assegnare tutte le idee, sto limitando la passione che le persone possono provare per i singoli esperimenti (che, in molti modi, limita il potenziale di vittoria dell'esperimento).

Quindi, in questa sezione, stiamo fondamentalmente lavorando da due strumenti:

• Il kanban di gestione del progetto (usiamo Airtable – ecco un ottimo modello).
• La matrice di priorità (usiamo PXL).

Identificazione di colli di bottiglia/bloccanti: resto del tempo

Infine, identificare i colli di bottiglia.

Questo è difficile. All'inizio fa due cose:

• Trovare modelli nelle consegne in ritardo
• Porre una domanda qualitativa e aperta alla squadra

Nel mio Airtable (che mi dispiace dire che non posso condividere), ho quattro colonne in ogni carta:

• Design dovuto
• Design consegnato
• Sviluppo dovuto
• Sviluppo consegnato

Questo è in aggiunta ai passaggi Kanban che seguiamo:

• Idea
• Documento sperimentale in corso
• Documento dell'esperimento in revisione
• In via di sviluppo
• Garanzia di qualità
• QA'd e pronto per il lancio
• In esecuzione
• Concluso
• Spinto alla produzione

Questo mi permette di vedere dove le cose sono in ritardo rispetto al programma. Se, ad esempio, abbiamo eseguito 10 test ma nessuno di questi è stato implementato, abbiamo un problema di produzione. O forse i nostri esperimenti si bloccano in termini di garanzia della qualità e abbiamo un arretrato di esperimenti pronti per la pubblicazione in attesa di essere lanciati.

Nella fase di sviluppo, vogliamo anche vedere se stiamo aspettando il design o gli sviluppatori per creare l'esperienza. Se rimaniamo indietro ripetutamente, significa che dobbiamo riformulare le priorità di queste squadre o aumentare potenzialmente l'organico.

Le domande qualitative suonano così:

• Qualcuno ha bisogno del mio supporto questa settimana?
• Ci sono potenziali ostacoli al raggiungimento dei nostri obiettivi questa settimana?

Le risposte a questi dovrebbero consentire di correggere questi colli di bottiglia nel breve termine e anche di identificare i modelli quando si ripetono per essere risolti a lungo termine.

Colmare le lacune: altri utili strumenti del programma di sperimentazione

La riunione del team di sperimentazione non è l'unico strumento che dovrebbe essere nel toolkit del tuo manager.

In effetti, l'errore più grande che vedo fare dai manager della sperimentazione è cercare di fare tutto in una riunione.

Piuttosto, vuoi diffondere i tuoi rituali e manufatti in modo da utilizzare lo strumento migliore per ogni lavoro che vuoi svolgere.

La riunione del team di sperimentazione realizza tre cose:

• Apprendimenti e approfondimenti
• Priorità e allocazione del lavoro
• Identificazione e correzioni del bloccante.

Altri obiettivi del programma di sperimentazione che potrebbero interessarti sono i seguenti:

• Ottenere idee da altre squadre
• Mantenere i dirigenti e le parti interessate al passo con il ROI e i risultati
• Condivisione dei risultati con altri team per diffondere la conoscenza al di fuori della sperimentazione

A seconda della tua organizzazione, potresti avere altro su cui lavorare, come mantenere i tabelloni della sperimentazione o collaborare con i data scientist per implementare il processo DataOps per automatizzare parti dell'analisi o la tua piattaforma.

Ma per gli scopi di cui sopra, trovo che questi strumenti siano poco impegnativi e altamente efficaci:

• L'email di revisione della sperimentazione
• L'incontro di lettura della sperimentazione interfunzionale
• L'archivio della sperimentazione/lo strumento di condivisione della conoscenza

L'email di revisione della sperimentazione

La riunione del team di sperimentazione non dovrebbe essere spesa per esaminare i risultati, per la maggior parte. Questo dovrebbe essere fatto in modo efficace in una dashboard e un'e-mail settimanale che tu, il manager del programma, invii al resto del team e alle parti interessate.

Dovrebbe includere:

• Esperimenti passati che si sono conclusi + risultati
• Attualmente sono in corso esperimenti
• Esperimenti futuri

È anche possibile includere qui qualsiasi analisi e dashboard self-service. Mi piace creare grafici dei risultati visivamente accattivanti e collegare a più dettagli per i nerd del gruppo. Ma nel complesso, il tuo vicepresidente non si preoccuperà molto delle statistiche dettagliate di ogni singolo test. Quindi questa e-mail serve per ottenere visibilità per i tuoi sforzi e condividere risultati e apprendimenti di alto livello.

L'incontro di lettura della sperimentazione interfunzionale

I team di esperimenti non dovrebbero mai agire come un silo territoriale. Limiti la diffusione delle conoscenze acquisite dal tuo team e limiti anche l'afflusso di idee dirompenti.

Quindi, ogni trimestre, mi piace eseguire una lettura della sperimentazione interfunzionale in cui esaminiamo tutti gli esperimenti che abbiamo condotto e gli apprendimenti di alto livello, quindi apriamo il microfono al resto dei team per commentare e presentare idee.

Questo dà agli altri team - per me, generalmente marketing di prodotto, marchio, prodotto e demand gen - uno sguardo a ciò che abbiamo imparato. Forse possono usarlo per influenzare il loro lavoro, i messaggi e il design.

Consente inoltre loro di mettere sul nostro radar cose di cui potremmo non essere a conoscenza: una campagna imminente, un esperimento eseguito sul flusso di onboarding, ecc.

L'archivio della sperimentazione/lo strumento di condivisione della conoscenza

Infine, lo strumento più sottovalutato in un programma di sperimentazione è un posto dove archiviare tutti i risultati e gli apprendimenti. Preferibilmente, questo è uno strumento con una buona funzionalità di ricerca e tagging.

Ciò consente alle parti altamente interessate e impegnate di cercare semplicemente da sole ciò che è stato eseguito.

Personalmente, utilizzo una combinazione di Airtable e Google Docs. Ma puoi usare Notion, Confluence o uno strumento di archiviazione di test A/B dedicato come Experiments efficaci.

Conclusione

La riunione del team di sperimentazione è un rituale importante che può rendere o distruggere l'efficienza del tuo team (velocità e qualità dell'esperimento) e l'efficacia (quanto è visibile e rispettato il tuo team nell'organizzazione).

Trattate la riunione ei partecipanti con rispetto e restate fedeli al suo scopo. Evita le distrazioni e lo scope creep: ci sono altri strumenti per il brainstorming e il reporting. E presto scoprirai che invece di temere un altro incontro, non vedi l'ora che arrivi questo perché è altamente produttivo. È lì che siamo comunque atterrati.