Guida alla gestione del prodotto OKR per obiettivi orientati al risultato

Contenuti:

• Cosa sono gli OKR?
• Chi ha creato il framework OKR e perché?
• Quali sono i limiti degli OKR?
• I vantaggi degli OKR per i leader
• Il valore degli OKR per le funzioni di gestione del prodotto
• Stabilire robusti OKR di prodotto
• Revisione dell'avanzamento dell'OKR del prodotto
• L'interazione tra OKR e strategia di prodotto
• Il ruolo degli OKR nella scoperta del prodotto
• In che modo OKR e Scrum interagiscono in sinergia tra loro
• Utilizzo degli OKR per il processo decisionale sui prodotti
• Trappole OKR da evitare

Un segno di un leader esecutivo di successo è la capacità di guidare progressi significativi verso una data visione del business. Mentre i leader devono portare sul tavolo una miriade di abilità e talenti, uno specifico modello mentale chiamato Obiettivi e risultati chiave (OKR) può aiutarti a raggiungere questi progressi con meno tempo e fatica.

Abbiamo scritto questa guida agli OKR per i dirigenti C-suite e i leader di prodotto che cercano di stabilire e raggiungere obiettivi aziendali ambiziosi. Implementando gli OKR per te stesso e per le funzioni che gestisci, avrai la possibilità di identificare ciò che conta per la tua azienda, fissare obiettivi per ciò che i tuoi team dovrebbero raggiungere, monitorare i progressi verso gli obiettivi e diagnosticare la causa principale per risultati inaspettati.

Cosa sono gli OKR?

Il quadro degli obiettivi e dei risultati chiave ( quadro OKR ) è una struttura flessibile e orientata all'azione per identificare le priorità aziendali, stabilire obiettivi misurabili orientati ai risultati e ispirare azioni a tutti i livelli dell'organizzazione per creare valore per i clienti.

Molte organizzazioni hanno creato i propri processi specifici attorno agli OKR. Abbiamo scritto questa guida per aiutarti a modellare e plasmare i processi che hanno più senso per le tue esigenze e il tuo contesto, piuttosto che per "importare" un particolare sapore da una particolare azienda che potrebbe fare più male che bene per la tua specifica organizzazione.

Per iniziare, ogni implementazione OKR contiene due componenti: obiettivi e risultati chiave .

• Gli obiettivi sono aspirazioni qualitative che rappresentano la direzione verso cui l'azienda cerca di muoversi, piuttosto che uno stato finale tangibile
• I risultati chiave sono obiettivi quantitativi che rappresentano i progressi compiuti dai team verso l'obiettivo

Ogni squadra dovrebbe avere un unico obiettivo per il trimestre. I team dovrebbero quindi decidere su più risultati chiave che supportano questo obiettivo.

Ad esempio, immagina un'azienda che vende pentole. L'obiettivo di uno dei loro team potrebbe essere "diventare un fornitore affidabile di pentole per cuochi casalinghi".

Questa squadra potrebbe scegliere i seguenti tre risultati chiave per supportare questo obiettivo:

• Diminuire i tassi di rimborso dallo 0,5% allo 0,2%
• Aumenta i tassi di acquisto ripetuto dal 5% al ​​15%
• Migliora la consapevolezza del marchio top-of-mind dal 10% al 25%

La combinazione specifica di obiettivi qualitativi e risultati chiave quantitativi è potente perché guida un'azione diretta e sinergica tra tutti i membri del team.

Immagina una squadra che aveva solo obiettivi ma nessun risultato chiave. Questo team non avrebbe una visione sufficiente dei progressi compiuti verso tali obiettivi e non saprebbe quali comportamenti modificare o azioni intraprendere per ottenere progressi significativi.

Inoltre, i compagni di squadra potrebbero scegliere individualmente di perseguire obiettivi in ​​modi che hanno senso per loro, ma finire per non allinearsi bene insieme.

Ad esempio, una persona potrebbe cercare di scegliere come target gli account aziendali per la vendita di pentole, mentre un'altra persona potrebbe cercare di scegliere come target le PMI. Oppure, una persona potrebbe cercare di aumentare i prezzi per dimostrare la forza e il prestigio del marchio, mentre un'altra persona potrebbe cercare di diminuire i prezzi per aumentare la convenienza e l'accessibilità.

Utilizzando questi esempi, possiamo facilmente vedere come i risultati chiave condivisi a livello di team aiutano a mantenere i compagni di squadra sulla stessa pagina.

D'altra parte, immagina una squadra diversa che ha avuto solo risultati chiave ma nessun obiettivo. Questo team non avrebbe il contesto aziendale per fare i giusti compromessi e potrebbe ottimizzare in modo ristretto le proprie metriche a breve termine a scapito del successo aziendale a lungo termine.

Inoltre, potrebbero soffrire di un sovraccarico di informazioni nel tentativo di destreggiarsi tra più metriche contemporaneamente, senza un obiettivo generale che indichi loro a quali metriche dare la priorità e in quali situazioni.

Pertanto, abbinando insieme aspirazioni qualitative e obiettivi quantitativi, allineiamo e motiviamo i team a intraprendere azioni che faranno progredire le nostre attività.

Prima di approfondire le migliori pratiche per l'implementazione degli OKR, discutiamo innanzitutto del motivo per cui sono stati inventati gli OKR e dell'impatto che questo framework ha avuto su aziende note.

Chi ha creato il framework OKR e perché?

Il CEO di Intel Andy Grove ha istituito il framework OKR negli anni '70 per consentire ai lavoratori a tutti i livelli in tutte le funzioni di identificare e acquisire valore aziendale.

La sua motivazione principale per la creazione di un nuovo "manuale operativo" per le aziende era perché aveva visto in prima persona i problemi del controllo manageriale dall'alto verso il basso e l'impotenza in prima linea quando lavorava alla Fairchild Semiconductor.

Grove ha concepito gli OKR come un motore per l'apprendimento , piuttosto che un sistema di gestione delle prestazioni. L'obiettivo degli OKR non era quello di premiare le persone per aver battuto i bersagli o punire le persone per i bersagli mancati. Invece, sia i manager che i dipendenti diretti dovevano riflettere su ciò che avevano appreso in base ai progressi compiuti sugli OKR, indipendentemente dal fatto che avessero superato, raggiunto o mancato i propri obiettivi.

Grove ha costruito il framework OKR sopra il sistema di "gestione per obiettivi" (MBO) che Peter Drucker ha condiviso nel suo libro del 1954 The Practice of Management, in cui Drucker consigliava ai manager di fissare obiettivi chiari da raggiungere per i loro rapporti diretti.

Tuttavia, Grove ha cercato di evitare i principali svantaggi derivanti da una struttura così rigida che centralizzava troppo il processo decisionale nelle mani di manager e supervisori. Nel suo libro High Output Management del 1983, Grove fornì questa critica: "Se il supervisore si affida meccanicamente al sistema MBO per valutare le prestazioni del suo subordinato, o se il subordinato rinuncia a sfruttare un'opportunità emergente perché non era un obiettivo specifico, allora entrambi si stanno comportando in modo meschino”.

Ecco perché gli obiettivi sono tipicamente fissati da leader e manager, e perché i risultati chiave sono tipicamente fissati da team e individui. In questo modo, supervisori e subordinati collaborano per guidare il progresso aziendale di alto livello attraverso il successo in prima linea.

Il framework OKR è stato poi ulteriormente reso popolare da John Doerr nel 1999, quando ha portato questo framework a Google. A quel tempo, Google aveva meno di 50 dipendenti e i suoi fondatori Larry Page e Sergey Brin erano studenti di dottorato solo un anno prima.

Come condivide Doerr, “Kleiner Perkins aveva appena investito in Google e, in qualità di forte sostenitore degli OKR, mi sono offerto di presentare il sistema OKR a Larry, Sergey e al gruppo dirigente. Larry e Sergey hanno visto immediatamente il valore. A loro piaceva avere una serie trimestrale di priorità per l'azienda.

Concentrando i propri sforzi su queste priorità, Google è diventato rapidamente un tesoro per gli utenti di Internet che in precedenza si erano affidati a portali come Yahoo o Lycos per navigare sul Web. L'IPO di Google è avvenuta nel 2004, appena 5 anni dopo l'implementazione degli OKR in Google.

Quali sono i limiti degli OKR?

Ora vediamo come gli OKR hanno aiutato Intel a crescere da $ 1,9 miliardi a $ 26 miliardi di fatturato annuo sotto la guida di Grove, e come gli OKR hanno aiutato Google a diventare il motore di ricerca dominante su Internet.

Ma gli OKR non sono proiettili d'argento: dobbiamo assicurarci di non abusare accidentalmente degli OKR. Nello specifico, gli OKR non dovrebbero sostituire né la visione aziendale né la strategia aziendale.

La visione definisce la direzione generale dell'azienda nel corso di anni e decenni. Gli OKR sono fissati a livello trimestrale e sono quindi radicati nell'esecuzione quotidiana. Senza una visione guida, i leader non possono creare OKR che facciano progressi significativi a lungo termine, perché la definizione stessa di "progresso significativo" è stabilita dalla visione.

E gli OKR non possono soppiantare la strategia aziendale; piuttosto, gli OKR aiutano a dare vita alle strategie. Una vera strategia richiede una diagnosi e una serie di guardrail per guidare i compromessi, mentre gli OKR si concentrano sull'esecuzione per ottenere risultati che si adattano a quei guardrail predefiniti.

Non ci addentreremo ulteriormente in "come impostare una visione convincente" o "come creare una strategia vincente", poiché questi argomenti non rientrano nell'ambito di questa guida. Se desideri saperne di più sulla visione o sulla strategia in particolare, teniamo workshop aziendali sia sulla visione che sulla strategia presso Product Teacher.

Finora, abbiamo imparato da dove provengono gli OKR e abbiamo una buona definizione operativa di cosa sono gli ORK. Ma, come leader, perché dovremmo usare OKR piuttosto che approcci alternativi?

I vantaggi degli OKR per i leader

L'utilizzo del framework OKR offre ai leader cinque vantaggi chiave:

1. Capacità di misurare i progressi

In primo luogo, gli OKR ci incoraggiano a cristallizzare gli obiettivi dell'azienda in obiettivi facilmente misurabili.

In altre parole, gli OKR sono una funzione forzante che ci fa verbalizzare cosa ci interessa esattamente per l'azienda, perché ci interessa e quali risultati contano. Creiamo responsabilità e trasparenza ed evitiamo di "raccogliere con cura" buoni risultati in seguito.

Supponiamo che un risultato chiave per la tua organizzazione sia "aumentare i tassi di acquisizione di nuovi clienti del 10% in questo trimestre". Se un team finisce per "aumentare il valore del contratto per i clienti attuali" ma non "aumentare i tassi di acquisizione di nuovi clienti", sai immediatamente come leader che questo risultato non era quello che avevi cercato di ottenere.

Forse, in qualità di leader, avevi identificato che "acquisire nuovi clienti" era fondamentale per guidare la crescita virale, in cui ogni nuovo cliente acquisito aumenta la probabilità di acquisire il prossimo nuovo cliente.

Ma se avessi incaricato il tuo team solo di "aumentare le entrate", allora avrebbero creduto che "aumentare il valore del contratto" fosse un buon modo per aumentare le entrate senza capire che la tua strategia desiderata era incentrata sull'acquisizione di nuovi clienti.

Evitare il cherry picking è particolarmente importante per l'esecuzione di test A/B. Qualsiasi esperimento potrebbe facilmente produrre modifiche su dozzine di possibili metriche e qualcuno potrebbe facilmente selezionare "solo risultati positivi" per far sembrare buoni i propri test quando i loro risultati non erano riusciti a creare un valore reale per i clienti.

Pertanto, impostando in anticipo le metriche di successo, gli OKR promuovono responsabilità e trasparenza.

2. Allineamento degli sforzi verso gli obiettivi aziendali

In secondo luogo, quando i team hanno chiarezza su quali metriche cercano di spostare, allineano i loro sforzi verso tali metriche. Quando le metriche del team si inseriscono negli obiettivi aziendali, possiamo consentire ai nostri team di prendere decisioni decentralizzate ad alta velocità per aiutare l'azienda ad avere successo.

Non appena un determinato team sa quali metriche utilizzerà per misurare i propri progressi, possiamo lasciargli decidere quali iniziative eseguire, quali persone dovrebbero puntare su tali iniziative e quali tipi di processi vorrebbero implementare. Una volta che i nostri team ci convincono che le loro metriche selezionate dimostrano progressi rispetto all'obiettivo aziendale, come leader possiamo entrare in un ruolo di consulenza piuttosto che in un ruolo di esecuzione.

In qualità di leader esecutivi, dovremmo mirare a fare in modo che tutti i team siano "strettamente allineati ma debolmente accoppiati". In altre parole, i team dovrebbero puntare nella stessa direzione aziendale, ma non dovrebbero essere ostacolati dall'intervento o dall'approvazione dei dirigenti.

Quando i leader si sentono obbligati a microgestire ogni dettaglio, diventano significativamente meno efficaci e meno strategici. D'altra parte, quando i team sono responsabilizzati e strettamente allineati, i leader possono concentrarsi su usi più scalabili del proprio tempo e del proprio impegno.

3. Flessibilità al cambiamento basato sugli apprendimenti

In terzo luogo, gli OKR possono e devono cambiare in base a ciò che apprendiamo dai nostri clienti e dai mercati in cui operiamo.

In alcuni ambienti, i team potrebbero decidere che solo tre risultati chiave contano veramente per un determinato obiettivo; in altri ambienti, i team potrebbero decidere di dover tenere traccia di cinque risultati chiave separati.

Inoltre, poiché ogni linea di business attraversa diverse fasi di maturità (ad es. lancio vs. crescita vs. declino) al proprio ritmo, dobbiamo rivalutare regolarmente gli obiettivi di business.

Attraverso il framework OKR, abbiamo i mezzi per cambiare i nostri obiettivi e gli obiettivi dei nostri team per concentrarci sugli sforzi più rilevanti e di maggior valore per i nostri clienti e i nostri investitori.

4. Capacità di telescopio su diversi livelli

In quarto luogo, gli OKR possono essere spostati su diversi livelli; cioè, gli OKR in prima linea possono essere trasformati in OKR per i quadri intermedi, che a loro volta possono essere trasformati in OKR per i dirigenti senior.

Come afferma lo stesso Doerr a proposito del periodo trascorso in Intel: “È stato incredibilmente potente per me vedere gli OKR di Andy Grove [a livello di CEO], gli OKR del mio manager e gli OKR dei miei colleghi. Sono stato rapidamente in grado di legare il mio lavoro direttamente agli obiettivi dell'azienda.

Il valore degli OKR è che possono essere implementati a qualsiasi livello, sia per i CEO che per i dipendenti di prima linea. I “risultati chiave” a livello esecutivo confluiscono in “obiettivi” al livello successivo; e, i risultati dei team di prima linea confluiscono nei risultati per i team esecutivi.

Quando i CEO utilizzano gli OKR per concentrare i propri sforzi, definiscono chiaramente dove dovrebbe dirigersi l'azienda nel trimestre successivo, con obiettivi nitidi e facilmente visualizzabili a livello aziendale.

Da lì, i capi dei vari dipartimenti possono poi convertire ogni target in obiettivi per le rispettive funzioni. E ogni gruppo funzionale può quindi prendere questi obiettivi e creare risultati chiave per i propri team, che poi creano i propri obiettivi e risultati chiave per gli individui.

Guidando questo allineamento telescopico a tutti i livelli, i leader esecutivi possono fornire chiarezza e stimolare la motivazione tra le funzioni e l'anzianità.

5. Coerenza e standardizzazione

Infine, gli OKR ci forniscono un linguaggio universale per guidare i nostri team. Quando disponiamo di coerenza e standardizzazione, alla fine possiamo muoverci più velocemente e più lontano come organizzazione.

Il coordinamento tra i team è uno dei maggiori amplificatori del successo e del fallimento dell'azienda. Consentendo ai team di parlare la stessa lingua, promuoviamo una migliore collaborazione, negoziazione e risoluzione dei problemi.

Quando due team hanno obiettivi contrastanti nel framework OKR, possono lavorare insieme per modificare i rispettivi obiettivi e metriche, in modo che i loro progressi non siano più in conflitto tra loro ma piuttosto si sinergizzino tra loro.

Ad esempio, supponiamo che un team per il successo dei clienti miri a ridurre l'attrito con i conti correnti, mentre un team di vendita potrebbe mirare a raggiungere una varietà di nuovi loghi.

Senza OKR in atto, queste due squadre potrebbero finire per scontrarsi. Se il team di vendita introduce molti nuovi loghi che effettuano un acquisto iniziale ma poi si rifiutano, il team di successo del cliente ne risentirà. E, se il team di successo del cliente costringe il team di vendita a qualificare i loghi prima di consentirne l'acquisto, il team di vendita ne risentirà.

Ma, con gli OKR in atto, questo ipotetico team di successo del cliente può lavorare con le loro ipotetiche controparti di vendita per perfezionare ciascuno dei rispettivi risultati chiave. Il successo dei clienti può misurare i loro progressi rispetto a "logoramento per account qualificati" e le vendite possono misurare i loro progressi rispetto a "conversazioni con nuovi account qualificati".

In questo modo, nessuno dei due team dedica tempo ad account scarsamente qualificati che non troverebbero valore, consentendo all'azienda nel suo insieme di concentrarsi sui clienti che trarrebbero il massimo vantaggio dalle loro offerte.

Il valore degli OKR per le funzioni di gestione del prodotto

Ogni prodotto cerca di creare un enorme valore per i propri clienti, in modo che l'azienda possa quindi acquisire valore per se stessa. Tuttavia, è difficile che i prodotti possano ottenere valore commerciale in molte direzioni, con alcune direzioni che si escludono a vicenda rispetto ad altre direzioni.

Ad esempio, un prodotto dovrebbe concentrarsi sull'acquisizione di nuovi utenti? O dovrebbe concentrarsi sulla promozione di un maggiore coinvolgimento da parte degli utenti esistenti? Forse invece dovrebbe concentrarsi sulla monetizzazione della sua attuale base di utenti? O forse dovrebbe invece guidare la redditività dagli attuali flussi di entrate?

Dobbiamo scegliere in anticipo quale di questi obiettivi dovremmo affrontare in questo trimestre. Dopotutto, concentrarsi su uno di questi obiettivi di solito ha il costo di un altro possibile obiettivo:

• Ottenere più utenti potrebbe richiedere il sacrificio dei profitti per finanziare l'acquisizione di clienti
• Guidare profitti immediati potrebbe richiedere paywall che causano un calo del coinvolgimento degli utenti

Pertanto, l'utilizzo di OKR per guidare la direzione del prodotto può accelerare in modo significativo l'impatto del prodotto sull'azienda.

Come potremmo decidere gli OKR per un team PM? Possiamo utilizzare questo modello OKR di Miro come punto di partenza. Il modello fornito da Miro è già stato precompilato con esempi per una funzione Contenuto e per una funzione Partnership ed eventi.

Compiliamo questo modello con un esempio di gestione del prodotto, quindi. Diciamo che un responsabile del prodotto si pone l'obiettivo di "diventare un partner tecnologico di fiducia per i nostri clienti", con i seguenti tre risultati chiave:

• Aumenta il numero medio di flussi di lavoro completati, per utente, al mese
• Aumentare il numero di utenti attivi mensili
• Aumenta il numero di integrazioni del prodotto

Ogni risultato chiave è quindi guidato da un direttore del prodotto, che converte il risultato chiave specifico in un obiettivo per guidare i rispettivi product manager.

Considera il direttore del prodotto che è responsabile dei "flussi di lavoro completati". Potrebbero avere i seguenti risultati chiave per la loro squadra:

• Completa una serie di test A/B
• Completa una serie di test di usabilità
• Accelera i tempi di completamento del flusso di lavoro di una certa percentuale

Ogni product manager avrà quindi i propri obiettivi, dove creerà quindi risultati chiave per i propri pod di prodotto attraverso progettazione, ingegneria e altre controparti funzionali.

Ecco un diagramma di come potrebbe apparire per questo particolare team di prodotto:

Il motore di apprendimento OKR è particolarmente utile per i team PM per tre motivi:

1. Incoraggia la sperimentazione e l'apprendimento piuttosto che la fornitura di funzionalità
2. Crea spazio per la scoperta bottom-up con un ricco contesto del cliente
3. Fornisce guardrail per il successo

Innanzitutto, i product manager devono avere la capacità di sperimentare. Tieni presente che la gestione del prodotto è incentrata sulla massimizzazione del rialzo e sull'assunzione di rischi prudenti, mentre la gestione del progetto si concentra sulla riduzione al minimo del ribasso; le due discipline sono correlate ma distinte.

Se forziamo i product manager nella modalità di gestione del progetto, in cui il loro unico obiettivo è fornire alcune funzionalità note entro una scadenza nota, lo sviluppo del prodotto si trasforma nella consegna del progetto. Quando non riusciamo a dare ai product manager lo spazio per imparare dai clienti e per lanciare esperimenti ben mirati, causiamo la stagnazione dei nostri prodotti e facciamo sì che le nostre aziende rimangano indietro rispetto ai concorrenti che si prendono il tempo per conoscere i problemi dei clienti.

Come nota a margine, la transizione dalla tradizionale gestione dei progetti alla moderna gestione dei prodotti non rientra nell'ambito di questa guida sugli OKR. Se stai cercando di dare il via a questo tipo di trasformazione, forniamo workshop aziendali e coaching 1:1 tramite Product Teacher.

In secondo luogo, utilizzando gli OKR, consentiamo alla scoperta decentralizzata dal basso verso l'alto di essere la forma dominante di innovazione all'interno delle nostre organizzazioni, piuttosto che ostacolare l'innovazione a livello di leadership esecutiva.

I product manager tendono ad essere significativamente più vicini al contesto del cliente rispetto ai leader esecutivi, sia attraverso interviste ai clienti, affiancamento dei clienti, analisi del feedback dei clienti o analisi dei dati. Pertanto, i product manager dovrebbero avere il potere di prendere decisioni sui prodotti per i loro clienti, piuttosto che costringere i dirigenti in situazioni in cui devono rinunciare a tempo prezioso per fare scelte di prodotto tattiche.

Infine, gli OKR stabiliscono barriere per il successo e collegano il successo del cliente al successo dell'azienda.

Dopotutto, i clienti sono “divinamente scontenti” e hanno infiniti punti dolenti che potremmo risolvere per loro; le loro aspettative crescono nel tempo. Alcuni di questi problemi, una volta risolti, semplicemente non produrranno valore per l'azienda. Pertanto, identificare quali leve aziendali contano è un potente filtro per aiutare i product manager a dare la priorità ai giusti tipi di punti deboli del cliente.

Ad esempio, considera un sito Web immobiliare in cui gli utenti possono inserire un indirizzo per ottenere una valutazione stimata della casa. Un ipotetico product manager per questo flusso di lavoro di valutazione della casa potrebbe identificare che potrebbe migliorare il "tempo di completamento del flusso di lavoro", i "tassi di completamento del flusso di lavoro" o la "soddisfazione degli utenti" rimuovendo solo un singolo passaggio nel flusso di lavoro. Questo passaggio capita di chiedere agli utenti se desiderano parlare con un agente immobiliare delle loro esigenze e una minoranza di utenti ha inviato reclami al team di assistenza clienti che questo passaggio è fastidioso per loro.

Fondamentalmente, questo passaggio è un passaggio di monetizzazione che cattura il valore aziendale. Se questo product manager rimuove questo invito all'azione, il prodotto non acquisisce più valore per l'azienda.

Con gli OKR in atto, questo ipotetico product manager si renderà conto che lo scopo del loro prodotto è acquisire valore per l'azienda e quindi non tenterà di rimuovere questa fase del flusso di lavoro anche se creerebbe valore per i clienti. In altre parole, anche se uno dei risultati chiave di questo PM è il "tempo di completamento del flusso di lavoro del cliente", non sacrificheranno la redditività a lungo termine dell'azienda per guadagni a breve termine sulle metriche del prodotto.

Ora comprendiamo il valore degli OKR per i team di gestione del prodotto. E, man mano che le aziende scoprono il potere della crescita guidata dal prodotto, ovvero utilizzando il prodotto per raggiungere obiettivi per funzioni non legate al prodotto come vendite e marketing, i leader esecutivi di qualsiasi funzione devono capire come impostare solidi OKR di prodotto.

Stabilire robusti OKR di prodotto

Per aiutarti a creare OKR di prodotto che funzioneranno per la tua organizzazione, esaminiamo le best practice e gli anti-pattern per obiettivi e risultati chiave:

Stabilire un unico obiettivo per ogni squadra

Quando implementiamo gli OKR, dobbiamo tenere presente che ogni squadra dovrebbe perseguire un solo obiettivo alla volta. Mentre diversi obiettivi possono essere sequenziati su più trimestri, ogni trimestre dovrebbe avere un solo obiettivo attivo.

Ad esempio, gestivo un'app mobile CRM per agenti immobiliari con il seguente obiettivo: "consentire agli agenti immobiliari di aumentare le vendite di case con meno sforzo".

Avrei potuto invece suddividere questo obiettivo in tre obiettivi più piccoli, come questo:

• Consenti agli agenti immobiliari di collaborare tra loro attraverso i nostri prodotti
• Rafforzare la visibilità online per gli agenti immobiliari
• Automatizza il maggior numero possibile di processi di basso valore

Ma, se avessi finito per utilizzare questi tre obiettivi separati, sarei incappato in un problema: su quale obiettivo mi concentro? Quando i team hanno più di una priorità in teoria, in pratica finiscono per avere zero priorità.

Ovviamente, a livello di leadership, riconosciamo che le aziende devono destreggiarsi tra molteplici priorità in conflitto. Anche così, una di queste priorità è la più urgente per una data squadra; tutti gli altri obiettivi possono essere sequenziati nel futuro o assegnati a un diverso team dedicato.

Più obiettivi cerchi di raggiungere in questo trimestre, più team dedicati devi avere; il numero di obiettivi attivi scala linearmente con il numero di squadre. E poiché ogni azienda ha un capitale circolante limitato, ogni azienda può avere solo un numero limitato di obiettivi attivi contemporaneamente.

Per chiarire, non possiamo ignorare le richieste del mondo reale; piuttosto, dobbiamo fare scelte difficili su cosa dare la priorità ora rispetto a cosa dare la priorità in seguito.

Esempi di obiettivi improduttivi

Sebbene non esistano obiettivi universalmente buoni applicabili a ogni azienda ea ogni contesto, dovremmo evitare di selezionare obiettivi universalmente cattivi.

In primo luogo, dovremmo evitare obiettivi che non possono essere raggiunti in modo significativo entro un solo trimestre. Ad esempio, "diventare il leader di mercato in Spagna" non ha senso se la nostra organizzazione non è ancora presente in Spagna.

Invece, potremmo inquadrare questo obiettivo come "scopri se possiamo entrare in modo fattibile nel mercato in Spagna". Impostando l'obiettivo in modo che sia ragionevole entro un trimestre, possiamo quindi impostare risultati chiave tangibili rispetto all'obiettivo.

In secondo luogo, dovremmo evitare di fissare obiettivi che impongano risultati specifici del prodotto, soprattutto se non abbiamo chiarezza sul dolore del cliente.

Ad esempio, un obiettivo improduttivo potrebbe essere "abbandonare le funzionalità meno utilizzate per migliorare i margini". Sebbene ciò possa avere senso a livello superficiale, potremmo non renderci conto che una particolare funzionalità di "recupero password" è una funzionalità a basso utilizzo con un valore estremamente elevato per i clienti.

Quando i clienti non possono modificare le proprie password e devono contattare i team di supporto per chiedere aiuto, diventano frustrati e molto più propensi a passare a soluzioni concorrenti. Anche se potessimo risparmiare qualche migliaio di dollari in costi di manutenzione, probabilmente perderemo decine di migliaia o dollari o più a causa dell'abbandono dei clienti.

Un altro obiettivo improduttivo potrebbe essere "ridurre la distanza tra il nostro set di funzionalità e il set di funzionalità di un concorrente". Quando chiediamo ai nostri team di inseguire i concorrenti piuttosto che comprendere i nostri stessi clienti, i nostri prodotti si allontanano dal risolvere il vero dolore dei clienti e perdono il loro potere di acquisire valore per le nostre attività.

Dopotutto, i nostri concorrenti servono la loro specifica base di clienti e noi serviamo la nostra specifica base di clienti; ogni base di clienti ha esigenze distinte che differiscono l'una dall'altra. Pertanto, i nostri obiettivi di business devono essere radicati nel contesto specifico della nostra base di clienti, piuttosto che nella base di clienti dei concorrenti.

Se cerchiamo di imitare i concorrenti perché non sappiamo quale dolore hanno i nostri clienti, è molto più produttivo fissare obiettivi sulla scoperta del dolore del cliente piuttosto che fissare obiettivi sulla parità di funzionalità competitiva.

Ora che comprendiamo quali sono gli obiettivi buoni e gli obiettivi cattivi, discutiamo delle best practice per la selezione dei risultati chiave.

Impostazione di buoni risultati chiave

I risultati chiave dovrebbero identificare se i team hanno compiuto progressi rispetto all'obiettivo aziendale selezionato. Pertanto, i risultati chiave contengono tre componenti:

• La metrica che stiamo misurando
• Lo stato corrente della metrica
• Lo stato finale di destinazione per quella metrica

Fai attenzione a non impostare risultati chiave convenienti da misurare ma che non sono in linea con l'obiettivo prescelto. Ad esempio, considera l'obiettivo aziendale di "creare flussi di lavoro più potenti per gli utenti". Molti team potrebbero decidere di misurare gli "utenti attivi mensili" perché è facile da strumentare e misurare. Tuttavia, "utenti attivi mensili" non è una metrica che dimostra in modo difendibile i progressi verso la "creazione di flussi di lavoro più potenti per gli utenti".

Dopotutto, un team potrebbe creare flussi di lavoro più approfonditi ma finire comunque con lo stesso numero di utenti attivi mensili. Oppure, un team potrebbe attirare un numero significativamente maggiore di utenti attivi mensili fornendo funzionalità che guidano la consapevolezza del flusso di lavoro, ma il team potrebbe non riuscire ad approfondire in modo significativo il flusso di lavoro corrente.

Inoltre, ogni obiettivo dovrebbe avere 3-5 risultati chiave. Idealmente, ogni risultato chiave dovrebbe essere distinto l'uno dall'altro e catturare diversi componenti dell'obiettivo. Avere più di 5 risultati chiave può portare alla perdita di concentrazione e avere meno di 3 risultati chiave può portare alla perdita di una copertura completa.

Ad esempio, supponiamo che il mio obiettivo sia "consentire agli agenti immobiliari di aumentare le vendite di case con meno sforzo". Questi tre risultati chiave potrebbero avere senso insieme:

• Migliora i tassi di conversione lead-to-sale dal 30% al 34%
• Aumentare le vendite mensili medie di case per agente da 1,5 a 1,8
• Rafforzare l'accuratezza delle stime del valore della casa dall'85% al ​​90%

Stabilire obiettivi fattibili

Inoltre, i risultati chiave devono essere accompagnati da obiettivi: non possiamo semplicemente misurare una metrica e farla finita. Affinché gli obiettivi siano attuabili per i nostri team, devono essere obiettivi SMART:

Nel fissare questi obiettivi, dovremmo incoraggiare i nostri team a selezionare stretch goal che siano motivanti ma non impossibili.

Se il team ha un obiettivo che raggiungerà il 100% delle volte, avrà meno motivi per essere curioso e innovativo. Ma se il team ha un obiettivo che potrebbe raggiungere solo il 20% delle volte, rimarranno delusi e scoraggiati poiché il loro obiettivo si sente distante e irraggiungibile.

Una buona regola empirica è che gli obiettivi OKR dovrebbero essere realizzabili al 60-80%. Cioè, una squadra dovrebbe naturalmente essere in grado di raggiungere il 60-80% dell'obiettivo senza ulteriori sforzi, ma dovrà impegnarsi per tentare di raggiungere il 100% dell'obiettivo.

Esempi di risultati chiave improduttivi

In qualità di leader, dovremo istruire i nostri team a selezionare risultati chiave significativi per i loro obiettivi.

In primo luogo, i risultati chiave non dovrebbero essere risultati di "vanità", cioè risultati che arriveranno naturalmente nel corso del tempo. Ad esempio, il "numero totale di visualizzazioni" o il "numero totale di account utente" possono crescere solo verso l'alto, indipendentemente dagli sforzi del team in questo trimestre.

In generale, percentuali e rapporti tendono ad essere obiettivi orientati al risultato migliori rispetto ai totali. Ad esempio, "percentuale di account utente attivi" è più significativa di "account utente totali", perché la percentuale di account attivi nel tempo ci dice se il prodotto sta creando un valore ripetuto di lunga durata per i clienti.

In secondo luogo, i risultati chiave su cui ci concentriamo dovrebbero effettivamente essere importanti per l'azienda; that is, a key result should connect to customer value or user value.

Logins and views are rarely good choices for key results. When a customer logs in, they haven't received value from the product yet. Similarly, when a customer views a particular page, their pain has likely not been solved yet.

Completed workflows tend to be better measures of customer value than logins or views. And, somewhat counterintuitively, customer interviews tend to be strong choices for key results. By interviewing customers, teams can identify unmet customer pain, which can then guide them towards making valuable product decisions.

Now our teams have a system of objectives and key results in place. But, we still need to set up regular reviews to drive learnings and iterative improvement across the organization.

Reviewing product OKR progress

As leaders and managers, we need to regularly review the progress that our teams have made against their set OKRs, so that we can encourage them to reflect, learn, and improve.

Keep in mind that OKRs are not meant for performance management – you should not encourage promotions or demotions based on OKRs, as that tends to incentivize “gaming the system.” That is, teams will be incentivized to pick a target that will make them look good, rather than selecting a target that truly drives customer learning and business value.

Focus on rewarding teams that demonstrate thoughtful learning rather than thoughtless execution. After all, the teams that learn are the ones that will create long-term value.

We should formally review OKRs with our teams at least once per quarter. Some product-led organizations review OKRs every 6 weeks, and others might review them every 4 weeks. On the other hand, a 2 week cadence for formal reviews is usually not a good use of time.

Furthermore, we should encourage teams to spin up dashboards so that we can check in at any time on their progress without having to schedule a meeting. By encouraging information flow, we spur the organization to move faster and farther.

Using key result goals to drive learning and business growth

The key result goals that teams have set will lead to one of three possible outcomes:

• The team meets 60-80% of the target
• The team exceeds 80% of the target
• The team doesn't achieve at least 60% of the target

If the team meets the target, then they should spend time reflecting on their learnings. Which initiatives and processes were effective? How could the team have achieved better results? Were there surprises that we didn't expect?

If the team overshoots the target, that's not cause for celebration. Instead, we need to ask whether their goals had been set too low, and whether we had missed out on achieving even more. Or, perhaps the market was more favorable than expected. If that's the case, then what exactly caused this favorability, and how might the team be able to take better advantage of tailwinds like these in the future?

If the team misses the target, that's not cause for blame. Instead, we should ask blameless questions in retrospectives, to understand “what are 2-3 things we will do differently next time to be better than last time?”

Some questions that can help this discussion:

• Was there an internal failure? If so, could we have foreseen or mitigated it?
• Were there external factors (eg competition or economy) that caused it? If so, how could we have made ourselves more resilient?

Promote a culture of psychological safety, so that teammates can provide candid feedback and drive meaningful iterations.

After each quarter, we as leaders need to reassess the objectives that we had set, based on the progress that our teams have made towards this objective. Do we keep the objective and double down for the next quarter? Or do we instead set our sights in new directions?

We've now covered the foundations for a successful implementation of OKR processes. Let's discuss how OKRs interact with product strategy, product discovery, and Scrum.

The interplay between OKRs and product strategy

OKRs are complementary to product strategy. After all, the objectives that feed into OKRs must first come from product strategy.

Every strategy must contain a diagnosis of “what is a problem in the world that we wish to solve,” as well as an understanding of our assumptions, our constraints, and our proposed path to victory. This proposed path provides the foundation for the objectives within any OKR.

OKRs are focused more on execution, and less on diagnosis or tradeoffs. And, since key results flow from objectives, key results ultimately tie back to the identified product strategy.

But, OKRs do not solely flow downstream from product strategy – they also influence product strategy in turn. Our product strategies should not be static; they should fluidly evolve based on the learnings that our teams have found as they pursue their key results.

In other words, progress against key results can help us identify whether the strategy makes sense to continue pursuing. If we find that multiple teams are struggling to reach their key results, we now have reason to believe that the strategy must be updated to reflect changed market conditions.

As an example, in 2022 the world experienced a heavy economic downturn, and therefore teams were significantly less likely to reach their prior key results. In cases where the underlying terrain has changed, we have to update our strategies to account for new realities.

The role of OKRs in product discovery

Product discovery is the journey through which teams dive into the unaddressed needs of the customer and rapidly iterate through possible product solutions for addressing those needs.

The objectives within OKRs will set product discovery goals for the team. Based on the kind of value that the business seeks to achieve, teams should focus their discovery efforts on those threads of inquiry.

In other words, when teams conduct customer interviews or data analyses, they should do so from the lens of “which customer pains do we prioritize to achieve the given business objective?”

But, in the course of product discovery, teams will learn unique insights from customers that we as an organization may not have realized before. These new insights might wind up changing our objectives.

As an example, perhaps a team uncovers a promising new area of customer pain that we are uniquely positioned to address. Or, perhaps a team learns that “increasing awareness of our existing offerings” might yield significantly more value than “creating new offerings,” based on what they learn in customer conversation.

We would be unwise to discard these learnings solely because they did not align with predetermined objectives. Rather, we should update objectives based on the learnings that we find in product discovery. We should expect a cyclical flow between OKRs and product discovery in this way.

And, the key results within OKRs also signal to us and our teams whether we should continue to dig deeper into an insight that we found through customer discovery, or whether it's time to conduct additional customer discovery to find new objectives to target.

When teams are unable to reach their key result goals, they cannot reflect in isolation. They need to conduct product discovery with customers to understand why their product initiatives have not met the goals.

And, when teams do successfully reach their key result goals, then they need to identify which new customer pains to address in the coming quarters. This exercise also requires them to conduct discovery with customers.

Ultimately, teams cannot mindlessly “manage by numbers.” OKRs are not meant to pull teams away from customers; rather, the metrics within the OKR framework should provide teams with a scalable lens into the lives and needs of their customers.

How OKRs & Scrum synergize with one another

Scrum is a methodology that teams use to deliver “increments of working value” to customers on a regular basis, eg every two weeks. Each block of time, ie sprint, contains a sprint goal with a hypothesis for making progress against OKRs.

Scrum cannot work in the absence of OKRs, because “what is valuable” depends on “which business objective we seek to pursue.” OKRs provide clarity to each sprint, and teams are motivated to focus on creating valuable functionality each sprint that will move the metric in a measurable way.

OKRs also benefit significantly from Scrum. Because Scrum encourages teams to deliver meaningful and measurable value every sprint, teams can make faster progress towards their key results and their objectives by leveraging Scrum. By focusing on delivering working components, teams avoid overbuilding and focus on the minimum required functionality to test their hypotheses.

And, Scrum encourages teams to demo their products to customers, and to capture those learnings. Those learnings then feed back into OKRs. When customers provide live feedback on live functionality, teams can iterate more quickly and have a more clear-eyed view into whether their chosen key results still make sense to pursue over the course of the quarter.

Using OKRs for product decision-making

Every product decision is a tradeoff between initiatives that yield different returns on investment (ROI) across different time horizons and different company objectives.

Therefore, OKRs help guide us and our teams to select the right tradeoffs given our current priorities as an organization. OKRs provide us with value at every level of product-decision making, whether for product strategy, product execution, or sequencing of product initiatives.

At the feature level eg enhancements or improvements to existing products, we can use the RICE prioritization framework to break out the ROI case for each initiative. The RICE framework identifies the reach (# of customers impacted), the impact (depth of value created), the confidence (level of understanding of customer pain), and the effort (implementation costs) of any given initiative.

Crucially, “impact” is calculated based on the OKRs that we seek to achieve this quarter. If a given proposal would unlock some value, but that value doesn't align with the objective for the quarter, then its impact should be set to zero. That way, we focus solely on the initiatives that will truly drive progress towards the objective.

At a strategy level, we should encourage our teams to create product strategy one-pagers when they seek to convince us to prioritize objective X over objective Y, as this exercise drives clarity of thought.

In these proposals, teams should base their arguments on the learnings from key results that they've found in prior quarters. In other words, OKRs give teams space to learn, and their learnings then drive compelling strategic changes.

OKR traps to avoid

In our experience working with leaders from dozens of organizations, we've seen the following pitfalls come up frequently when using OKRs:

• Too many objectives or key results
• Conflicting objectives across teams
• Implementation is too rigorous
• Forcing OKRs onto binary situations

Too many objectives or key results

A common anti-pattern for OKR implementation is that a given team has too many objectives or key results at the same time. While leaders should demonstrate drive and ambition, we need to remember that multitasking leads to worse outcomes.

Ensure that each team has only one active objective for the quarter, and ask teams to decide on 3-5 key results to support the objective.

If you or your teams find that there truly are multiple objectives or key results that must be tackled at the same time, spin up a new dedicated team to handle those objectives, rather than spreading a single team too thin.

Conflicting objectives across teams

Even if we ensure that each team has only a single active objective, one issue that can arise is when different teams have conflicting objectives. In essence, this phenomenon is a symptom of a problem with strategy.

A strategy requires us to state tradeoffs up front, so that all teams have synergistic objectives. As an example, rather than attempting to pursue both high-end customers and mass-market customers, leadership teams must decide which customer segment matters the most right now.

Teams that run into conflicts tend to have senior leaders who aren't operating with the OKR framework in mind. To help reduce the likelihood of conflicting objectives, we can implement OKRs for senior leadership.

After all, as leaders, we should not fear process changes, but should instead embrace them. As a reminder, Intel and Google achieved massive success through ruthless prioritization; we can do the same as leaders.

Implementation is too rigorous

While OKRs are valuable, some organizations misuse the OKR framework as “the ultimate objective of the company,” rather than a means for driving learning and improvement.

This instinct is understandable. Organizations seek certainty, and using OKRs to drive performance reviews and promotions feels data-driven.

However, by placing OKRs on a pedestal within the organization, we start to drift away from our customers' needs, and we lose agility. Teams focus too much on setting targets that will make them look good, and fail to spend sufficient time learning about customer needs and experimenting with ways to better meet those needs.

Teams should be encouraged to revisit their key results as they learn more in the market. The insights that they receive from their execution must be reincorporated bottoms-up into our strategies at the leadership level.

If we solely use top-down directives without granting teams the flexibility to experiment and propose new targets, we revert back to a waterfall-style way of working, which runs counter to the practices that enabled Andy Grove to unlock dozens of billions of dollars in incremental annual revenue at Intel.

Forcing OKRs onto binary situations

OKRs tend not to work well in binary situations, where the team can only achieve one of two outcomes: success or failure.

One binary situation would be “launch this specific feature.” Another binary situation would be “capture this specific customer.”

When we force OKRs onto binary situations, teams have no way of seeing and measuring the progress they made towards the outcome over the quarter. This loss of transparency creates frustration and loss of motivation.

Yet, binary situations are occasionally appropriate to track, especially for enterprise products. In cases like these, leaders would do well to explicitly state “this key result is binary” and to ask the team to provide an estimated “chance for success” for the key result.

The goal for the team is then no longer to deliver the binary result, but rather to increase the chance for success. By doing so, the team focuses on their processes and builds up long-term strength, rather than focusing on an immediate deliverable that might cause long-term harm when rushed to an arbitrary finish line.

Closing thoughts

Executive leaders should consider implementing an OKR learning engine to empower their teams to create business value at all levels.

By combining qualitative business objectives with measurable outcomes, you motivate your teams and your direct reports to improve over time.

OKRs should not be rigidly implemented—instead, different organizations will have different best practices around OKRs. Consider which kinds of processes make the most sense for you, whether those are formal executive readouts or lightweight syncs.