Spedizione del prodotto in iterazioni: una guida ai test di ipotesi

Uno sguardo al Play Store/App Store su qualsiasi telefono rivelerà che la maggior parte delle app installate ha ricevuto aggiornamenti rilasciati nell'ultima settimana. Una visita al sito Web dopo alcune settimane potrebbe mostrare alcune modifiche al layout, all'esperienza utente o al testo.

I prodotti software oggi vengono forniti in iterazioni per convalidare ipotesi e ipotesi su ciò che rende l'esperienza del prodotto migliore per gli utenti. In qualsiasi momento, aziende come booking.com (dove ho lavorato in precedenza) eseguono centinaia di test A/B sui loro siti proprio per questo scopo.

Per le applicazioni fornite su Internet, non è necessario decidere l'aspetto di un prodotto con 12-18 mesi di anticipo, quindi costruirlo ed eventualmente spedirlo. Al contrario, è perfettamente pratico rilasciare piccole modifiche che forniscano valore agli utenti mentre vengono implementate, eliminando la necessità di formulare ipotesi sulle preferenze dell'utente e sulle soluzioni ideali, poiché ogni ipotesi e ipotesi può essere convalidata progettando un test per isolare l'effetto di ogni cambiamento.

Oltre a fornire valore continuo attraverso miglioramenti, questo approccio consente a un team di prodotto di raccogliere feedback continui dagli utenti e quindi correggere il corso secondo necessità. Creare e testare ipotesi ogni due settimane è un modo più economico e semplice per costruire un approccio iterativo e di correzione del corso alla creazione di valore del prodotto.

Che cos'è il test di ipotesi?

Durante la spedizione di una funzionalità agli utenti, è fondamentale convalidare le ipotesi sul design e le funzionalità per comprenderne l'impatto nel mondo reale.

Questa convalida viene tradizionalmente eseguita attraverso il test dell'ipotesi del prodotto, durante il quale lo sperimentatore delinea un'ipotesi per un cambiamento e quindi definisce il successo. Ad esempio, se un Data Product Manager di Amazon ha l'ipotesi che mostrare immagini di prodotti più grandi aumenterà i tassi di conversione, il successo è definito da tassi di conversione più elevati.

Uno degli aspetti chiave della verifica delle ipotesi è l'isolamento di diverse variabili nell'esperienza del prodotto per poter attribuire il successo (o il fallimento) alle modifiche apportate. Quindi, se il nostro product manager Amazon avesse un'ulteriore ipotesi che mostrare le recensioni dei clienti accanto alle immagini dei prodotti migliorerebbe la conversione, non sarebbe possibile testare entrambe le ipotesi contemporaneamente. Ciò comporterebbe la mancata corretta attribuzione di cause ed effetti; pertanto, le due modifiche devono essere isolate e testate singolarmente.

Pertanto, le decisioni sui prodotti sulle funzionalità dovrebbero essere supportate da test di ipotesi per convalidare le prestazioni delle funzionalità.

Diversi tipi di test di ipotesi

Test A/B

I casi d'uso più comuni possono essere convalidati mediante test A/B randomizzati, in cui una modifica o una funzionalità viene rilasciata in modo casuale a metà degli utenti (A) e trattenuta dall'altra metà (B). Tornando all'ipotesi di immagini di prodotto più grandi che migliorano la conversione su Amazon, a metà degli utenti verrà mostrata la modifica, mentre l'altra metà vedrà il sito web come era prima. La conversione verrà quindi misurata per ciascun gruppo (A e B) e confrontata. In caso di un aumento significativo della conversione per il gruppo che mostrava immagini di prodotti più grandi, la conclusione sarebbe che l'ipotesi originale era corretta e la modifica può essere estesa a tutti gli utenti.

Test multivariato

Idealmente, ogni variabile dovrebbe essere isolata e testata separatamente in modo da attribuire in modo definitivo le modifiche. Tuttavia, un tale approccio sequenziale al test può essere molto lento, specialmente quando ci sono diverse versioni da testare. Per continuare con l'esempio, nell'ipotesi che immagini di prodotti più grandi portino a tassi di conversione più elevati su Amazon, "più grande" è soggettivo e diverse versioni di "più grande" (ad esempio, 1.1x, 1.3x e 1.5x) potrebbero aver bisogno di essere testato.

Invece di testare tali casi in sequenza, è possibile adottare un test multivariato, in cui gli utenti non sono divisi a metà ma in più varianti. Ad esempio, quattro gruppi (A, B, C, D) sono costituiti dal 25% di utenti ciascuno, dove gli utenti del gruppo A non vedranno alcun cambiamento, mentre quelli nelle varianti B, C e D vedranno immagini più grandi di 1.1x, 1.3x e 1.5x, rispettivamente. In questo test, più varianti vengono testate contemporaneamente rispetto alla versione corrente del prodotto per identificare la variante migliore.

Prima/Dopo il test

A volte, non è possibile dividere gli utenti a metà (o in più varianti) poiché potrebbero esserci effetti di rete in atto. Ad esempio, se il test prevede di determinare se una logica per formulare un aumento dei prezzi su Uber è migliore di un'altra, i driver non possono essere suddivisi in diverse varianti, poiché la logica tiene conto del disadattamento tra domanda e offerta dell'intera città. In tali casi, un test dovrà confrontare gli effetti prima della modifica e dopo la modifica per giungere a una conclusione.

Tuttavia, il vincolo qui è l'incapacità di isolare gli effetti della stagionalità e dell'esternalità che possono influenzare in modo diverso i periodi di test e di controllo. Supponiamo che all'istante t venga apportata una modifica alla logica che determina l'aumento del prezzo su Uber, in modo tale che la logica A venga utilizzata prima e la logica B dopo. Sebbene gli effetti prima e dopo il tempo t possano essere confrontati, non vi è alcuna garanzia che gli effetti siano dovuti esclusivamente al cambiamento di logica. Potrebbe esserci stata una differenza nella domanda o altri fattori tra i due periodi di tempo che hanno determinato una differenza tra i due.

Test di accensione/spegnimento basati sul tempo

Gli svantaggi dei test prima/dopo possono essere superati in larga misura implementando test di attivazione/disattivazione basati sul tempo, in cui la modifica viene introdotta a tutti gli utenti per un determinato periodo di tempo, disattivata per un uguale periodo di tempo e poi ripetuto per una durata maggiore.

Ad esempio, nel caso d'uso Uber, la modifica può essere mostrata ai conducenti lunedì, ritirata martedì, mostrata nuovamente mercoledì e così via.

Sebbene questo metodo non rimuova completamente gli effetti della stagionalità e dell'esternalità, li riduce in modo significativo, rendendo tali test più robusti.

Progettazione di prova

La scelta del test giusto per il caso d'uso in questione è un passaggio essenziale per convalidare un'ipotesi nel modo più rapido e affidabile. Una volta effettuata la scelta, si possono delineare i dettagli del progetto di prova.

Il design del test è semplicemente uno schema coerente di:

• L'ipotesi da verificare: mostrare agli utenti immagini di prodotti più grandi li porterà ad acquistare più prodotti.
• Metriche di successo per il test: Conversione del cliente
• Criteri decisionali per il test: il test convalida l'ipotesi che gli utenti della variante mostrino un tasso di conversione più elevato rispetto a quelli del gruppo di controllo.
• Metriche che devono essere strumentate per imparare dal test: Conversione dei clienti, clic sulle immagini dei prodotti

Nel caso dell'ipotesi che immagini di prodotto più grandi portino a una migliore conversione su Amazon, la metrica di successo è la conversione e il criterio decisionale è un miglioramento della conversione.

Dopo aver scelto e progettato il test giusto e identificati i criteri e le metriche di successo, i risultati devono essere analizzati. Per fare ciò, sono necessari alcuni concetti statistici.

Campionamento

Durante l'esecuzione dei test, è importante assicurarsi che le due varianti selezionate per il test (A e B) non abbiano pregiudizi rispetto alla metrica di successo. Ad esempio, se la variante che vede le immagini più grandi ha già una conversione maggiore rispetto alla variante che non vede il cambiamento, il test è parziale e può portare a conclusioni errate.

Per garantire che non vi siano distorsioni nel campionamento, è possibile osservare la media e la varianza per la metrica di successo prima che venga introdotta la modifica.

Significato e potere

Una volta osservata una differenza tra le due varianti, è importante concludere che il cambiamento osservato è un effetto reale e non casuale. Questo può essere fatto calcolando il significato del cambiamento nella metrica di successo.

In parole povere, la significatività misura la frequenza con cui il test mostra che immagini più grandi portano a una conversione più elevata quando in realtà non lo fanno. La potenza misura la frequenza con cui il test ci dice che immagini più grandi portano a una conversione più elevata quando effettivamente lo fanno.

Quindi, i test devono avere un alto valore di potenza e un basso valore di significatività per risultati più accurati.

Sebbene un'esplorazione approfondita dei concetti statistici coinvolti nella verifica delle ipotesi di prodotto sia fuori portata qui, si raccomandano le seguenti azioni per migliorare le conoscenze su questo fronte:

• Gli analisti di dati e gli ingegneri di dati sono generalmente abili nell'identificare i giusti progetti di test e possono guidare i product manager, quindi assicurati di utilizzare la loro esperienza nelle prime fasi del processo.
• Esistono numerosi corsi online sul test di ipotesi, test A/B e concetti statistici correlati, come Udemy, Udacity e Coursera.
• L'utilizzo di strumenti come Firebase e Optimizely di Google può semplificare il processo grazie a una grande quantità di funzionalità pronte all'uso per eseguire i test giusti.

Utilizzo del test di ipotesi per una gestione del prodotto di successo

Al fine di fornire continuamente valore agli utenti, è imperativo testare varie ipotesi, allo scopo di utilizzare diversi tipi di test di ipotesi di prodotto. Ogni ipotesi deve avere un disegno di test di accompagnamento, come descritto sopra, al fine di convalidarla o invalidarla in modo conclusivo.

Questo approccio aiuta a quantificare il valore fornito da nuove modifiche e funzionalità, concentrare l'attenzione sulle funzionalità più preziose e fornire iterazioni incrementali.