Scoperta del prodotto nella pratica: framework testati in casi reali

La parte più costosa della costruzione di un prodotto non è l'ingegneria. È costruire la cosa sbagliata con competenza. Interi team trascorrono mesi per fornire, con una qualità tecnica impeccabile, una soluzione che nessuno aveva chiesto per un problema che non esisteva.

La scoperta del prodotto esiste per evitare esattamente questo. È l’insieme delle pratiche che risponde, prima della costruzione, a una domanda brutale: vale la pena costruire questo? Per chi? Perché?

I framework di scoperta aiutano a strutturare questa indagine. Ma la loro teoria è facile da lodare e difficile da applicare. Ecco perché questo testo si basa su casi reali, situazioni in cui la scoperta ha deciso il destino del prodotto, nel bene e nel male.

Il caso della funzionalità che nessuno ha utilizzato

Inizia con l'errore più comune. Un'azienda decide di creare una funzionalità perché "i clienti lo hanno richiesto". Il team esegue, lancia, celebra e l'adozione è quasi pari a zero.

Quello che è successo? I clienti chiedevano, ma chiedevano una soluzione, non descrivevano un problema. Quando costruisci letteralmente ciò che il cliente chiede, senza indagare sul problema che sta dietro ad esso, spesso fornisci qualcosa che aveva immaginato male.

La scoperta avrebbe cambiato il gioco qui. Un giro di interviste incentrate sulla comprensione del contesto, non della caratteristica, ma del dolore, rivelerebbe che il vero problema era un altro, con una soluzione molto più semplice. La lezione: la richiesta del cliente è un sintomo, non la diagnosi.

Il caso del governo digitale che nessuno potrebbe utilizzare

Nel settore pubblico, lo schema si ripete con conseguenze più gravi. Immagina un municipio che digitalizza un servizio, ad esempio, fissando un appuntamento o emettendo un documento, investendo in una solida tecnologia.

Il sistema diventa operativo, viene annunciato come una modernizzazione e la coda di persona rimane la stessa. Perché? Perché nessuno ha verificato se i veri cittadini potessero usarlo. Il pubblico target includeva persone con scarsa familiarità digitale, connessione instabile e dubbi che il flusso non fosse stato previsto.

La scoperta, qui, non è un lusso da startup. Questo è ciò che evita di spendere soldi pubblici per sistemi che non assolvono alla loro funzione sociale. Alcune conversazioni con cittadini reali, prima di costruire, avrebbero rivelato barriere che nessun incontro interno avrebbe previsto. Il costo della scoperta è irrisorio rispetto al costo di un servizio che esclude chi dovrebbe servirlo.

Framework che funzionano se presi sul serio

I casi reali mostrano che alcuni framework di scoperta reggono meglio di altri sotto pressione.

Continuous Discovery (interviste continue). Invece di ricerche una tantum prima del progetto, conversazioni settimanali con gli utenti nel tempo. La tipica storia di successo è quella del team che scopre presto un'obiezione critica, perché era in costante contatto con coloro che utilizzavano il prodotto.
Albero delle soluzioni delle opportunità. Collega i risultati aziendali, le opportunità scoperte e le soluzioni candidate in un albero visibile. Funziona perché costringe il team a giustificare il motivo per cui una soluzione risolve un'opportunità reale, non un'intuizione.
Test del prototipo prima della codifica. Il caso classico è convalidare un'idea con un prototipo navigabile e scoprire, in un pomeriggio, che il flusso non aveva senso, risparmiando settimane di sviluppo.

Il punto comune di questi framework di successo è il contatto diretto e frequente con la realtà. La scoperta che avviene solo in una sala riunioni, con ipotesi sull'utente anziché conversazioni con l'utente, di solito fallisce nel caso reale.

Il caso della scoperta che è diventato una scusa

Esiste anche il lato opposto, ed è onesto riconoscerlo. La scoperta può diventare paralisi. Ho visto team usare il "siamo ancora in fase di scoperta" come scudo per non decidere mai.

La ricerca che non converge mai non è cura, è paura. In un caso reale di startup, mesi di ricerca hanno ritardato un lancio che il mercato già chiedeva, e lo spazio si è preso un concorrente meno attento ma più determinato.

La scoperta deve avere una scadenza e uno scopo. L’obiettivo non è mai stato quello di capire tutto, ma piuttosto ridurre l’incertezza quanto basta per decidere in modo responsabile. Quando il team confonde la scoperta con la ricerca della certezza assoluta, scambia il rischio di sbagliare con il rischio altrettanto reale di non agire mai.

Il caso della scoperta che ha cambiato la strategia, non solo la funzionalità

Vale un caso che mostra la scoperta operante ad un altro livello, non per decidere una funzionalità, ma per correggere il corso di un'intera scommessa.

Immagina un'azienda convinta che il suo pubblico volesse un prodotto più completo, ricco di funzionalità. L'intuizione della leadership era chiara: la concorrenza era troppo semplice e la differenziazione sarebbe avvenuta attraverso la profondità. Tutta la tabella di marcia puntava in quella direzione.

Un serio giro di scoperte, conversazioni continue, osservazione dell’uso effettivo, hanno rivelato il contrario. Gli utenti non volevano più funzionalità; Volevano che quel poco che già esisteva funzionasse in modo più semplice e affidabile. La complessità che l’azienda intendeva costruire era esattamente ciò che teneva lontane le persone.

Il valore della scoperta, in questo caso, non stava nel risparmiare qualche settimana di sviluppo. L'obiettivo era evitare che l'azienda investisse mesi nella costruzione della propria strategia nella direzione sbagliata. La scoperta, presa sul serio, a volte non modifica ciò che costruisci, ti mette in dubbio se dovresti costruirlo.

Questo è l'uso più difficile e più prezioso. Richiede che la leadership sia disposta a sentire che la loro convinzione potrebbe essere sbagliata. I team che fanno scoperte solo per confermare ciò che hanno già deciso non stanno indagando; Cercano applausi. E gli applausi non proteggono nessuno da una scommessa sbagliata.

Quando la scoperta vale davvero l'investimento

La decisione su quanta scoperta fare è, in sostanza, un’analisi del rischio. Maggiore è l’incertezza e maggiore è il costo di commettere errori, più la scoperta è giustificata.

Costruire una funzionalità piccola, reversibile ed economica? A volte vale la pena correre un rischio e apprendere nell'uso reale, una scoperta approfondita sarebbe uno spreco. Costruire una scommessa costosa, difficile da ribaltare, che definisce la strategia dell'azienda o colpisce migliaia di cittadini? Allora la scoperta non è un costo, è sicura.

I leader maturi calibrano questo caso caso per caso. Trattare la scoperta come obbligatoria in ogni cosa è tanto ingenuo quanto trattarla come facoltativa in ogni cosa. La domanda giusta è sempre proporzionale: quanto perdo se sbaglio, e quanto costa scoprirlo prima?

Chiusura

I casi reali insegnano la stessa lezione in modi diversi. Chi indaga il problema prima di costruire spreca meno, fa più cose bene e dorme meglio. Coloro che saltano questa fase pagano più tardi, in rielaborazione, in denaro, a volte escludendo coloro che avevano più bisogno di essere serviti.

La scoperta non garantisce il successo. Garantisce che quando si commette un errore, lo si commetta in modo economico e tempestivo, con la possibilità di correggerlo. Nel prodotto, questo è quasi tutto.

Se la tua organizzazione tende a costruire prima e a scoprire poi, potrebbe valere la pena invertire l’ordine prima di fare la prossima grande scommessa. Qui sono disponibili altri articoli sui framework di scoperta e progettazione che approfondiscono l'argomento.