Pensare per risultati: le differenze tra output, outcome e impatto

Torno su un tema che ho già trattato e che mi è particolarmente caro – la differenza tra output e outcome – aggiungendo un bit in più, ovvero il concetto di impatto.

Perché riproporre questo argomento? Semplicemente perché occupandomi tra le altre cose di formazione sui temi dell’Agile e del product management continuo a vedere persone che inizialmente fanno davvero fatica a capire le differenze.

Diciamocelo… siamo molto più abituati a pensare per azioni che per risultati.
La cultura del fare nel bel paese e altrove sembra essere ancora dominante rispetto all’idea di “fare le cose giuste”.

Il punto è che io posso mettere in campo un sacco di attività – ad esempio – per portare più traffico sul mio sito ma alla fine non tutte le iniziative si riveleranno produttive: alcune lo saranno più di altre, alcune non lo saranno affatto, poche faranno veramente la differenza e sposteranno i numeri dell’acquisition.

Prendiamoci allora il tempo di capire bene questi concetti e di non ricadere nell’approccio del fare tanto per fare.
Andy Grove – CEO di Intel per tanti anni e padre degli OKR – già negli anni ‘70 diceva

“Ci sono così tante persone che lavorano duro e ottengono così poco”.

Quanto spreco! Possiamo tutti imparare a fare meno e a scegliere quelle attività che possono davvero spostare l’ago della bilancia.

Definizione di output, outcome e impatto

Output

Partiamo dalla cosa più semplice: l’output è un’attività, un’azione che facciamo per raggiungere un determinato obiettivo.
Difficilmente ci confondiamo su questo concetto perché gli output sono tangibili, sono qualcosa che possiamo vedere / toccare / esperire e quindi è molto facile capire se una determinata cosa è stata fatta oppure no (es. la presentazione che il tuo responsabile ti ha chiesto, l’aggiunta di filtri avanzati di ricerca sul sito, l’avvio della campagna marketing per un cliente retail, ecc.).
L’output c’è o non c’è, quali risultati produca è tutta un’altra storia.

Outcome

Joshua Seiden nel suo libro “Outcomes Over Outputs” definisce l’outcome come “un cambiamento nel comportamento umano che guida i risultati aziendali.” 

L’outcome è il risultato che le azioni che fai producono; si tratta di cambiamenti nel comportamento di clienti, utenti e dipendenti che portano cose positive (si spera!) per la tua azienda, la tua organizzazione o chiunque sia al centro del tuo lavoro.

I risultati non sono direttamente correlati con la creazione di funzionalità, anche se a volte arrivano creando le cose giuste. Idealmente – sottolinea l’autore – si verificano quando hai creato il minor numero possibile di funzionalità.

Fare cose insomma non significa necessariamente fare progressi verso un determinato obiettivo. Se la presentazione che hai prodotto non sblocca il budget per perseguire il nuovo progetto R&D, se l’aggiunta di filtri avanzati non riduce i tempi di ricerca con risultati sul sito, se la campagna marketing non genera traffico il tuo output non ha prodotto alcun outcome (e – fidatevi – questa situazione è estremamente comune se consideriamo la statistica che il x% delle funzionalità non cambia…).

L’outcome ha a che fare con il valore generato per i nostri interlocutori.

Impatto

Alcuni utilizzano outcome e impatto in maniera intercambiabile… non è del tutto sbagliato; dal mio punto di vista dipende dal contesto.
Se penso ad esempio ad uno strumento come la Impact Map l’impatto è proprio definito come una modifica del comportamento negli attori del sistema, in altri casi l’impatto è considerato un cambiamento che avviene su una scala più grande (pensate all’impatto sociale o organizzativo). In questa seconda accezione l’impatto è un cambiamento di portata maggiore, che interessa gruppi di individui, organizzazioni o intere società (in molti casi potrebbe essere definito ad esempio nella mission di un’azienda).

W.K. Kellogg Foundation
Logic Model Development Guide

Ciò che non mi convince del tutto in questo modello è proprio la collocazione dell’output all’interno dei risultati attesi… l’output non è affatto un risultato bensì la nostra migliore scommessa su ciò che c’è dev’essere fatto per raggiungere un certo risultato. 

Esempio del Logic Model

Perché pensare per risultati fa la differenza…

Capite perché l’enfasi sui risultati innesca un cambio culturale? 
L’accento sul “fare cose” è un’eredità di un’epoca in cui producevamo principalmente beni fisici e la sfida principale era fare bene le cose. Oggi viviamo in un mondo molto più digitale e immateriale dove l’attenzione si sposta dai beni fisici ai servizi e alle esperienze nel loro complesso, un contesto in cui per lo più meno è meglio (“la semplicità – diceva Leonardo – è la suprema sofisticazione”). 

Pensare per risultati ti costringe a verificare che le tue azioni producano effettivamente un outcome (se non lo fanno, non perdere tempo!), ad accogliere il dubbio che gli output che hai individuato possano non essere tanto efficaci quanto le tue aspettative, a validare se stai davvero creando valore per qualcuno.

In sostanza se lavori per risultati non puoi fare a meno di un compagno di viaggio: gli esperimenti

Quando cominci a combinare il raggiungimento dei risultati con un processo basato sull’esecuzione di esperimenti, sblocchi la reale potenza degli approcci agili.

I progetti diventano a quel punto una serie di ipotesi ed esperimenti creati per raggiungere un risultato. Il tuo responsabile potrà non essere del tutto a suo agio quando gli viene ribadito il rischio insito in ogni progetto, ma a sua volta sa perfettamente che solo una percentuale minoritaria delle iniziative ha successo (… e se fa finta di non saperlo è meglio perderlo che trovarlo).

Lavorare in questo modo – come ho già raccontato in questo post – richiede più impegno ma è estremamente più motivante per le persone.

Quindi fate brainstorming su quali azioni hanno più chances di avvicinarvi al risultato atteso, prioritizzate le vostre migliori ipotesi e poi sperimentate, sperimentate, sperimentate. Diventerete sempre più bravi ad anticipare quali output sono più efficaci per raggiungere un certo outcome e a scartare un sacco di idee (sulla base dei learnings che avete accumulato nel tempo).

Riconoscere output, outcome e impatti

Vi sembra più chiara la differenza ora tra i 3 concetti?
Pensate di essere in grado di distinguerli?
Proviamo a fare qualche esempio e vediamo che ne pensate… si tratta di outcome o impatti? 

  • Creare e promuovere cibi gustosi, salutari e biologici
  • Aiutare a dare vita ai progetti creativi
  • Diventare il leader riconosciuto nella produzione di vini rosé
  • Migliorare l’accessibilità del nostro sito web
  • Sconfiggere la malaria
  • Scalare il monte Everest

Un suggerimento: ricordate che gli impatti sono di grossa portata e hanno al centro gli altri.

Scrivete nei commenti le vostre risposte o i vostri dubbi e li approfondiremo assieme. Aiuto tutti i giorni le aziende a definire i loro obiettivi e sarò felice di fare chiarezza con voi se ancora avete qualche perplessità a riguardo.

Infine se volete approfondire ulteriormente c’è un corso gratis su Coursera che può fare al caso vostro: argomento? OKR

… e su questi ultimi tornerò a breve.

Design Thinking: che cos’è e come può esserti utile

Quali sono le caratteristiche dei prodotti e dei servizi di successo? Che cosa rende un’innovazione tale? Ve lo siete mai chiesto?
Il Design Thinking ha una risposta precisa a queste domande.
Sto seguendo un corso del MIT dedicato al pensiero progettuale e approfitto per riorganizzare le idee.

Che cos’è il Design Thinking

Il Design Thinking è un approccio sistematico per creare innovazioni di successo, una metodologia per l’innovazione che combina capacità analitiche, attitudini creative e collaborazione tra le discipline.
In altre parole Il Design Thinking è un processo per la risoluzione creativa dei problemi.

Questo approccio è stato codificato attorno agli anni 2000 in California dall’Università di Stanford e ripreso poi da varie scuole e società tra cui la famosissima IDEO.
Pur essendo partito dagli studi di design, il Design Thinking sta prendendo piede negli ultimi anni nella consulenza direzionale, nella trasformazione digitale e nella progettazione software.

Il Design Thinking è la progettazione incentrata sull’uomo (human-centered design); incoraggia coloro che progettano a concentrarsi sulle persone per le quali stanno creando (ricordate le personas?), il che porta a prodotti, servizi e processi interni migliori.
Invita a cercare soluzioni innovative (solo) dopo aver individuato l’esigenza umana sottostante (non è questo un mantra per un Product Owner?).

Questa è la risposta del Design Thinking alla domanda su come creare prodotti innovativi.
Tutti i prodotti di successo hanno in comune tre dimensioni: la dimensione relativa alle persone, la dimensione tecnica e il lato business.

Le tre sfide per l’innovazione

Perché un’innovazione si possa dire veramente tale tutti e 3 questi aspetti devono coesistere.

“Impiegando il Design Thinking stai mettendo insieme ciò che è desiderabile da un punto di vista umano con ciò che è tecnologicamente fattibile ed economicamente sostenibile.”

Desiderabilità

Tutto ha inizio con l’idea che ci sia un problema là fuori che le persone hanno e che sarebbero disposte eventualmente a pagare per trovare una soluzione.
Nell’area delle persone dobbiamo essere ragionevolmente sicuri che la soluzione – ovvero il prodotto o il servizio che andiamo a proporre – sia desiderabile.
Le persone devono essere consapevoli di avere quel particolare bisogno.
A volte può capitare che ci voglia un po’ di lavoro prima che possano effettivamente riconoscerlo ma senza una vera necessità la soluzione che proponiamo è destinata a fallire: le persone non la compreranno.

Fattibilità

La seconda dimensione è la dimensione è di natura tecnica.
Dobbiamo essere in grado di risolvere questo problema in un modo tecnicamente fattibile.
In alcuni casi le soluzioni tecniche proposte possono risultare veramente molto difficili da implementare, possono richiedere risorse che non si hanno a disposizione o tecnologie che non sono ancora “pronte” per il mass market.
In questo caso il prodotto o servizio che proponiamo risolverebbe un bisogno riconosciuto dai nostri utenti, ma risulta tecnicamente irrealizzabile.

Sostenibilità

E ora la terza dimensione: il business.
Ammesso di avere davvero indirizzato uno o più bisogni e di avere trovato una soluzione tecnicamente fattibile, quello che proponiamo è anche sostenibile dal punto di vista della redditività? E’ in grado di generare ricavi?
Se non produce entrate sufficienti per pagare i costi, non saremo in grado di sostenere il prodotto per molto tempo (e perché dovremmo farlo poi?).
Il prodotto innovativo per essere tale deve anche realizzare un profitto per ripagare tutto l’investimento fatto. Va di pari passo con un modello di business (innovativo o meno).

Queste tre dimensioni insieme ci danno innovazione.
Se ne indirizziamo solo una o due, generalmente non possiamo avere un’innovazione di successo. D’altra parte non è necessario che tutte e 3 le dimensioni siano risolte immediatamente in una volta; l’importante è che al termine del processo siano tutte e 3 presenti.

Ad esempio è comune che durante l’attività di Design Thinking si parta da uno di questi aspetti. Potresti partire dalla dimensione delle persone o da un innovativo modello di business rispetto al quale sei abbastanza confidente di poterlo fare funzionare; parti da lì e poi alla fine risolvi le altre dimensioni.
Al contrario un ingegnere potrebbe partire dalla dimensione tecnica. Anche questa modalità può funzionare a patto però di rendersi conto che se la soluzione proposta non risolve una reale esigenza del cliente, se non c’è alcun desiderio da parte del mercato, il prodotto non avrà successo.
Inutile dire che se non c’è un business allora neanche il resto può funzionare a dovere…

Quando è utile il Design Thinking

L’abbiamo già detto: il Design Thinking è progettazione incentrata sull’uomo.
Questa affermazione porta con sé un corollario: se il problema che state tentando di risolvere non è “umano”, questo approccio potrebbe non fare al caso vostro.
No, non mi riferisco agli alieni… semplicemente al fatto che in molti casi come persone di prodotto ci troviamo a dover indirizzare progetti che nascono semplicemente da esigenze aziendali. Se stiamo cercando di risolvere un problema di redditività di un’azienda non correlato in alcun modo a un vero bisogno delle persone – sperabilmente i nostri utenti – il Design Thinking non è il framework che fa per noi, dovremo considerare altri tipi di risorse.

Spero a questo punto di avervi dato un’idea di massima di cos’è il Design Thinking.
In ogni caso continuerò a elaborare il tema in approfondimenti successivi. Comunque se volete avere un’idea più precisa del processo vero e proprio vi suggerisco la visione di questo video; è un po’ datato ma sempre valido.


Racconta il processo di Design Thinking in pratica applicato ad un progetto teorico (ma assolutamente realistico). Se lo guarderete sino alla fine vi stupirà vedere come innovazioni progettate nel ‘99 siano diventate oggi oggetti del nostro uso comune. Buona visione!

Le 3 C delle user stories: carta, conversazione e conferma

Oggi parliamo di storie, un grande classico per i product owner, e andiamo alla base della loro costruzione esplorando insieme le 3 C delle user stories: carta, conversazione e conferma.

Ma cosa sono le user stories? Sono semplici descrizioni, contenute in una frase, di ciò che un determinato utente vuole ottenere raccontate dal suo punto di vista.
Sono nate nell’ambito dell’Extreme Programming prima dell’inizio di questo millennio (la loro origine si fa risalire al 1998) e sono poi diventate popolari in tutti i processi agile.

User story: qualche esempio di scrittura delle card

Facciamo qualche esempio pratico per capirci meglio.
Immaginiamo di stare sviluppando un sito di annunci (i cosiddetti classified) che consente a venditori e acquirenti di scambiarsi beni materiali e servizi accordandosi tra privati.
La nostra piattaforma avrà user stories come queste:

  • come utente di <nome della piattaforma> , posso effettuare ricerche su articoli specifici.
  • come venditore, posso facilmente consultare la lista di tutti i potenziali acquirenti interessati al prodotto che ho messo in vendita.

Come vedete sono frasi brevi che descrivono cosa un utente vuole fare, raccontate secondo il suo punto di vista.
Un’altra cosa che possiamo notare è che abbiamo più tipologie di utenti: nel primo caso parliamo di un utente generico, nel secondo adottiamo il punto di vista di uno dei principali attori della piattaforma (in venditore).

Possiamo fare la stessa cosa mettendoci dal punto di vista dell’acquirente:

  • come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo.

Cosa manca ancora in questo esempio?
Manca un dettaglio che per me è la parte più importante delle user stories, la cosiddetta clausola so-that.
Ciò che spiega perché un determinato utente vuole una certa cosa, qual è la sua finalità, qual è il risultato finale a cui tende (o outcome).

La storia potrebbe prendere allora questa forma:

“come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo così da potermi accertare delle sue condizioni”

O dal punto di vista del venditore:

“come proprietario di un auto che desidero vendere, posso creare una pagina in cui descrivere lo stato dei veicolo e mostrarlo al suo meglio”

Notate che stiamo parlando della medesima funzionalità (le foto associate al prodotto) da due punti di vista differenti: quello del venditore e quello dell’acquirente.

User story: l’importanza del punto di vista

Bene, abbiamo introdotto il formato più classico con cui si scrivono le user stories:

Come <tipo di utente>, voglio <funzionalità> così da <obiettivo o valore per l’utente>.

Semplice ed efficace! Chiunque è in grado di esprimere un bisogno, una necessità o un desiderio secondo questo formato.
Ma non è solo la semplicità ad essere la chiave del successo delle user stories, l’elemento essenziale qui è la prospettiva: il punto di vista che adottiamo ci aiuta a relazionarci con specifiche tipologie di utenti, a metterci nei loro panni.

Sembra un dettaglio ma non lo è.
Ditemi se vi fa lo stesso effetto esprimere le medesime funzionalità come si descrivevano una volta nei documenti di requisiti …

  • il sistema consente all’utente di effettuare una ricerca
  • il sistema consente all’utente di pubblicare online un prodotto
  • il sistema consente all’utente di associare una o più foto a un prodotto

Il significato di queste affermazioni è lo stesso ma nel primo caso rispondiamo con più empatia perché stiamo mettendo l’utente – una persona – al centro della scena.

User story: la conversazione a partire dalla carta

Un errore in cui cadono spesso i team che muovono i primi passi con i framework agili è pensare che una volta scritta la user story tutto sia chiaro e definito.
In realtà chi ha un po’ più di esperienza alle spalle sa bene che la scrittura è solo l’inizio del gioco.
Non dobbiamo dimenticare che la user story comprende tre C:

  • una scheda o carta (= card),
  • la conversazione (= conversation)
  • criteri di conferma (= confirmation).

Le 3 C sono un’allitterazione ideata da Ron Jeffries per chiarire che una user story è più di un semplice testo scritto su carta fisica o su strumento software.
Le user stories sono brevi, non sono fatte per contenere molti dettagli bensì per agevolare delle conversazioni (si parla anche delle storie anche come “placeholder per conversazioni con il team”).
La carta è solo una delle tre C, la più visibile, e anche quella meno importante.

Mi è capitato in passato di lavorare con team che pretendevano di avere il massimo livello di dettaglio nelle storie; questo desiderio di chiarezza e completezza per quanto comprensibile dà l’illusione che tutto sia stato definito e compreso ma non aiuta le persone ad uscire dalla propria comfort zone e fare il “viaggio di scoperta” nei bisogni dell’utente.
E’ dall’interazione tra il product owner, il team allargato e gli utenti che nasce la vera comprensione di ciò che c’è da fare, non da una frase scritta su un pezzo di carta.

Non si tratta di un modo alternativo di scrivere requisiti, la card è “una promessa a due vie” come dice Mike Cohn:

  • la promessa del team di porre domande prima di iniziare a lavorare su una storia
  • la promessa del product owner di essere disponibile ad approfondire l’argomento.

Questi due aspetti insieme ci evitano di dover scrivere corposi documenti di specifiche contenenti ogni singola funzionalità.

Se il team si parla prima di iniziare a lavorare, il product owner può specificare solo quanto basta per poter avere quella conversazione.
E’ la conversazione in sé che rende agile un team, non la scrittura delle storie, l’utilizzo di post-it o di tool come Jira.

User story: la C di conferma

Quando Mike Cohn illustra questa parte delle storie dice che non gli piace iniziare qualcosa se non capisce come saprà quando ha terminato. E a chi piace questa incertezza?
I criteri di conferma di una user story servono proprio a questo; sono il modo in cui il product owner definisce insieme al team ciò che deve essere fatto affinché lo sviluppo possa essere considerato completo.

Ricordate quando a scuola per la prima volta un insegnante vi ha assegnato un riassunto di un libro? Alzi la mano chi non si è chiesto quanto dovesse essere lungo lo scritto!
Ecco, questo è un classico esempio di criterio di accettazione. Per alcuni professori una sintesi di una pagina è accettabile, per altri non si parla di sufficienza sotto le 3 pagine (e non pensate di barare con la dimensione del testo e l’interlinea!).

Una parte della conversazione tra il team e il product owner prima di lavorare una storia riguarderà proprio i criteri di conferma, ovvero come ciò che sarà sviluppato verrà valutato per l’accettazione durante la sprint review.
Si tratta delle “condizioni di soddisfazione” della storia. In altre parole, affinché il product owner possa considerare la user story fatta, una determinata cosa deve fare questo, quello e quell’altro.

Torniamo al nostro esempio di prima quando parlavamo della possibilità di associare delle foto all’auto che il nostro utente vuole mettere in vendita.
Per questa user story potremmo definire criteri di accettazione di questo tipo:

  • i formati di immagine accettati dal sistema (es. jpg, png, ecc.)
  • il peso massimo della singola immagine
  • la possibilità di vedere un’anteprima dell’immagine caricata
  • e magari anche la possibilità di poter ruotare eventuali immagini capovolte prima della pubblicazione.

User story: la prima C da sola non basta!

Siamo arrivati alla fine del nostro excursus sulle user stories.
Come abbiamo visto le storie non sono un nuovo modo di scrivere i requisiti, ma molto di più. Hanno come minimo 3 funzioni:

  • sono un placeholder per una conversazione sui bisogni degli utenti
  • sono strumenti per capire cosa vogliono gli utenti e cosa ha senso realizzare
  • sono un modo per programmare il lavoro del team.

Quindi ricordatevi di prestare attenzione a tutti e 3 gli aspetti: non solo al testo che andrete a scrivere su una scheda, ma anche alle conversazioni sulla funzionalità e ai criteri di conferma che utilizzerete per determinare se la storia è completa.

Note

Questo post è liberamente tratto dalle lezioni di Mike Cohn sulle user stories. Se volete approfondire vi consiglio il suo corso – molto valido – “Better User Stories“.

Nel blog trovate anche diversi post dedicati alle storie. Eccone qui una piccola selezione: