Un processo di product discovery per evitare gli sprechi

Il codice più costoso è quello che nessuno usa. I team investono mesi in funzionalità sviluppate in modo pulito, testate con successo e poi rimaste intoccate, perché il problema era stato dato per scontato, non validato. La product discovery è il lavoro economico che si fa prima del lavoro costoso, per assicurarsi di costruire qualcosa che le persone vogliono davvero. Non deve essere un processo pesante. Deve semplicemente avvenire prima della build, non dopo.

La discovery non è una fase, è un filtro

Non si fa discovery una volta sola e poi ci si ferma. Ogni funzionalità significativa passa attraverso lo stesso filtro: si tratta di un problema reale, per utenti reali, che possiamo risolvere in un modo che adotteranno? L'obiettivo è eliminare le cattive idee a basso costo, su una lavagna, prima che diventino cattivo codice.

Iniziare dal problema, non dalla soluzione

I founder arrivano con soluzioni già in mente: "ci serve una dashboard," "aggiungiamo l'AI." Il primo compito della discovery è tornare indietro fino al problema sottostante. Cosa sta cercando di fare l'utente? Cosa fa oggi? Dove è il punto critico?

Se non si riesce a formulare il problema in una sola frase senza citare la propria soluzione, non si è pronti a costruire. La soluzione è un'ipotesi; il problema è ciò che va validato.

Parlare con gli utenti prima di scrivere una spec

Nulla sostituisce un gruppo ristretto di conversazioni reali. Da cinque a otto interviste con persone che hanno il problema insegneranno più di settimane di dibattiti interni.

• Chiedere di ciò che hanno fatto, non di ciò che farebbero ipoteticamente.
• Approfondire l'ultima volta che hanno incontrato questo problema: i dettagli specifici valgono più delle generalità.
• Ascoltare i workaround: un workaround doloroso è la prova che il problema è reale.
• Resistere alla tentazione di presentare il prodotto. Si è lì per imparare, non per vendere.

Se nessuno descrive il problema che si era ipotizzato, si tratta di un risultato che vale molto più della build evitata.

Validare la domanda prima di impegnarsi

Una volta confermato il problema, verificare se la propria soluzione è desiderata prima di svilupparla completamente:

• Un prototipo cliccabile da mettere davanti a utenti reali.
• Una landing page che misuri l'intenzione di iscrizione.
• Un test concierge in cui si eroga il risultato manualmente, in prima battuta.
• Un fake-door che misuri quante persone cliccano sulla funzionalità.

Questi test richiedono giorni e possono far risparmiare mesi. Un prototipo con cui gli utenti non interagiscono è un "no" a basso costo.

Scrivere cosa cambierebbe la propria opinione

La disciplina che rende la discovery concreta: enunciare l'assunzione più rischiosa e la prova che la confuterebbe. "Crediamo che i responsabili delle operations pagherebbero per automatizzare questo report; ci sbagliamo se meno della metà di quelli con cui parliamo lo considera un costo reale." In questo modo la discovery ha un criterio di successo o fallimento, non una sensazione.

Solo allora definire lo scope della build

Quando il problema è validato, la domanda è dimostrata e le assunzioni hanno superato il confronto con gli utenti, si è pronti a definire lo scope e a costruire, con un rischio molto più basso di sviluppare bene la cosa sbagliata.

In Pykero conduciamo una discovery leggera prima di scrivere codice in produzione, così i nostri clienti non pagano per costruire funzionalità che i loro utenti non hanno mai richiesto. Se sta per impegnarsi su un roadmap, ci contatti.