OKR e KPI: differenze e utilizzi

Gestire e sviluppare un prodotto implica comprenderne la prestazione e il progresso. Il successo (o fallimento) di un’iniziativa è stabilito con chiarezza solo se esiste un quadro di riferimento, stabilito a priori, che dia un senso alle nostre misurazioni. OKR e KPI sono concetti differenti ma con importanti aree di sovrapposizione.

Misurare la performance vs gestire lo sviluppo

Gli OKR – Objectives and Key results – sono orientati alla gestione dello sviluppo di un prodotto, progetto o spesso di un’intera strategia aziendale. Esistono svariati altri framework che svolgono compiti analoghi, e alcuni di questi poggiano sull’idea di KPI: ad esempio i KPI Tree, i KPI Graph o le Balanced Scorecards. Presa singolarmente, invece, l’idea di KPI – Key Performance Indicator – fa semplicemente riferimento a una modalità di misurazione della performance.

OKR e KPI sono ampiamente utilizzati e non sorprende che la differenza tra i due sia oggetto di interesse. Tuttavia, è bene dire da subito che non sono idee in contrapposizione e che non si riferiscono ad aspetti identici dell’analisi e sviluppo dei prodotti.

OKR

Come dice il nome stesso, gli OKR contengono due elementi fondamentali: gli obiettivi (objectives) e i risultati chiave (key results).

Gli obiettivi descrivono un esito desiderabile: un cambiamento che voglio vedere accadere nell’azienda o area di prodotto. Un obiettivo non è descritto quantitativamente: deve solo spiegare l’esito in maniera accurata. Inoltre, è buona pratica assicurarsi che il team possa perseguire l’obiettivo in maniera largamente indipendente; eventuali dipendenze con altri team vanno chiarite e concordate in fase di preparazione degli OKR.

Alcuni esempi di obiettivi:

• “Migliorare la user retention“
• “Rilasciare il nuovo prodotto in modalità beta”
• “Espandere l’offerta multilingua della piattaforma”

I risultati chiave servono a misurare quanto l’obiettivo possa considerarsi compiuto. Un buon risultato chiave deve essere SMART – Specific, Measurable, Attainable, Relevant, Time Bound:

• Specific: non vago, inequivocabile. Un buon esempio key result: “Il 5% degli utenti registrati torna sul sito almeno 2 volte ogni mese”. Un cattivo esempio: “5% degli utenti sono fidelizzati”.
• Measurable: quantificabile. Buon esempio: “<10% degli utenti che consultano la documentazione apre un ticket di richiesta supporto”. Cattivo esempio: “La documentazione fornita agli altri team è sufficiente per l’utilizzo dei servizi”.
• Attainable: realistico. Buon esempio: “p99 del tempo di risposta dell’API < 0.2s”. Cattivo esempio: “L’API non restituisce mai una risposta con un ritardo superiore a 1 secondo”.
• Relevant: deve fornire una misurazione rilevante per valutare l’obiettivo a cui è collegato. Buon esempio: “80% delle funzionalità concordate ha passato test e QA”. Cattivo esempio: “80% del tempo di sviluppo dei developer speso sulle funzionalità concordate per il nuovo prodotto”.
• Time bound: delimitato nel tempo. Buon esempio: “Durata media sessione +10% ultima settimana Q2 rispetto a prima settimana Q2”. Cattivo esempio: “Durata media sessione +10%”.

Il ciclo di vita di un OKR

Gli OKR tipicamente coprono un arco temporale definito: un trimestre, un semestre, un anno… Alla fine del periodo segue una revisione per capire dove ci si trova rispetto agli obiettivi concordati. Gli OKR possono essere trasposti nel nuovo ciclo, rivisitati, oppure sostituiti da nuovi OKR: essendo un riflesso della strategia dell’azienda, devono di volta in volta essere adattati agli esiti e ai cambiamenti che si desidera conseguire.

Vi sono inoltre modi diversi di misurare i progressi. È possibile misurare i vari KR in maniera binaria (conseguito vs non conseguito) oppure si possono assegnare dei punteggi. Nella mia azienda, ad esempio, era consuetudine usare una scala da 0 a 1, dove i punteggi consentiti erano 0 – 0,3 – 0,5 – 0,7 – 1.

Un key result legato all’obiettivo “Migliorare la user retention” potrebbe essere articolato come segue:

Un O è solitamente legato a più KR: la valutazione del punteggio attribuibile a un obiettivo può semplicemente essere la media dei punteggi ottenuti per i singoli KR.

Puntare in alto

La tendenza nei team poco abituati a lavorare con gli OKR è quella di impostare dei risultati chiave modesti. La soddisfazione di arrivare a fine trimestre e aver conseguito una sfilza di “1” è comprensibile, ma qual è l’utilità?

In realtà, gli OKR devono essere calibrati in maniera ambiziosa ma non irrealizzabile. Nel mio team, la regola generale era che uno 0.3 doveva posizionarsi là dove ci aspettavamo di arrivare una volta fatto il minimo indispensabile mentre lo 0.7 era segno di un lavoro eccellente. L’1 era il canestro segnato da metà campo quanto la squadra è sotto di due punti: non accade a ogni partita e sarebbe irrealistico aspettarselo.

Gli OKR, insomma, non sono una scusa per darsi delle pacche sulle spalle a vicenda: servono a riflettere sugli obiettivi, a indicare le leve necessarie per raggiungerli e misurare la performance in maniera realistica.

Uno strumento di allineamento

La mia limitata esperienza con gli OKR me ne ha fatto apprezzare un aspetto in particolare: l’utilità nel creare allineamento tra le varie parti dell’azienda. Tipicamente, infatti, venivano definiti degli OKR a livello aziendale a cui le business unit sottostanti si rifacevano per stabilire i propri.

Ad esempio, un obiettivo di un’azienda e-commerce potrebbe essere “Aumentare la soddisfazione dei clienti”. La logistica potrebbe impostare come obiettivo collegato “Ridurre i tempi di consegna”, mentre l’area responsabile per gli acquisti potrebbe considerare di “Estendere il numero di brand premium disponibili sul sito”. Le eventuali sotto-unità di queste aree, dovendo sviluppare i propri OKR, andrebbero a loro volta a costruire su quanto definito al livello superiore.

L’allineamento avviene in orizzontale così come in verticale. Gli OKR possono essere un eccellente strumento per anticipare dipendenze tra dipartimenti e concordare obiettivi comuni o parzialmente sovrapposti. Ad esempio, un dipartimento responsabile per tracciamento e analisi dati potrebbe includere un obiettivo di “Miglioramento nella qualità dei dati di analytics” e allinearsi con il dipartimento sicurezza e frodi perché tra i loro obiettivi vi sia il “Miglioramento nel blocco del traffico proveniente da bot”.

KPI

Come differiscono dunque i KPI dagli OKR?

KPI è l’acronimo di Key Performance Indicator: indicatori chiave di prestazione. Dunque, non indicatori qualsiasi bensì indicatori chiave. La denominazione in sé indica la necessità di selezionare tali indicatori in modo che la loro lettura fornisca delle informazioni di particolare rilievo rispetto alla prestazione che intendo misurare.

In un certo senso, i KPI tendono a essere più statici degli OKR perché riflettono un’area del business che vogliamo produca dei risultati (o dei miglioramenti) consistenti nel tempo. Se un KPI entra in “zona rossa”, l’aspettativa è in genere che vi sia un’azione immediata per capire cosa non sta funzionando.

Buoni KPI. Cattivi KPI.

Quali sono degli esempi di buoni KPI? Come sempre nella vita, la risposta più adeguata è: dipende. È evidente, per esempio, che i KPI legati al lancio di un MVP saranno molto diversi rispetto a quelli monitorati da un’azienda consolidata.

In realtà vi sono dei principi di massima sempre validi: ad esempio, la regola SMART già discussa per i KR. Inoltre, l’utilità di alcui KPI è relativamente condivisa tra realtà simili: l’esempio forse più evidente è il tasso di conversione per un sito e-commerce.

Ciò detto, fare copia-incolla dei KPI di un’altra azienda non aiuta certo a definire il successo di un prodotto. Spesso si deve scendere nei dettagli e capire quali KPI sono rappresentativi dei comportamenti e fenomeni da analizzare.

Un esempio: aumentare l’engagement

Prendiamo ad esempio il product manager di una piattaforma video intenzionato ad aumentare l’engagement. Una rapida ricerca su Google fornirà vari suggerimenti di buoni engagement KPI: numero di pagine visitate, tempo medio delle sessioni, CTR, bounce rate, … Viene infine presa la decisione che il KPI da monitorare è il tempo medio delle sessioni. Supponiamo, tuttavia, il seguente problema: la distribuzione della durata delle sessioni è molto sbilanciata. Vi sono alcuni utenti che si impegnano in vere e proprie maratone, consumando documentari di svariate ore; molti altri utenti invece chiudono il browser immediatamente dopo aver visto esattamente un video di gattini della durata di pochi secondi.

Evidentemente, è sufficiente l’acquisizione di una manciata di utenti appassionati di documentari per sbilanciare il KPI scelto (durata media delle sessioni). È però corretto attribuire tutto questo peso all’acquisizione di pochi utenti? Di converso, un problema nel sito che porti a un aumento nella bounce rate in una certa area del sito potrebbe azzoppare il KPI: sarebbe certamente un problema, ma è accurato inquadrarlo come problema di engagement?

La realtà è che in questo caso la durata media delle sessioni non è un buon KPI. Piuttosto, potrei voler guardare al numero assoluto di utenti che spedono più di x minuti (20? 30? 120?) sul sito in una settimana – una metrica poco sensible agli outliers (siano questi appassionati di documentari o di video di gattini) e non impattata dalla bounce rate.

KPI e metriche

La “K” di KPI non è messa lì a caso. Gli indicatori di prestazione sono, infatti, sempre troppi per essere considerati in contemporanea: è essenziale saper scegliere quali danno informazioni chiave sulla prestazione, e quali sono accessori (dunque da tenere semplicemente sott’occhio).

Inoltre, non tutti gli indicatori sono utili per la gestione del prodotto. Alcuni sono semplicemente poco pratici nella misurazione, o non variabili a sufficienza perché forniscano indicazioni che possano essere sfruttate su base giornaliera o settimanale.

Ad esempio, in uno dei team in cui ho lavorato ci occupavamo di fornire prodotti e servizi a supporto della creazione di alcuni contenuti specifici. Il processo di creazione dei contenuti era altamente manuale e suddivisibile in un numero ben definito di passaggi discreti – una decina circa. Tra i KPI che inizialmente ci eravamo preposti di monitorare vi era il “numero di passaggi nel processo di creazione automatizzati tramite uno o più dei nostri servizi”.

In sé, la metrica poteva aver senso. Tuttavia, durante una revisione ci venne chiesto: “potete mettere quella metrica su una dashboard e utilizzarla settimanalmente per prendere decisioni sul vostro prodotto, o per capire se qualcosa sta andando male?”. No: era una metrica, ma non un KPI. Sarebbe stato un buon key result (dato il giusto obiettivo), ma non era un buon KPI.

Misurare il successo tramite i KPI

L’immagine di un KPI spalmato su una dashboard, possibilmente accessibile a tutti, suggerisce che non siano lo strumento migliore per gestire lo sviluppo di un prodotto, quanto un guardrail per prevenire schianti rovinosi. Non è necessariamente esatto.

L’idea di KPI, in sé, non è particolarmente densa di significato. Un key result può benissimo fare riferimento a un KPI, ad esempio: i KPI possono dunque essere utilizzati nel contesto di sviluppo, purché inseriti in un framework adeguato.

One KPI to rule them all

Un esempio (non l’unico!) è la definizione di una North Star Metric (link in inglese) o NSM – una stella polare che guidi lo sviluppo del nostro prodotto.

In questo caso, viene definito un singolo indicatore che funziona da proxy per la definizione di successo del nostro prodotto. In particolare, la NSM lega il bisogno che il prodotto intende accomodare al successo che il business otterrà se il prodotto ha successo.

Una volta stabilita una NSM, si individuano quali KPI le sono correlati e la influenzano direttamente. Questo fornisce ai team di prodotto un riferimento e un’indicazione su quali KPI sia necessario migliorare per avere un impatto sugli obiettivi strategici dell’azienda.

La scelta di una NSM è strettamente legata al valore che il prodotto mira a generare e all’attuale strategia. Immaginiamo un’azienda di vendite online il cui focus strategico attuale sia quello di espandere la base clienti. Quest’azienda, inoltre, sa che i clienti che effettuano un secondo acquisto nel primo mese dalla registrazione hanno il 150% di probabilità in più di diventare clienti ricorrenti rispetto ai clienti che hanno acquistato una sola volta. Invece di impostare una NSM semplicemente basata su reddito o profitto, potrebbero focalizzarsi su qualcosa come “Numero di nuovi clienti che acquistano due volte entro i primi 30 giorni dalla registrazione”.

Sembra una NSM inutilmente involuta, tuttavia può essere chiaramente legata a KPI di “livello inferiore” e ad azioni volte a influenzarla: è chiaro, per esempio, che si debba puntare ad attirare nuovi clienti, e a riattivare i clienti dopo l’effettuazione del primo acquisto. Un primo KPI collegato probabilmente sarà semplicemente il “Numero di nuovi clienti mensile”; un altro potrebbe essere la “Percentuale di utenti che si registrano alla newsletter dopo il primo acquisto” (in quanto la newsletter è un potente strumento di riattivazione).

Scegli l’uno o l’altro. O entrambi. Ma scegli.

In sintesi, la principale differenza tra OKR e KPI riguarda gli usi: gestione dello sviluppo del prodotto in un caso, misurazione della performance nell’altro. Ho introdotto l’idea di Northstar Metric per mostrare un altro esempio di gestione dello sviluppo del prodotto che fosse basato sui KPI. OKR e NSM sono diversi ma non incompatibili (link in inglese) e l’utilizzo di uno o dell’altro dipende da una varietà di fattori tra cui la cultura aziendale e la modalità di collaborazione tra team.

Ciò che unifica tutti questi concetti è che aiutano a osservare il proprio prodotto con distanza, arginando il ruolo di istinto e predilezioni nel momento in cui serve prendere decisioni oggettive. Sono anche ottimi strumenti per creare allineamento tra team e per dare definizioni condivise a concetti quali “successo di un’iniziativa” o “trend preoccupante”. Non è sempre evidente quale sia lo strumento più adatto a misurare il progresso di un prodotto: quel che è certo è che non usarne nessuno è un errore.

Aggiornamento: se desideri approfondire il tema, abbiamo pubblicato una guida agli OKR.