CB Insights pubblica una ripartizione annuale del motivo per cui le startup falliscono. Per anni, il motivo numero uno è stato lo stesso: "nessun bisogno di mercato." Non scarsa esecuzione. Non finire i soldi. Non un cattivo team. Il prodotto semplicemente non risolveva un problema di cui le persone si curassero abbastanza da cambiare il loro comportamento.
Quella statistica è sbalorditiva quando consideri quanto sforzo va nella costruzione di prodotti. I team passano mesi — a volte anni — progettando sistemi, scrivendo codice, discutendo di architettura e perfezionando flussi. E il motivo più comune per cui falliscono è che nessuno ha chiesto se tutto questo stesse risolvendo un problema reale.
Costruire prodotti che le persone vogliono davvero non è un talento. È una disciplina. Ha un metodo, e quel metodo può essere imparato.
L'errore più comune nei prodotti è innamorarsi di una soluzione prima di comprendere profondamente il problema. Questo è quasi universale tra i founder al primo tentativo e sorprendentemente comune anche tra quelli esperti. Lo schema è sempre lo stesso: qualcuno ha un'idea, la trova interessante e inizia a costruire. Il cliente è un ripensamento — qualcuno da convincere, non da comprendere.
L'antidoto non è complicato ma richiede disciplina: passa più tempo sul problema che pensi sia giustificato, prima di considerare affatto le soluzioni. Parla con le persone che hanno il problema. Guardali lavorare. Comprendi i workaround che usano oggi e perché quei workaround sono imperfetti. Solo allora hai abbastanza contesto per progettare qualcosa che si adatta davvero.
Lo sviluppo buono del prodotto non è una linea retta — è un ciclo. Ogni iterazione attorno al ciclo è un'opportunità per sostituire le ipotesi con l'evidenza. I team che costruiscono prodotti che le persone vogliono sono quelli che completano questo ciclo velocemente e spesso.
Il ciclo non è una formalità. Ogni fase ha un output specifico che diventa l'input per la successiva. Saltare le fasi — più comunemente saltando direttamente da Problema a Costruisci — è quello che produce prodotti che mancano il bersaglio.
Non tutti i problemi meritano di essere risolti. Un buon problema di prodotto ha tre qualità: è frequente (colpisce le persone spesso, non raramente), è intenso (le persone lo sentono abbastanza da volere sollievo), e le soluzioni esistenti sono genuinamente inadeguate (non solo leggermente diverse da quello che costruiresti).
L'errore è ottimizzare per la prima qualità e ignorare le altre due. "Le persone sprecano tempo in riunioni" è frequente. Ma se il dolore è basso — se le persone hanno trovato workaround abbastanza buoni — il problema potrebbe non meritare di essere risolto commercialmente. E se ci sono già dodici strumenti che fanno quello che vuoi fare, hai bisogno di una ragione molto specifica per cui il tuo sarebbe scelto.
La ricerca ha una cattiva reputazione nei circoli prodotto — è associata alle consultazioni lente, ai report spessi e ai risultati che nessuno legge. Questo è un fallimento dell'esecuzione, non della pratica. La buona ricerca di prodotto è veloce, specifica e cambia quello che costruisci.
L'obiettivo della ricerca non è confermare che il problema è reale. Dovresti già crederci prima di investire pesantemente in ricerca. L'obiettivo è comprendere il problema abbastanza profondamente da sapere quale sia una buona soluzione: chi specificamente ha il problema, in quale contesto, cosa ha già provato, quali parole usa per descriverlo, e cosa significherebbe "risolto" per loro.
Un'ipotesi è una previsione specifica e falsificabile su quello che credi sia vero. Forza la chiarezza. Se non riesci a scrivere un'ipotesi chiara, non capisci ancora il problema abbastanza bene per costruire una soluzione.
Un'ipotesi di prodotto utile ha tre parti:
Il segnale è la parte più importante — e quella più comunemente omessa. Senza un segnale pre-concordato, ogni esperimento "funzionava più o meno." I team trovano modi per interpretare i dati ambigui favorevolmente. Un'ipotesi senza una condizione di falsificazione è solo un desiderio.
La fase di costruzione è dove la maggior parte dei team passa troppo tempo. L'obiettivo non è costruire il prodotto — è costruire la cosa minima che ti darà segnale sulla tua ipotesi. Questi sono obiettivi diversi e producono output molto diversi.
Per la maggior parte delle ipotesi in fase iniziale, il minimo è molto meno di quello che i team pensano. Puoi manualmente fare quello che il software farebbe, per dieci persone, per testare se lo valorizzano? Puoi mettere insieme strumenti esistenti e testare il flusso prima di costruire nuova infrastruttura? Puoi disegnare un prototipo e camminarlo attraverso con cinque utenti prima di scrivere qualsiasi codice?
La disciplina qui è chiedere, prima di costruire qualsiasi cosa: "Cosa sto cercando di imparare?" e "Qual è la cosa minima che mi permetterebbe di impararlo?" La risposta è quasi sempre più piccola di quello che il team vuole costruire.
Dopo il lancio — che si tratti di un prototipo, di un pilota manuale o di una funzionalità distribuita — la fase di misurazione è dove i team si ingannano più comunemente. Chiedono agli utenti se è piaciuto. Gli utenti dicono di sì. Il team contrassegna l'esperimento come validato.
Il sentimento non è segnale. L'unico segnale affidabile è il comportamento: le persone hanno fatto la cosa? Sono tornate? Hanno pagato? Hanno detto a qualcuno?
Per la misurazione quantitativa, strumento prima di lanciare. Sappi quali azioni specifiche stai tracciando. Imposta una soglia in anticipo — "considereremo questo validato se X% degli utenti completano Y entro Z giorni." Per la misurazione qualitativa, conduci interviste di follow-up strutturate, non sondaggi di soddisfazione a risposta aperta.
La fase di apprendimento riguarda l'aggiornamento del tuo modello mentale dell'utente e del problema, non solo decidere cosa costruire dopo. I team che saltano questo passaggio raccolgono dati ma non accumulano comprensione. Eseguono velocemente ma non migliorano il loro giudizio nel tempo.
Una buona sessione di apprendimento chiede: cosa abbiamo previsto? Cosa è effettivamente successo? Cosa ci dice il divario su le nostre assunzioni? Qual è la cosa più importante che non sappiamo adesso?
L'output della fase di apprendimento è una definizione del problema più netta, un'ipotesi rivista, o — se l'esperimento è chiaramente fallita — una decisione di perseguire una direzione completamente diversa. Tutti questi risultati sono preziosi. Il peggior risultato è l'ambiguità: "abbiamo imparato alcune cose ma non siamo sicuri di cosa fare dopo." Questo è un segno che l'esperimento non era abbastanza specifica.
Lo sviluppo del prodotto non raggiunge mai uno stadio in cui smetti di eseguire questo ciclo. Le domande cambiano — all'inizio stai validando se il problema è reale; più tardi stai validando se un elemento di soluzione specifico funziona — ma la struttura è sempre la stessa. Osserva, ipotizza, testa, impara.
I team che costruiscono prodotti che le persone vogliono non sono quelli con l'intuizione iniziale più intelligente. Sono quelli che completano il ciclo più velocemente e più onestamente. La velocità di apprendimento, non la velocità di spedizione, è il vantaggio competitivo.