Crea la tua cassetta degli attrezzi per la scoperta dei prodotti

Quando un team di prodotto inizia una nuova missione di scoperta del prodotto, il suo compito principale è ridurre l'incertezza. L'allineamento e la ricerca iniziali potrebbero sembrare prevedibili e quasi lineari. Ma non appena la prima ipotesi si rivela sbagliata, le squadre devono correggere la rotta.

La complessità di Product Discovery può sembrare opprimente, ma cercare di superarla con progetti sviluppati da altre aziende è raramente una soluzione praticabile. È molto più importante evolvere il proprio approccio. In questo articolo, voglio condividere il motivo per cui credo che l'individualità del team di prodotto sia il superpotere segreto per un'efficace Product Discovery.

Una storia personale: fissazione della velocità, scoperta del prodotto Paint-by-Numbers e una realizzazione

Ho sperimentato in prima persona approcci rigidi (e “prevedibili”) alla scoperta dei prodotti. E ho causato la mia giusta dose di infinite iterazioni senza creare chiarezza.

Quando ho ricevuto il mio certificato CSPO nel 2012, ero sicuro di sapere tutto sulla creazione di ottimi prodotti digitali. Ero convinto che il mio grande successo come product manager fosse ormai inevitabile. Tutto quello che dovevo fare era assicurarmi che le mie storie utente contenessero abbastanza dettagli e seguissero il modello. Ho potuto recitare il Manifesto Agile on demand.

Ho definito il successo del mio ruolo principalmente attraverso l'output del team e il grado in cui gli stakeholder erano soddisfatti della soluzione. Ho dato la priorità all'aumento della velocità dello sprint e al rispetto delle scadenze rispetto al miglioramento continuo del comportamento degli utenti. È tutto ciò che mi importava.

Ma a un certo punto ho iniziato a interrogarmi sul modo in cui nuove idee trovassero la loro strada nel nostro backlog. Ci doveva essere un modo migliore che copiare i concorrenti, saltare sulle nuove tendenze del design e aspettare l'ultima "grande idea" del CEO.

Dopo aver seguito per un po' il percorso di occupato Product Manager, mi sono avvicinato all'idea di Product Discovery e Dual-Track Agile. Mi sono subito innamorato di entrambe le idee.

Sfortunatamente, questa storia d'amore non è finita bene. Mi sono perso in infinite iterazioni di Product Discovery e ho cercato di seguire passo dopo passo i processi di altre aziende "famose". Quando non riuscivo a seguire esattamente i loro approcci, mi sentivo come se avessi fallito in qualche modo. Invece di esplorare lo spazio del problema e trovare nuove soluzioni, stavamo diventando una vittima dei modelli che abbiamo raccolto su Twitter e Medium.

Esempio: abbiamo esaminato il concetto di eseguire "Lean Inception", perché è stato suggerito da alcuni stakeholder. Speravamo di individuare chiaramente un MVP e tracciare un percorso da seguire. Sfortunatamente, non avevamo approfondite informazioni sugli utenti. Non era chiaro se valesse la pena risolvere il problema e mancava una prospettiva veramente interfunzionale. Lean Inception è un processo "collaudato" per dare il via a un "Progetto Agile" ed è stato visto come una mossa molto progressista internamente. Purtroppo, mentre l'inizio è stato "fantastico", siamo finiti in una modalità a cascata puramente guidata da HIPPO (che ironicamente è stata l'input principale per il seminario fin dall'inizio).

Da allora, ho lavorato con una vasta gamma di team di diversi settori e dimensioni aziendali, sia come product owner/manager interno che come product coach esterno. La mia prospettiva su ciò che serve per rendere efficace Product Discovery è cambiata radicalmente (e in meglio, credo).

Mentre spiega come Discovery e Delivery vanno di pari passo, la visualizzazione più popolare di Dual-Track Agile suggerisce anche una sorta di linearità che è distaccata dalla realtà disordinata che i team devono affrontare ogni giorno. È limitante adattare le iterazioni di scoperta alla cadenza dello sprint esistente. Allo stesso modo, i team non dovrebbero sentirsi obbligati a trasformare ogni nuova idea di scoperta in uno sprint di sviluppo.

Credo che questa rigidità esista a causa della "zona di comfort" che l'attenzione ripetitiva sugli output negli sprint offre agli stakeholder e ai team. Finché le nuove idee vengono inserite nello sprint backlog, l'utilizzo del team rimane elevato, il che significa che viene creato sempre più valore (percepito).

Nel mio lavoro con i team, osservo regolarmente i team che cercano di affrontare l'incertezza inerente alla scoperta dei prodotti con piani e liste di controllo sempre più dettagliati.

Una volta, ho lavorato con un team in cui i dirigenti chiedevano un "grande cambiamento" per fare davvero la differenza con la prossima versione del prodotto. Quindi al team sono state concesse risorse per esplorare nuove direzioni. Allo stesso tempo, l'impazienza di vedere risultati concreti è stata tangibile fin dal primo giorno. Un tentativo di tenere sotto controllo questa impazienza è stato quello di delineare quali attività di scoperta specifiche sarebbero avvenute nelle prossime settimane. E mentre questo approccio è stato utile per programmare in anticipo interviste con gli utenti e workshop di ideazione interfunzionale, è diventato rapidamente una "promessa" con poco spazio per correggere.

Questo mi ha portato a ripensare a come aiutare i team a trovare il proprio percorso attraverso la "giungla" di Product Discovery. Sono arrivato a credere che non ci sia un unico percorso per governarli tutti. Si tratta invece di fornire ai team le competenze, i metodi e la sicurezza per definire ed eseguire i loro approcci individuali.

Ovviamente, questo dipende molto dalla cultura aziendale. Ma è un cambiamento nel comportamento che può essere innescato anche dai singoli membri del team. Assumere la proprietà di Product Discovery e dei suoi risultati è uno dei passaggi più importanti per passare dall'essere una Feature Factory all'essere un team di prodotti potenziato.

Spostare l'attenzione dalla consegna alla scoperta orientata ai risultati

L'invio di team di prodotto in una missione di scoperta richiede una mentalità diversa (soprattutto se l'azienda si è concentrata sull'output). Ciò che funziona per la consegna non si traduce in lavoro di scoperta. Le squadre devono disimparare alcune abitudini.

Molte aziende utilizzano gli artefatti e i rituali di Scrum per chiarire i loro sforzi di consegna: il "cosa deve essere fatto". E mentre uno sprint di 2 settimane dovrebbe, in teoria, essere incentrato sull'obiettivo dello sprint qualitativo, la misura finale del successo per la maggior parte dei team è definita dal fornire il "risultato" (ovvero il numero di storie). In questo modello, una squadra migliora quando la sua velocità migliora.

Questo modello mentale si rompe durante la scoperta del prodotto. Come mai? Da una prospettiva a volo d'uccello, le possibili fasi di un Product Discovery possono essere suddivise in questo modo:

Le fasi si costruiscono l'una sull'altra, ma non sono sequenziali/lineari. A seconda del contesto, potrebbero non essere nemmeno necessari. Lavorare in un'area non garantisce il successo (né lavorare in tutte le aree). In un certo senso, devi scrivere il tuo playbook.

Esempio: stavo lavorando a un'integrazione JIRA per uno strumento aziendale b2b. Dopo un approfondito lavoro di scoperta, alcune difficoltà hanno iniziato a emergere quando abbiamo cercato di guidare l'adozione dell'MVP. Anche se abbiamo identificato gli amministratori JIRA come attori a cui vale la pena prestare attenzione, non abbiamo parlato con loro in prima persona.

Questo ci ha davvero raggiunto. Anche se avevamo un prodotto che piaceva ai nostri utenti effettivi (e confermato che ha risolto un problema), gli amministratori di JIRA avevano una prospettiva completamente diversa. Poiché non abbiamo parlato direttamente con loro, abbiamo perso completamente i cambiamenti nel comportamento che dovevamo creare per loro. Questa consapevolezza ci ha fatto tornare al tavolo da disegno (noto anche come la nostra Impact Map), per ripensare ai risultati di cui avevamo bisogno per ottenere non solo i nostri utenti primari, ma anche gli utenti secondari come gli amministratori JIRA.

Scoprire e comprendere lo spazio problematico è impegnativo. Ma le sfide non si fermano qui. Le informazioni sono spesso difficili da collegare con il valore aziendale effettivo, il che le rende meno tangibili per i colleghi e le parti interessate esterne al team di scoperta. Invece di ottenere uno pseudo-buy-in attraverso le prime discussioni sulle funzionalità, il team deve rimanere concentrato sul problema e sullo spazio dei risultati. Sebbene tu possa pianificare in modo più dettagliato il passaggio successivo immediato della scoperta, il percorso generale spesso rimane non ovvio fino al termine dell'esperimento successivo.

Per ribadire il punto sopra, questo è ben lontano dalla gestione del prodotto incentrata sulla consegna. Il team è in missione per rivelare i cambiamenti nel comportamento che contano veramente prima che possa iniziare a cercare soluzioni. Fino a quando ciò non accadrà, la squadra dovrà adattare il suo approccio. Avrai bisogno del supporto necessario.

Gli antipattern comuni includono:

1. Misurare il successo del team in base alla velocità delle attività di scoperta completate. Questo potrebbe aiutarti a determinare la diversità dei metodi di scoperta, ma non ti aiuterà a capire se quei metodi erano all'altezza della sfida.
2. Trasformare regolarmente ogni nuova idea in un'altra versione dell'idea originale di uno stakeholder.
3. Iterazioni infinite senza nuove intuizioni. Ad un certo punto devi riconsiderare il tuo approccio.
4. Non impegnare le risorse/il tempo e fare "lavori di scoperta" solo di nome.

Come primo passo, concordare in modo collaborativo un periodo di tempo fisso per una missione di scoperta. Considera questo timebox come un vincolo abilitante, non come una corsa per spuntare quante più caselle possibile. I team dovrebbero affrontare la sfida con un approccio "best-effort" e cercare di ridurre il più possibile l'incertezza della missione.

È fondamentale che il team scelga le fasi su cui concentrarsi e i metodi da utilizzare. Tuttavia, per evitare una percezione da "scatola nera" di un processo di scoperta del prodotto, dovrebbe condividere tali decisioni con il resto dell'organizzazione.

Sebbene in teoria sia facile concordare sulla non linearità di Product Discovery, è più difficile giustificare il salto e il ciclo delle attività nella realtà. In questo caso, il vantaggio di avere l'allineamento attorno allo spazio problematico è un'ancora importante. Quando una scoperta/intuizione non spinge il team "in avanti", ma richiede invece di fare un passo indietro o semplicemente di ripetere, il team deve avere una base per argomentare a favore.

Nella maggior parte dei casi, questo dovrebbe essere il modo in cui l'ultima intuizione ha aumentato o diminuito la fiducia del team nel contribuire all'impatto desiderato. Se semplicemente "non sembra giusto", i team avranno difficoltà a sostenere la non linearità.

Cerco di incoraggiare i team a creare la propria cassetta degli attrezzi per la scoperta dei prodotti, invece di attenersi a framework e processi popolari. Non si tratta di "superare" il prossimo sforzo di scoperta. Piuttosto, i team dovrebbero sforzarsi di costruire questo muscolo e aumentare la fiducia per gli sforzi futuri di scoperta. La creazione di una cassetta degli attrezzi e l'aumento della fiducia dell'organizzazione sono passaggi fondamentali affinché i team si assumano la responsabilità delle attività di scoperta dei prodotti.

Sommario

Penso che sia giunto il momento di sfidare l'idea della "corretta" scoperta del prodotto. Ambienti complessi e sfide aziendali in continua evoluzione richiedono adattabilità e sfidano l'idea di un processo di scoperta del prodotto lineare e rigido.

È importante che i team siano pienamente consapevoli di quali metodi sono appropriati per le sfide che devono affrontare e sappiano come combinarli in modo efficace. Le aziende non hanno successo a causa di uno specifico processo predefinito di Product Discovery. Ci riescono perché incoraggiano i team a trovare la propria strada e supportano questo sviluppo con formazione e sicurezza psicologica.

Pronto per iniziare? Ecco un bonus per aiutarti.

Per me è importante che tu possa togliere qualcosa di tangibile dalle storie condivise in questo articolo. Per aiutarti a fare proprio questo, ho creato per te una sezione bonus speciale.

I bonus gratuiti includono:

1. Un corso e-mail di Product Discovery Navigator gratuito di 6 giorni per aiutarti a rimanere in linea durante Product Discovery
2. Le mie migliori pratiche per superare il bias di conferma in Product Discovery
3. Quello che avrei voluto sapere quando ho eseguito le mie prime scoperte

Puoi entrare nell'area bonus iscrivendoti qui.