Il responsabile di prodotto rilascia una funzione. La funzione dovrebbe risolvere un problema dei clienti e favorire la fidelizzazione.
Due settimane dopo il lancio: la funzione riduce l'abbandono? Più clienti usano la funzione? I clienti passano più tempo nella funzione?
Senza una dashboard di prodotto, il responsabile aspetta sei settimane il report mensile per vedere l'impatto della funzione. A quel punto i feedback dei clienti sono freddi. Non può iterare.
Con una dashboard di prodotto, il responsabile vede dopo due settimane: l'adozione della funzione è del cinque per cento (l'obiettivo era venti per cento alla seconda settimana). Il problema si vede subito. Il responsabile indaga. Scopre che la funzione è difficile da trovare. Aggiunge un messaggio di onboarding. L'adozione sale al quindici per cento alla quarta settimana.
Dashboard di prodotto: adozione e coinvolgimento
Tasso di adozione della funzione
La funzione è stata lanciata due settimane fa. Utenti idonei: diecimila. Utenti che hanno usato la funzione: cinquecento. Tasso di adozione: cinque per cento. L'obiettivo era venti per cento alla quarta settimana. Al momento è indietro. Serve un'indagine.
Coinvolgimento nella funzione
Dei cinquecento utenti che hanno provato la funzione, quanti la usano ogni giorno? Duecento. Quanti la usano ogni settimana? Trecento. Quanti hanno abbandonato la funzione? Duecento. Tasso di coinvolgimento: quaranta per cento giornaliero, sessanta per cento settimanale, quaranta per cento abbandono. L'abbandono è troppo alto. La funzione non è appiccicosa.
Tempo speso nella funzione
La sessione media nella funzione è di due minuti. Prima della funzione, il tempo medio di sessione sul sito era di dieci minuti. La funzione sta allontanando gli utenti dalle altre funzioni. È voluto? La funzione ha sostituito una funzione più vecchia o è un'aggiunta?
Impatto sulla fidelizzazione
Clienti che hanno adottato la funzione: otto per cento di abbandono mensile. Clienti che non l'hanno adottata: dodici per cento di abbandono mensile. La funzione funziona. Miglioramento dell'abbandono di quattro punti percentuali. Per una base di mille clienti sono quaranta clienti in meno persi al mese. Quaranta per cinquanta (valore medio del cliente) sono duemila di ricavi risparmiati al mese.
Dashboard delle operazioni: stato dei sistemi e prestazioni
Disponibilità del sistema
Il sito è stato attivo il 99,95 per cento del tempo la settimana scorsa. L'obiettivo è 99,99 per cento. Siamo sotto l'obiettivo. Due interruzioni: una di dieci minuti, una di quindici minuti. In tutto venticinque minuti di inattività. Cosa ha causato le interruzioni? Si possono prevenire?
Tempo di risposta
Il tempo medio di risposta delle API è duecento millisecondi. Il tempo di risposta P95 è cinquecento millisecondi (il 95 per cento delle richieste è più veloce, il cinque per cento è più lento). Il P99 è un secondo. Tempi di risposta lenti capitano ogni tanto. Sono accettabili?
Tasso di errore
Una percentuale dell'uno per cento delle richieste API ha restituito un errore. In aumento rispetto allo zero virgola cinque per cento della settimana scorsa. Il tasso di errore è raddoppiato. Cosa è cambiato? Una query del database è più lenta. I tempi di risposta sono aumentati. I clienti vanno in timeout e riprovano. Serve un'indagine.
Pool di connessioni del database
Il pool ha cento connessioni. Al momento ce ne sono cento aperte (uso completo). Non ci sono altre connessioni disponibili. Se arriva un'altra richiesta, va in coda. L'utente aspetta. Il pool è alla capacità massima. Bisogna aumentare il pool o ridurre l'uso.
Tasso di successo della cache
La cache risponde il cinquanta per cento delle volte. Il cinquanta per cento del traffico non ha bisogno di una query al database. Un tasso di mancata risposta del cinquanta per cento è accettabile per la maggior parte dei siti. Sotto il quaranta per cento il database è sovraccarico. Sopra il settanta per cento stai usando troppa cache.
Esempio reale: dashboard di prodotto e operazioni di un SaaS
Metriche di prodotto
Nuova funzione dashboard: lanciata nel mese uno. Utenti idonei: cinquemila (clienti con più di dieci punti dati). Utenti che hanno creato una dashboard: mille. Tasso di adozione: venti per cento. In linea con l'obiettivo.
Dei mille che hanno creato una dashboard: Giornalieri attivi: seicento. Buon coinvolgimento. Settimanali attivi: novecento. La maggior parte la usa almeno ogni settimana. Abbandonati: cento. Dieci per cento di abbandono.
Impatto sulla fidelizzazione: i clienti con dashboard attive hanno il due per cento di abbandono mensile. I clienti senza dashboard hanno il quattro per cento di abbandono mensile. La dashboard riduce l'abbandono di due punti. Per una base di mille clienti sono venti clienti. A cento dollari di valore mensile per cliente, sono duemila di ricavi risparmiati al mese. Ventiquattromila all'anno.
Metriche delle operazioni
Disponibilità del mese scorso: 99,92 per cento. Obiettivo: 99,95 per cento. Abbiamo mancato l'obiettivo.
Interruzioni: Un incidente: dieci minuti, pagamenti fuori servizio. Causa: il failover del database ha impiegato troppo tempo. Un incidente: quindici minuti, picco di timeout delle API. Causa: un'impennata del traffico più una query lenta del database.
Tempo di risposta: Medio: centocinquanta millisecondi. Buono. P95: trecento millisecondi. Accettabile. P99: un secondo. È troppo alto. L'uno per cento dei clienti aspetta un secondo. Serve ottimizzare.
Tasso di errore: zero virgola otto per cento. In aumento rispetto allo zero virgola quattro per cento di due settimane fa. L'indagine mostra: gli errori dei pagamenti sono aumentati perché il fornitore dei pagamenti ha avuto un'interruzione la settimana scorsa (non è colpa nostra), gli errori delle API sono aumentati perché abbiamo rilasciato una modifica al codice che ha rotto un endpoint (è colpa nostra).
Database: Tempo medio delle query: trenta millisecondi. Utilizzo del pool di connessioni: ottanta per cento. Sano. Tasso di query lente: zero virgola due per cento. Accettabile.
Tasso di successo della cache: sessantacinque per cento. Sano.
Collegare le dashboard di prodotto e di operazioni
L'adozione delle funzioni dipende dalle prestazioni del sistema. Se il sistema è lento, l'adozione ne soffre. La nuova funzione dashboard ha una bassa adozione. Controlla la dashboard delle operazioni. Il tempo di risposta P99 è un secondo. Gli utenti avvertono lentezza quando aprono la dashboard. Aggiungi all'indagine: la lentezza sta causando la bassa adozione? Se sì, ottimizza prima le prestazioni del sistema. Poi misura di nuovo l'adozione.
Le prestazioni del sistema si misurano sulla disponibilità, non sull'impatto delle funzioni. Ma l'impatto delle funzioni dipende dalla disponibilità. Collega le due dashboard. Quando le metriche delle operazioni peggiorano, peggiorano anche quelle di prodotto.
Domande frequenti
Ogni quanto il responsabile di prodotto dovrebbe controllare l'adozione della funzione?
Prima settimana: ogni giorno. La funzione è appena stata lanciata, la curva di adozione è la più ripida. Bisogna cogliere subito i problemi. Settimane da due a quattro: tre volte a settimana. La curva di adozione si appiattisce. Bastano aggiornamenti settimanali. Dopo il primo mese: ogni settimana. L'adozione si è stabilizzata o cresce in modo costante. Basta un controllo settimanale. Eccezione: se la funzione è critica o se l'adozione iniziale è sotto l'obiettivo, il monitoraggio quotidiano continua finché il problema non è risolto. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
Qual è un tasso di adozione accettabile per settimana?
Settimana uno: dal cinque al quindici per cento (le persone stanno provando). Settimana due: dal dieci al trenta per cento (il passaparola si diffonde). Mese uno: dal venti al cinquanta per cento (tasso stabilizzato). Cambia da funzione a funzione. Le funzioni di gioco possono raggiungere il novanta per cento di adozione. Le funzioni di conformità magari solo il dieci per cento. L'obiettivo dovrebbe basarsi sul segmento di utenti e sull'importanza della funzione, non su un benchmark generico. Prima del lancio decidi: questa funzione è per tutti o solo per un segmento? Questo determina l'obiettivo.
Come distinguiamo tra adozione e coinvolgimento?
L'adozione è provare la funzione (l'hanno usata almeno una volta). Il coinvolgimento è usarla ripetutamente (ogni giorno, settimana, mese). Una funzione può avere alta adozione e basso coinvolgimento (tutti l'hanno provata, pochi sono rimasti). Può avere bassa adozione e alto coinvolgimento (pochi l'hanno provata, ma chi l'ha provata l'ha amata). Contano entrambe le metriche. Alta adozione più alto coinvolgimento è un successo. Basso coinvolgimento significa che la funzione non risolve un problema vero. Bassa adozione significa un problema di visibilità.
La dashboard di prodotto dovrebbe includere i feedback dei clienti o solo le metriche?
Entrambi. Le metriche dicono cosa fanno i clienti. I feedback dicono perché. Cinquecento utenti hanno abbandonato la funzione (metrica). Il feedback dice «la funzione è difficile da trovare» oppure «la funzione non risolve il mio problema» (il perché). Le metriche senza feedback sono incomplete. Aggiungi una sezione di feedback con i primi tre motivi di abbandono, in base ai ticket di assistenza e ai sondaggi. Come fare: aggiungi un campo commento alla funzione. Ogni settimana: leggi i primi venti commenti degli utenti e raggruppali per temi. Riporta i temi nella dashboard.
Come fissiamo gli obiettivi per disponibilità e tempo di risposta?
Basa gli obiettivi sull'impatto sui clienti e sugli standard del settore. Per il checkout di un negozio online: disponibilità 99,9 per cento, tempo di risposta sotto i due secondi. Per un sito di marketing: disponibilità 99 per cento, tempo di risposta sotto i tre secondi. Per gli strumenti interni: disponibilità 95 per cento, tempo di risposta sotto i cinque secondi. Più il servizio è critico, più rigido è l'obiettivo. Quando fissi l'obiettivo, sappi quale livello di investimento serve. Una disponibilità del 99,99 per cento (quattro nove) costa da tre a quattro volte più di una del 99 per cento (due nove). Assicurati che l'obiettivo valga il costo.
La dashboard delle operazioni dovrebbe far partire avvisi o solo mostrare lo stato?
Entrambi. La dashboard mostra lo stato attuale. Gli avvisi scattano quando si superano le soglie. Se il tasso di errore supera l'uno per cento per cinque minuti, scatta un avviso. L'avviso va al tecnico reperibile, che indaga. La dashboard serve per il monitoraggio durante l'orario normale. L'avviso serve fuori orario o in situazioni critiche. Nessuno dei due da solo basta. Una dashboard senza avvisi significa che i problemi si scoprono in orario di lavoro. Un avviso senza dashboard significa che il team non vede i peggioramenti lenti finché l'avviso non scatta. Usali insieme.