Creare nuovi prodotti che piacciano alle persone è difficile, soprattutto perché si tratta di un processo complesso che esige molto tempo. Ci chiede di imparare dai nostri errori in un contesto in cui tornare indietro per correggerli non è mai ben accetto.
Il processo per dar vita a qualcosa di grande richiede creatività e disciplina. Molti prodotti falliscono perché queste due componenti in gioco non si supportano reciprocamente; invece, si limitano a vicenda.
Arginare la creatività in un processo rigoroso darà luogo a un prodotto noioso e inutile. Affidarsi solo alla creatività porterà rapidamente al raggiungimento dell’80% dell’obiettivo, senza però essere mai in grado di dare il tocco finale agli aspetti importanti.
Per anni ho visto fallire prodotti a causa dell’ego, della castrazione creativa e della mancanza di disciplina. Il bisogno di prodotti di qualità oggi è troppo grande per sprecare tempo e talento.
Attraverso la realizzazione di prodotti in Translated e Memopal, la mia società di cloud storage, e l’osservazione di così tante startup fantastiche, ho ideato un metodo volto a raggiungere l’equilibrio richiesto fra creatività e disciplina, un modo rapido e pre-approvato per tornare indietro e correggere gli errori, che incorpora anche due elementi comuni nei prodotti di successo: visione e psicologia. Il team è composto almeno da:
- Il product manager (PM), che ha il compito di coordinare.
- Uno o più utenti, che hanno il compito di evidenziare i punti critici e la loro importanza.
- Uno o più sviluppatori, che hanno il compito di trovare soluzioni per i punti critici dell’utente e di stimarne i costi.
Se siete un founder singolo vi suggerisco di svolgere il ruolo di PM e, se possibile, di coinvolgere qualcun altro come sviluppatore. I founder singoli possono svolgere il duplice ruolo di PM e di sviluppatore, ma questa non è la situazione ideale, perché porta alla naturale esigenza di rimanere nella propria zona di comfort, mentre questo metodo è concepito appunto per evitare questa trappola.
La maggior parte delle persone crea prodotti senza coinvolgere l’utente nel ciclo iniziale. La ritengo una pessima idea. Per avere successo senza l’utente serve molta fortuna, e gli utenti sono molto più abbondanti della fortuna.
Identificate i punti critici
Richiede diverse riunioni di un’ora. L’utente esprime il problema percepito. Il PM pone domande per chiarire e approfondire la problematica, finché non emerge la vera causa del punto critico. Gli sviluppatori partecipano come osservatori silenziosi. È qui che la qualità del PM diventa evidente: quanto è possibile approfondire le cause alla radice del punto critico senza essere considerati degli scocciatori? In genere l’utente cercherà di compiacere il PM, dicendo che sarebbe felicissimo che quel problema fosse risolto. Tuttavia, il PM non dovrebbe ascoltare ciò che dice l’utente: il PM dovrebbe osservare cosa fa. A tale scopo consiglio spesso di fingere che esista già un prodotto adatto a risolvere il problema, che si chiama X e costa Y. A quel punto chiedete all’utente: “Vuoi che te ne procuri uno adesso?”. Se dice di sì, avrete identificato un problema percepito rispetto a cui vale la pena di agire; se dice di no, oppure inizia a introdurre ulteriori requisiti e complicazioni, dovreste ricominciare daccapo l’intero processo. Il PM traduce ogni punto critico in un’attività.
Aggiungete la visione
Diverse riunioni da un’ora per discutere di come sarà idealmente il prodotto in futuro. I partecipanti non dovrebbero pensare che si tratti di ciò che viene loro chiesto di costruire adesso, ma piuttosto che cosa ritengono sarà possibile un giorno. Il product manager chiederà agli sviluppatori come pensano sia possibile superare le aspettative dell’utente, tenendo conto dei problemi percepiti. Parleranno di ciò che la tecnologia potrebbe potenzialmente fare. Il PM dovrebbe chiedere la stessa cosa all’utente e alla fine esporre il proprio punto di vista. Normalmente il PM è responsabile della visione, ma parlando per ultimo si assicura di poter sfruttare la creatività dei partecipanti. La discussione dovrebbe continuare fino a quando il PM conferma che il prodotto futuro sarà tecnicamente fattibile e apprezzato dall’utente. Il PM traduce le idee in attività.
Aggiungete il pathos
I prodotti di maggior successo danno agli utenti qualcosa di più della semplice soluzione di un problema percepito. Far fronte alla vanità, alla pigrizia e al desiderio di qualcosa che non possiamo avere: questi sono alcuni degli elementi che accomunano i grandi prodotti. Queste riunioni funzionano meglio se coinvolgono solo il PM e l’utente in un colloquio a tu per tu. Il PM dovrebbe mettere l’utente nella posizione di parlare del proprio lavoro o della propria vita e per un momento dimenticare la creazione del prodotto. Il PM dovrebbe chiedere all’utente che cosa secondo lui lo fa spiccare rispetto ai suoi pari, che cosa lo annoia e che cosa vuole ma non può avere. Tutto ciò viene tradotto in attività.
Stabilite priorità e versioni
Tutte le attività derivate da punti critici, visione e psicologia saranno inserite in una tabella simile a questa:
| Attività | Costo (€) | Impatto (€) | Priorità |
|---|---|---|---|
| Fare in modo che gli utenti facciano clic con il pulsante destro sulla foto per condividerla | 2.000 | 10.000 | 5,0 |
| Versione 1 | |||
| Zoom Foto | 1.500 | 5.000 | 3,3 |
| Support Android | 10.000 | 10.000 | 1,0 |
| Versione 2 | |||
| Organizzazione automatica delle foto | 50.000 | 25.000 | 0,5 |
| Scelta automatica delle foto migliori | 20.000 | 5.000 | 0,2 |
| Versione 3 | |||
La voce “costo” corrisponde a una stima del costo totale dell’attività; questo campo dovrebbe essere compilato solo dai tecnici. L’impatto è un punteggio o un valore economico associato all’attività. Dovrebbe essere compilato dagli utenti, possibilmente senza vedere il costo. L’aspetto importante non è la cifra di per sé, ma il rapporto tra le attività. Se un’attività ha un valore doppio rispetto ad un’altra, il suo impatto dovrebbe essere due volte maggiore. Il PM dovrebbe richiedere ai tecnici e all’utente di assicurarsi che le stime siano corrette. Il PM calcolerà la priorità come rapporto tra impatto e costo e classificherà le attività in ordine di priorità decrescente. Il PM, con l’aiuto dell’utente e dei tecnici, disegnerà linee orizzontali per pianificare le versioni.
Il raggruppamento delle attività in versioni in base alle priorità garantisce che il rapporto massimo tra qualità e prezzo sia presente nella prima versione. Questo è fondamentale per far incontrare prodotto e mercato. Se la value proposition desiderata non emerge dalla prima versione, il PM dovrebbe riconsiderare le stime precedenti e la value proposition stessa, perché è possibile che il problema non sia sufficientemente percepito perché valga la pena lavorarci.
Riesame
Create la versione 1 del prodotto e chiedete all’utente di usarla. Richiedete pre-ordini con uno sconto equo, dato che si tratta del prodotto alfa. Se l’utente pre-ordina, passate alla versione 2 e ripetete di nuovo.
Se l’utente non preordina perché non ritiene che il prodotto stia affrontando il punto critico, tornate indietro e identificate nuovamente i problemi. Se, dopo qualche ciclo, l’utente continua a non preordinare, il componente più debole tra l’utente, lo sviluppatore e il PM deve essere sostituito e il ciclo riavviato.
Al di là della creatività e della disciplina, se volete costruire buoni prodotti, dovete essere pronti a fare enormi sacrifici, oppure ad avere molta fortuna. Se volete creare un ottimo prodotto, saranno necessari entrambi.