Output e Outcome: differenza, significato e su cosa focalizzarsi

In questo post esploreremo il significato di Output e Outcome, in cosa si differenziano, e su cosa, come Product Manager, devi focalizzarti.

Output e Outcome possono sembrare due parole molto simili a prima vista, ma la differenza semantica è sostanziale.

La differenza tra Output e Outcome, spiegata con un esempio

Il modo migliore per spiegare i tratti distintivi delle due parole è vedere un esempio pratico che non ha nulla a che vedere con lo sviluppo di prodotto: la fisioterapia.

Immaginiamo che tu abbia un dolore al ginocchio da qualche settimana e per risolverlo ti rivolga a un fisioterapista consigliato da un amico. Il Fisioterapista si chiama Arturo.

Il giorno della prima seduta Arturo si dedica all’analisi provando a capire qual è il problema, da dove ha avuto origine, come si manifesta, etc. poi, nella stessa seduta, inizia il trattamento. Immaginiamo che in questo caso il giusto trattamento sia una seduta di 15 minuti di Tecar, 30 minuti di trattamento manuale e degli esercizi da fare a casa 3 volte alla settimana per 15 minuti.

Questo accade per 4 sedute consecutive una volta alla settimana. 

Sono passate cinque settimane e tu, diligentemente, non hai mai perso una seduta con il fisioterapista e hai sempre fatto gli esercizi a casa ma il problema non è stato risolto.

Quella che hai appena letto è la differenza tra Output e Outcome.

L’Output sono le sedute di fisioterapia e gli esercizi, che tu hai eseguito pensando che avrebbero risolto il problema. Tutto quello che hai fatto è una tra le innumerevoli possibilità che avevi a disposizione per risolvere il problema.

Avresti anche potuto decidere di non rivolgerti ad un fisioterapista, ma fare una visita in ospedale, o aspettare che passasse da solo, o prendere degli antidolorifici, o andare da uno sciamano.

L’Outcome è il risultato prodotto, che in questo caso non è stato in linea con le tue aspettative: ti aspettavi che Arturo ti aiutasse con il tuo dolore, ma ciò non è accaduto. 

Un Buon Output non equivale sempre ad un buon Outcome

Hai fatto tutto quello che ti è stato detto (Output Pazzesco), ma il dolore è restato (Outcome disastroso)

Rimaniamo qualche secondo in più sull’esempio perché troverai grandi somiglianze con il mondo dello sviluppo prodotto.

Alla quinta settimana il fisioterapista vede che il trattamento non sta avendo alcun effetto e prova a cambiare strategia per aiutarti a raggiungere il risultato: non si sognerebbe mai di indicarti una terapia che dura 6 mesi di cui solo alla fine capirai se ha funzionato o meno.

Arturo, che ha grande esperienza, procederà progressivamente attraverso iterazioni: probabilmente farà dei nuovi controlli, ti farà domande ancora più approfondite, cercherá di capire se il ginocchio fa male solo in alcune posizioni, introdurrá nuovi esercizi, sospenderà la Tecarterapia perché probabilmente non produce gli effetti sperati.

L’obiettivo di Arturo, infatti, non è farti completare le sedute, ma aiutarti a guarire il ginocchio.

Ed è in base a questo che tu lo valuterai e lo pagherai (Revenue), non in base a quanto sia potente il nuovo macchinario, profumato il gel per i massaggi o luminoso il suo studio (Nice to Have). Tutti questi appena citati sono elementi sicuramente importanti, ma se Arturo non ti aiuterà a risolvere il tuo problema è possibile che sospenderai i tuoi appuntamenti (Churn).

Output e Outcome nello sviluppo di prodotto

Prova a sostituire il tuo problema al ginocchio con il problema che stai provando a risolvere ai tuoi utenti (con il prodotto su cui lavori) e le sedute di tecar, il trattamento e il gel dei massaggi con le feature che costantemente vengono tirate fuori senza misurarne poi l’impatto, ecco svelata l’analogia.

L’abitudine più comune di chi è abituato a lavorare per progetto e non per prodotto è di valutare il lavoro svolto in base all’output, ovvero la feature rilasciata in tempo e in budget, piuttosto che in base all’outcome, il risultato prodotto dal nuovo rilascio.

Questo è uno dei motivi per cui si fa così fatica a sposare il Mindset portato dagli OKR.

Su cosa deve focalizzarsi il Product Manager?

Ecco, adesso tieniti forte: il Product Manager ed il Product Team devono essere valutati sull’outcome non sull’output.

È chiaro che l’output dovrà seguire alcuni criteri minimi di base (che abbiate già uno UI Kit o meno), ma il Product Manager deve essere valutato in base all’impatto che il suo lavoro ha sulle metriche che si sono scelte per misurare il risultato.

Product Management vs Project Management

Ti faccio un esempio più vicino al nostro mondo: tuo zio ha un Albergo e ti chiede di aiutarlo a migliorare il sito dell’Albergo per avere più prenotazioni. Tuo zio si chiama Antonello e L’Hotel si chiama “Hotel Cristallo”.

Tuo zio è super convinto che la prima cosa da fare sia implementare un sistema di pagamento online, che ancora non c’è, con Apple Pay perchè tuo zio Antonello ha un Iphone ed è sicuro al 100% che sia una scelta giusta. 

Come Project Manager il tuo lavoro sarebbe quello di implementare Apple Pay come sistema di pagamento, in tempo, con la “giusta qualità” e non spendendo più soldi di quanti ce ne siano a disposizione. Verrai valutato sull’output e appena Apple Pay è implementato e funzionante tuo zio sará sicuramente super felice.

Rilasciato Apple Pay, senza chiederti effettivamente quanto impatto abbia avuto sul business di tuo zio, passeresti alla richiesta successiva di tuo zio e alla feature successiva.

Il Product Manager si focalizza sull’Outcome

Il tuo lavoro, prima di tutto è capire se ha senso implementare un sistema di pagamento online o se dare priorità ad altro in base agli obiettivi di revenue, margine, stanze occupate o altro che ti sono stati dati, e in caso affermativo scegliere una tra le tante possibilità che hai a disposizione prendendo in considerazione target, effort, tempi, e tutto quello che ti serve,

Se non hai obiettivi devi farteli dare, se gli obiettivi non sono misurabili devi aiutare tuo zio a definirli. Lo so è un inferno, ma è solo così che ci si muove in avanti.

Se sceglierai di andare avanti non importa quanto sia bello il pulsante con scritto “prenota ora”, se usi Intercom, FB messenger, o Zendesk come customer support, o se alla fine scegli di mostrare un IBAN a cui fare un bonifico, l’unica cosa che conta è se con il tuo lavoro muovi la metrica che hai definito prima di iniziare a scrivere una singola riga di codice.

In questo modo lavorerai sull’outcome.

Nella maggior parte dei casi quello che avrai fatto, visto che partivi da zero, ti serve soltanto a costruire una baseline di dati e un primo funnel , perché il tuo lavoro deve ancora cominciare.

Successivamente non farai altro che iterare per migliorare gli Outcome che avrai definito. Non passerai da una feature all’altra perchè a tuo zio “viene l’ansia che sta pagando uno sviluppatore e deve fargli fare qualcosa di completamente inutile”, ma anzi, ogni tanto non svilupperai nulla, perché sarà più importante capire prima quale metrica muovere e come farlo sprecando il meno possibile.

Quello appena letto probabilmente è un esempio in cui ti è ancora più facile identificarti sostituendo tuo zio Antonello con il tuo capo, l’hotel dell’albergo con il tuo prodotto e l’integrazione di apple pay con le centinaia di feature che al tuo team vengono richieste senza avere scelto una metrica da impattare.

Come passare da Output ad Outcome?

Come sempre non è mai tutto lineare. Ci saranno spesso degli Output importanti da consegnare indipendemente dall’outcome e spesso tu non avrai la visibilità necessaria in azienda per capirlo.

Il mio consiglio, se nella tua azienda si ragiona ancora solo e soltanto in termini di output, è di arrivarci gradualmente. Combatti solo le battaglie più importanti e non fare lo sbaglio di pensare che tu detenga la verità e gli altri non capiscano nulla.

Spesso la resistenza al cambiamento deriva dal non avere gli strumenti necessari per cambiare e spesso è frutto diretto della paura.

Inizia in piccolo, verifica ogni passo con pochi utenti prima di pensare in grande.. Parti da prodotti o feature che vengono ritenuti marginali, da lì costruisci un business case che poi ti possa aiutare ad aumentare l’impatto.