OKR (Objectives and Key Results)

Un Objective è una dichiarazione d'intenti breve e qualitativa — memorabile, direzionale e leggermente scomoda da sottoscrivere. "Diventare lo strumento predefinito per l'onboarding dei nuovi team di prodotto" è un Objective. Non è misurabile di per sé, e non deve esserlo.

Ogni Objective porta con sé tre-cinque Key Results: risultati numerici specifici che dimostrano che l'Objective è stato raggiunto. Un buon Key Result ha la forma "portare la metrica X da A a B entro una data" — per esempio "portare il tasso di attivazione dal 34% al 50%" o "ridurre il tempo mediano al primo valore da 9 a 3 giorni". Se si può discutere se un Key Result è stato raggiunto, è scritto male. La disciplina vuole che l'Objective sia ispiratore e i Key Results inequivocabili.

La maggior parte dei team gestisce gli OKR con cadenza trimestrale, spesso annidati sotto OKR aziendali annuali, con un check-in leggero settimanale o bisettimanale per aggiornare la confidenza. Alla chiusura del trimestre, ogni Key Result viene valutato, di solito su una scala da 0,0 a 1,0.

Una convenzione ampiamente citata — resa popolare dall'adattamento di Google della pratica originale di Andy Grove in Intel — è che una media di 0,7 sia l'obiettivo, non 1,0. La logica: se si ottiene costantemente 1,0, i Key Results erano sottodimensionati. Gli OKR "stretch" o aspirazionali vengono fissati deliberatamente in modo che raggiungere il 60-70% sia un risultato forte. Funziona solo se la valutazione resta disaccoppiata dalle revisioni delle performance; nel momento in cui gli OKR alimentano direttamente la retribuzione, le persone fissano obiettivi sicuri e lo stretch evapora.

Il fallimento più comune è scrivere i Key Results come una lista di attività — output — invece di outcome. "Lanciare il nuovo flusso di onboarding" è un output — si può lanciarlo senza muovere alcuna metrica. "Aumentare la retention della settimana 1 al 45%" è un outcome. Quando i Key Results sono solo una roadmap camuffata, gli OKR diventano teatro: il team segna tutto come completato, nulla cambia, e la fiducia nel framework si erode.

Altri fallimenti ricorrenti: troppi OKR (più di tre Objectives per team frammenta la concentrazione); farli cascare rigidamente dall'alto verso il basso, così diventano assegnazioni invece di impegni; fissarli e non rivederli mai fino al giorno della valutazione; e legare i punteggi ai bonus, il che uccide l'onestà che gli obiettivi ambiziosi richiedono. Gli OKR sono uno strumento di focalizzazione e allineamento, non un tracker di progetto — l'obiettivo è cambiare ciò che accade, non registrare ciò che è stato costruito.

La parte più difficile degli OKR nella pratica è mantenere i Key Results collegati a un numero vivo invece che a una cifra che qualcuno aggiorna a mano in uno slide ogni venerdì. Quando la metrica vive in un foglio di calcolo, i check-in vanno alla deriva e la valutazione diventa un dibattito.

Un sistema operativo di prodotto aiuta qui mantenendo i segnali sottostanti su una base condivisa: AIOProductOS unisce analytics di prodotto, ricavi (MRR/ARR) e comportamento dei clienti in un unico record, e il suo modulo OKR può tracciare un Key Result rispetto a una metrica viva della base — così un obiettivo come "aumentare il tasso di attivazione" o "far crescere i ricavi da espansione" legge dai medesimi dati con cui lavora il resto del team, invece che da un'istantanea statica. Questo mantiene la conversazione focalizzata sul fatto che l'outcome si stia muovendo, che è l'intero scopo del framework.