Problema, Soluzione e Mostri a tre Teste

In questo post capirai perchè è molto importante, come Product Manager, dedicare il tuo tempo principalmente al Problema che vuoi risolvere, piuttosto che alle soluzione o soluzioni che ti vengono in mente costantemente.

Come sempre inizierò con un esempio che poco ha a che vedere con il mondo del tech e dei prodotti digitali. Se sei un lettore affezionato di Product Heroes probabilmente ti chiederai perchè per spiegare il Product Management parlo di fisioterapisti, alberghi o missioni spaziali.

La risposta è semplice: i principi del Product Management sono universali e possono essere applicati a qualsiasi tipo di attività. Ho sentito troppe volte dire “no, questa cosa non la posso fare così perchè il mio prodotto è diverso”, ecco, sono solo scuse che si mettono davanti perchè non si è disposti a sostenere il costo del cambiamento.

Ovviamente ogni azienda ha i propri tempi, processi e richiede investimenti diversi, ma i principi del Product Management possono sempre essere utilizzati.

Usare esempi molto lontani dal digitale ci aiuta ad astrarre i principi, renderli estremamente semplici e comprensibili e poi di poterli applicare a qualsiasi cosa.

In questo caso userò un esempio trovato in un video di Dan Olsen, che vi consiglio di guardare per intero: Mastering the Problem Space to Achieve product-Market Fit.

La penna da 1.000.000 di $

Correva l’anno 1960, periodo di guerra fredda e di corsa agli armamenti spaziali. Dopo le  prime missioni inter-stellari, gli Stati Uniti decisero che era necessario dare agli astronauti la possibilità di scrivere per poter comunicare tra loro e appuntare qualsiasi cosa, durante le missioni.

C’era un problema: l’assenza di gravità. 

Le penne normali non funzionavano, perché l’inchiostro non scendeva lungo la penna! La NASA reputò così importante il problema che avviò un processo di Ricerca e Sviluppo per trovare la soluzione.

Con un investimento di 1.000.000 di $, venne creata la “Space Pen”: una penna in grado di scrivere in assenza di gravità.

Problema risolto!

I Russi di fronte allo stesso dilemma diedero ai propri astronauti una matita del costo di pochi centesimi!

Sebbene questa storia sia in bilico tra legenda e realtà , quel che conta è la morale. 

La usiamo sempre durante la Product Academy perché semplifica e rende molto evidente la differenza tra problema e soluzione.

La cosa che più mi piace è la perfetta rappresentazione di quanto gli sprechi possano diventare enormi quando ci si innamora della soluzione.

Analizziamo la storia perché questo tipo di approccio ti sarà molto utile durante le fasi di brainstorming e creazione di nuovi prodotti o nuove feature.

Problema e Soluzione vanno suddivise in due aree completamente distinte.

Problem Space: Un problema, un bisogno o un beneficio a cui il prodotto dovrebbe rispondere

Solution Space: Un’implementazione specifica per rispondere al bisogno specifico.

Questo è il modo migliore per capire dove finisce uno e inizia l’altro.

Tornando al nostro esempio, il Problema degli astronauti era la difficoltà di comunicazione tra loro durante le missioni, non la penna che non scriveva!!!

Non è neanche detto che la scrittura fosse la migliore soluzione possibile per farli comunicare.

Quel che è accaduto, invece, è che una delle soluzioni possibili diventasse il problema e si facesse di tutto per risolverlo.

Adesso sii sincero: quante volte ti è capitato?!

A me tante: mi perdevo nei dettagli e impiegavo (sprecavo!) giorni a riflettere sul come portarmi a casa la soluzione perdendo di vista il problema.

Negli anni, ho anche creato un nome per questo processo di de-focalizzazione, dal problema e dall’utente, per aiutare me e il mio team a riconoscerlo e da subito dargli il giusto peso: Mostro a tre Teste.

Il Mostro a tre Teste

Il mostro a tre teste si materializza quando a partire da un problema reale di un utente si inizia a ragionare su una soluzione che:

1. progressivamente si allontana dalla risoluzione del problema stesso e quindi dagli utenti, e quindi dal valore che potremmo generare.
   
2. comincia ad ingrandirsi alimentandosi della sua stessa complessità verso direzioni poco connesse all’obiettivo o alle metriche che vogliamo impattare.

La soluzione a un semplice problema, diventa un mostro a tre teste che non si sa esattamente da dove sia arrivato, e da chi sia stato creato, la cui implementazione richiederebbe settimane o mesi di sviluppo senza avere la minima certezza che abbia senso investire in quella direzione.

La soluzione a un problema diventa essa stessa il problema da risolvere

Tipicamente il Mostro a tre teste si genera durante sessioni di Brainstorming non moderate in cui partecipano soggetti molto entusiasti e con abbastanza autorità da portare in esecuzione una “cosa” che non ha grande senso di esistere.

Ti faccio un esempio molto pratico e super semplificato.

Esempio di genesi del Mostro a Tre Teste

Ipotizziamo di lavorare su una piattaforma per la creazione e la gestione di Webinar (molto originale di questi tempi..). La piattaforma si chiama WeBiDè.

Siamo nella fase iniziale e abbiamo circa 150 utenti che pagano una fee annuale per poter creare i propri Webinar con WeBiDè. In media 10 utenti creano 1 webinar a settimana. Ci accorgiamo però che l’80% delle persone che si iscrivono al webinar per assistervi, poi non si presenta (No Show). Per ogni Webinar in media si iscrivono/prenotano 50 persone.

Ovviamente questo rappresenta un grande problema su tutti i livelli.

Dopo qualche intervista capiamo che il problema potrebbe essere legato all’assenza di reminder in piattaforma: semplicemente gli utenti non si ricordano del Webinar.

La nostra ipotesi quindi è che il tasso di Noshow possa diminuire del 50% grazie a una soluzione che ricordi all’utente del Webinar imminente.

NOTA BENE: come vedi ho molto chiaro il problema e come misurare l’eventuale superamento, e non ho ancora la soluzione.

Per trovare la giusta soluzione faccio un brainstorming con il mio team.

PM: il problema è che le persone non si presentano al webinar perchè nessuno glielo ricorda. Avete qualche idea su come poterlo risolvere?

Dev 1: Facciamo un sistema di notifiche automatizzato!

Designer: Figo! facciamolo multi channel: email e sms.

Dev 2: Bellissimo! Facciamo anche un’integrazione su Smartwatch! Pensa che figata!!! Cammini per strada e ricevi il reminder direttamente su Smartwatch.

PM: Ragazzi siamo sulla giusta trada secondo me: il CEO sarà super contento. Parliamo un attimo della frequenza e delle condizioni. Facciamo così: mandiamo una notifica il giorno prima, poi, se l’hai aperta, ma non hai cliccato, ne mandiamo un’altra dopo 12 ore, se invece hai cliccato ne mandiamo una dopo 24 ore e poi…

Dev 1: Aspetta aspetta! Ma perchè non implementiamo un algoritmo di Machine Learning che lavora su argomento, età e abitudini. Probabilmente chi segue un Webinar su yoga si comporterà diversamente da chi segue un Webinar su Matematica Finanziaria…

e così lentamente il Mostro a Tre Teste sorge dagli abissi e si materializza.

Ci si fa prendere dall’entusiasmo, si spendono ore a progettare una soluzione completamente fuori scala per il reale problema da risolvere.

In questo caso vista la fae di prodotto di WeBiDè e il numero esiguo di utenti per singolo webinar (50) e di webinar per settimana (10), si sarebbe potuto optare per soluzioni con un costo di implementazione tecnico pari a zero, sicuramente con un maggior costo operativo, ma con l’agilità di poter dismettere la soluzione qualora non muovesse le metriche. Solo dopo, al crescere degli utenti, si sarebbe potuto passare a soluzioni più scalabili.

Nel Trade-off tra costo di implementazione tecnica (ore di lavoro del team) e costo di gestione operativa ecco alcune soluzioni ipotetiche. Come sempre non c’è una soluzione giusta e una sbagliata, dipende a cosa vuoi dare priorità:

• Invio mail manuali (ccn)
• Invio messaggi Whats-app manuali / Broadcast
• Newsletter manuali da strumenti di Marketing Automation
• Integrazione tra piattaforma e strumenti di marketing automation tramite tool di connessione (Integromat, Zapier, etc.).
  

Se vuoi avere qualche informazione in più sulle tecniche di prioritizzazione delle diverse soluzioni puoi approfondire da questo articolo che abbiamo scritto in passato: come stabilire le priorità di prodotto.

Il vantaggio di non partire dalla soluzione.

Tornando alla Soluzione spendo giusto due parole: non perdere tempo nei dettagli, ma dai la soluzione minima per risolvere il problema più urgente. Ridurrai la frizione progressivamente.

Meno ti leghi alla soluzione meglio è. 

Al di là del tempo impiegato o dei soldi spesi per sviluppare qualcosa, non avere ancora nulla tra le mani ti dà un’apertura mentale pazzesca e la possibilità di trovare problemi super urgenti che non conoscevi.

Le cose che “non sappiamo di non sapere”, e che scopriamo sui nostri utenti, sono esattamente quelle che devi cercare. 

Con una soluzione già pronta ti verrà davvero complicato. Non sto dicendo che non dovrai mai sviluppare nulla. Assolutamente no! 

Quel che ti consiglio è capire prima che problema stai risolvendo, averlo molto chiaro, scoprire quali persone reali lo hanno e poi passare alla soluzione.

Se vuoi approfondire su come validare la soluzione con il minimo spreco puoi dare un’occhiata a questo articolo sul Minimum Viable Product.

Come Product Manager inoltre non dovrai essere tu a pensare alla soluzione, ma il team fantastico con cui lavori.

Ricordati sempre che il Product manager è l’owner del WHY, contribuisce alla definizione del WHAT e lascia l’HOW al team.

Come il Product manager può focalizzarsi sul problema e non sulla soluzione

In questo video Silvana De Santis, Head of product in Hyperlex ci dà qualche consiglio utile per capire come ragionare in termini di problema e non di soluzioni.