Skip to main content

Perché siamo in ritardo? Quando finirai la progettazione del prodotto? Se hai già sentito queste parole, non sei solo.

Molte aziende non comprendono come funziona lo sviluppo di un prodotto. Lo considerano un processo lineare, come se aggiungere risorse extra potesse magicamente risolvere ogni problema. In realtà, è molto più controintuitivo e complesso di così.

Nel corso della mia carriera mi è capitato spesso di sfatare alcuni dei più comuni miti sullo sviluppo dei prodotti. In un ambiente di una nuova impresa, questo può essere molto caotico, ma allo stesso tempo gratificante. Pensala in questo modo: è più facile risolvere qualcosa prima che acquisti slancio. 

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

La sfida, però, consiste nel portare tutti sulla stessa lunghezza d’onda prima che il danno sia fatto. L’ultima cosa che vuoi è che sul posto di lavoro si inneschi un tiro alla fune. Se non viene controllato, diventa un altro incendio destinato a non spegnersi rapidamente.

Se ti occupi di sviluppo di prodotti e ti chiedi dove stai sbagliando, dai un’occhiata a questi comuni miti sullo sviluppo dei prodotti. Ti aiuterà a lavorare al meglio. 

Passiamo a sfatare alcuni miti professionali

Chiariamo subito una cosa: lo sviluppo di un prodotto è un’attività completamente diversa dalla produzione. Nella produzione puoi controllare i costi e aumentare l’efficienza nel modo convenzionale. Ma se lo fai nello sviluppo di un prodotto, finirai per causare più danni che benefici. 

Perché? Perché la produzione è prevedibile. Le attività sono ripetitive, come ingranaggi di una macchina. Lo sviluppo di un prodotto, invece, è dinamico e in continua evoluzione. Non esiste un unico modo corretto per farlo: impari strada facendo. Questo ci porta al primo mito sullo sviluppo dei prodotti.

Abbiamo raccolto il meglio: prompt AI, offerte esclusive e una biblioteca di risorse per leader di prodotto. Sblocca il tuo account per accedere.

Mito 1: più risorse significano prestazioni migliori

Più risorse immesse equivalgono a più risultati: sembra perfettamente logico, ma questa logica è pericolosa e fuorviante nello sviluppo di un prodotto. 

Secondo i sondaggi, la maggior parte dei responsabili dello sviluppo dei prodotti mantiene l’utilizzo della capacità al di sopra del 98 percento. È logico pensare che più una squadra lavora, maggiori saranno i risultati che riuscirà a produrre.

Nella pratica, però, non funziona così. Un utilizzo elevato delle risorse porta a prestazioni peggiori della squadra e a risultati inferiori. Per quanto tu possa essere un buon responsabile, non puoi semplicemente aggirare questo problema. Tuttavia, molti responsabili lo ignorano per due motivi principali:

1. Sottovalutano quanto sia imprevedibile lo sviluppo di un prodotto. Un progetto può arrivare sulla tua scrivania in qualsiasi momento. Non puoi prevedere di che tipo di progetto si tratterà, quale tipo di competenze ti serviranno e quanto tempo richiederà.

Lo sviluppo di un prodotto è tutto fuorché lineare. Aggiungere un utilizzo elevato delle risorse a questa situazione porta a ulteriori ritardi, intoppi e code. Questo accade perché, se una squadra lavora sempre al 100%, ogni nuovo progetto deve essere messo in coda, dato che non esiste alcun margine di capacità.

Grafico della teoria delle code
Il grafico precedente è un modello matematico della teoria delle code. Mostra che i tempi di attesa aumentano esponenzialmente con l’utilizzo delle risorse. L’effetto è più evidente tra l’80 e il 90 percento di utilizzo delle risorse.

2. Una cosa che i responsabili di prodotto sottovalutano regolarmente è quanto le code possano danneggiare le prestazioni. Quando una squadra di sviluppo prodotto lavora alla massima capacità e gestisce diversi progetti contemporaneamente, è inevitabile che metta in sospeso i progetti bloccati nelle fasi di approvazione e verifica.

Supponiamo che tu stia progettando un prodotto e che, a metà del lavoro, non possa procedere perché ti serve il via libera del reparto di ingegneria. Immagina che questa approvazione richieda tre settimane. Cosa fai? Resti fermo per tre settimane o nel frattempo inizi un nuovo progetto? La maggior parte degli sviluppatori di prodotti sceglie la seconda opzione, senza rendersi conto che si sta preparando al disastro.

Quando ottieni l’approvazione, starai lavorando a un progetto diverso e non avrai la capacità necessaria per riprendere quello precedente. Di conseguenza, il progetto originale rimane in coda, a meno che tu non liberi una parte della capacità per ripartire da dove ti eri fermato. Nel frattempo, il progetto inattivo rischia di diventare obsoleto se cambiano le tendenze del mercato.

Ancora una volta, questa è una conseguenza dell’elevato utilizzo delle risorse. Lavorare alla massima capacità crea code più lunghe. Questo circolo vizioso continua finché non smaltisci l’arretrato o aumenti la tua capacità di lavoro creando una nuova squadra. In altre parole, le code:

  • Aumentano i costi dei ritardi, i costi di processo e i tempi di ciclo.
  • Mettono i progetti in sospeso. Più a lungo tieni i progetti in sospeso, più diventano vulnerabili ai cambiamenti del mercato.
  • Rendono lo sviluppo dei prodotti ancora più variabile.

Ecco come risolvere questo dilemma sull'allocazione delle risorse:

  1. Limitare il numero di progetti attivi. Questo ridurrà il tasso di utilizzo, libererà una parte della capacità e porterà a un numero inferiore di code. Inoltre, il team sarà più concentrato sulle attività da svolgere.
  2. Rendere più visibile l'inventario del lavoro in corso (WIP). Nello sviluppo dei prodotti, il WIP è invisibile, ed è per questo che è così difficile allocare le risorse in modo efficace. Ho sempre trovato molto utili le lavagne di controllo visivo nei software per lo sviluppo dei prodotti per rimanere aggiornato. Si possono organizzare riunioni quotidiane di 10 minuti oppure utilizzare molti post-it. L'obiettivo è fare in modo che tutti comunichino il più possibile le proprie tappe intermedie.
  3. Allineare gli obiettivi dei reparti. Considerate di nuovo l'esempio in cui dovete aspettare tre settimane per ottenere un'approvazione. Cosa succederebbe se bastassero solo un paio d'ore? A tal fine, è necessario sincronizzare gli obiettivi dei reparti modificando i sistemi di controllo gestionale. La maggior parte dei manager vuole aumentare la capacità senza rendersi conto che potrebbe ricavarne molta di più se modificasse le operazioni e le rendesse efficienti.

Mito 2: lavorare in grandi lotti migliora il processo di sviluppo

Lavorare in grandi lotti funziona bene nella produzione manifatturiera, ma non nello sviluppo dei prodotti. I grandi lotti significano più code e più code portano a una maggiore quantità di lavoro in corso e a tempi di ciclo più lunghi.

Supponiamo che un team debba costruire 300 componenti di una macchina. Può costruire tutte le parti insieme oppure lavorare in lotti da 20. Se decide di costruire tutte le parti insieme:

  • Le code saranno più lunghe
  • I tempi di ciclo saranno più lunghi 
  • Il feedback sarà minimo

Un piano di sviluppo del prodotto potrebbe non procedere interamente come previsto. Sarà necessario modificare le specifiche tecniche o qualche altra caratteristica del prodotto. L'unico modo per affrontare questa curva di apprendimento è attraverso il feedback.

Il feedback è l'informazione che si acquisisce testando il prodotto e osservandone le prestazioni. È necessario per determinare se il processo di sviluppo richiede modifiche sulla base di fattori tecnici. Un feedback inferiore porta a tempi di ciclo più lunghi. Il tempo di ciclo è il tempo trascorso tra il completamento della progettazione e la produzione. È possibile misurarlo utilizzando la legge di Little.

Nel secondo caso, la dimensione del lotto è inferiore del 90%. 

  • Il lavoro in corso è minimo o inesistente 
  • Nessuna coda 
  • Feedback rapido
  • Qualità ed efficienza migliori e tempi di ciclo ridotti

Molti sviluppatori di prodotti scelgono la prima strada, pensando che lavorare in grandi lotti produca economie di scala. Ma ciò è ben lontano dalla realtà. Raggiungere una dimensione ottimale del lotto consiste nel bilanciare i costi di transazione e i costi di mantenimento. 

Se oggi fai scorta di uova per un anno, potresti ottenere un buon prezzo, ma la maggior parte delle uova andrebbe a male. In altre parole, avresti un costo di transazione basso, ma un costo di mantenimento elevato. Il segreto per ottenere il meglio da entrambe le situazioni consiste nel trovare il giusto equilibrio.

Grafico della dimensione ottimale del lotto
La dimensione ottimale del lotto è quella in cui il costo totale è più basso e il costo di transazione interseca il costo di mantenimento.

Raggiungere la dimensione ottimale del lotto non è affatto semplice. Varia da un'azienda all'altra. Ad esempio, se gestisci un negozio di alimentari, i costi di mantenimento saranno molto più elevati rispetto a quelli di un produttore di acciaio. In definitiva, scegli una dimensione del lotto che non crei nuovi colli di bottiglia e che comporti i costi più bassi.

Articolo correlato: Come creare un ciclo di feedback efficace dei clienti per i team di prodotto?

Mito 3: riempi il prodotto di funzionalità e i clienti lo ameranno.

Gli sviluppatori di prodotti presumono regolarmente che più funzionalità inseriscono in un prodotto, più questo piacerà ai clienti. Ciò è ben lontano dalla realtà e spesso porta all'accumulo incontrollato di funzionalità. Quante volte hai preso in mano un prodotto e hai scoperto che era troppo complicato da usare?

Succede continuamente. Le cuffie tradizionali hanno troppi pulsanti sul lato, i telecomandi dei televisori sono difficili da usare, gli schermi LCD sono complicati da configurare e la ricarica wireless è ancora una fantasia. Tuttavia, è difficile convincere uno sviluppatore di prodotti a mantenere le cose semplici, soprattutto per due motivi:

1. Gli sviluppatori di prodotti tendono a elaborare così tante idee senza selezionarle. Ho notato che di solito manca un filtro. È come quando una persona dipendente dal lavoro non riesce a sopportare di vedere uno spazio vuoto nella propria giornata. Deve riempirlo con qualcosa di produttivo.

Allo stesso modo, gli sviluppatori di prodotti vedono un’opportunità ogni volta che trovano uno spazio vuoto in cui aggiungere ulteriori funzionalità a un prodotto, indipendentemente dal fatto che il consumatore le utilizzi mai oppure no.

Apple Inc. è un ottimo esempio del contrario. Mantiene sempre semplicità ed eleganza in primo piano. Lo sviluppo del prodotto parte dall’utente finale e procede a ritroso verso la tecnologia. In altre parole, è il consumatore a guidare la tecnologia, non il contrario. Infatti, il team di progettazione di Apple ha l’ultima parola prima che un prodotto venga immesso sul mercato.

Accumulo di funzionalità non necessarie in un prodotto non aggiunge valore per il cliente. McKinsey riferisce che la maggior parte delle aziende “monitora la soddisfazione dei clienti rispetto alle prestazioni del prodotto [e] solo il 44 per cento misura la soddisfazione dei clienti rispetto al prezzo pagato per il valore ricevuto”.

Le aziende che si affidavano maggiormente a quest’ultima metrica ottenevano risultati migliori in termini di crescita e stabilità dei profitti, sia a breve sia a lungo termine. Nel frattempo, quelle che si concentravano esclusivamente sulle prestazioni del prodotto perdevano opportunità di crescita a lungo termine.

Grafico delle metriche incentrate sul prodotto
Il grafico qui sopra mostra che guidare lo sviluppo del prodotto con metriche incentrate sul prodotto può portare a buoni risultati a breve termine, ma a scarsi benefici a lungo termine.

2. Gli sviluppatori di prodotti amano ostentare la propria competenza. Tanto che a volte dimenticano che conta più l’esperienza del cliente degli aspetti tecnici. Tutto ciò che i consumatori desiderano è un’esperienza utente fluida, una soluzione che funzioni senza sforzo.

Per riuscirci, gli sviluppatori di prodotti devono sapere cosa omettere. Mettiti nei panni dei consumatori. Vorresti acquistare un frigorifero dotato di un sistema audio integrato? All’inizio può sembrare interessante, ma ascoltare canzoni da un frigorifero è semplicemente scomodo.

Riduci il tuo elenco. Le funzionalità del prodotto che scegli dovrebbero essere essenziali oppure far risaltare il prodotto. Ricorda che un prodotto non è finito quando non puoi più aggiungere funzionalità, ma quando sottrarne un’altra lo renderebbe peggiore anziché migliore. 

Ecco un esempio del processo che ho utilizzato lavorando con designer UX/UI per creare un’app semplice e facile da usare per i rivenditori.

  1. Dedica del tempo all’ideazione, che consiste sostanzialmente nel porre le domande giuste e rispondere ai “come”. Questa è l’opportunità per andare oltre l’ovvio e cercare soluzioni innovative confrontandoti con il tuo team. Stabiliamo anche un limite di tempo per non esagerare. Non vuoi sacrificare la creatività per guadagnare tempo ed efficienza.
  2. Dopo aver delineato la tua visione del prodotto finale, penso che il passaggio più importante, spesso trascurato dalla maggior parte degli sviluppatori, sia partire dalla fine e ricostruire a ritroso il percorso. Questo ti aiuta a individuare tutti i passaggi necessari per arrivare al prodotto finale. La maggior parte degli sviluppatori parte da zero e finisce per perdere di vista ciò che aveva pianificato inizialmente.
  3. Come accennato in precedenza, il piano di sviluppo del prodotto può cambiare, e infatti cambia. Nel completare tutti i passaggi, il brainstorming continua, solo che ora è incentrato sugli aspetti tecnici. Consideralo come una messa a punto dell’idea concepita inizialmente e come un modo per portarla al livello successivo.

Mito 4: Attenersi al piano, costi quel che costi

Come recita il proverbio, “i piani meglio congegnati di uomini e topi spesso vanno storti”. Non potrebbe essere più vero. Dall’inizio alla fine, lo sviluppo del prodotto è fatto di tentativi ed errori. Sperimentare permette di riconoscere le lacune trascurate in precedenza.

Uno studio del MIT rivela la natura dinamica dello sviluppo del prodotto. Gli ingegneri aerospaziali che lavoravano a un sottosistema hanno esaminato diversi progetti prima di selezionare quello migliore. Tuttavia, durante l’intero processo ingegneristico, le loro preferenze sono cambiate sulla base dei risultati dei test.

Lo sviluppo del prodotto riguarda interamente l’innovazione. Si parte da una concezione iniziale del prodotto e la si modifica strada facendo. Forse il retro in vetro del telefono si surriscalda troppo, oppure i bordi curvi non consentono di inserire l’antenna GPS. Queste informazioni si ottengono solo iniziando a testare e sperimentare.

Come discusso in precedenza, lo sviluppo del prodotto parte dal cliente, non dalla tecnologia. Ma come si può valutare ciò di cui il cliente ha bisogno? La maggior parte dei clienti insoddisfatti non si lamenta di un prodotto: se ne va e basta. Peggio ancora, cosa succede se le preferenze dei clienti cambiano durante il processo di sviluppo a causa dell’evoluzione delle tendenze del mercato?

La risposta a tutte queste domande è cambiare il piano di sviluppo. Questo non significa che pianificare sia inutile; significa che devi essere meticoloso fino all’ultimo dettaglio. Tratta il tuo piano come un’ipotesi anziché come una legge perché, in fin dei conti, non vuoi un piano perfetto: vuoi un prodotto perfetto.

Ecco alcune cose che puoi fare per mantenere più flessibile il tuo piano di sviluppo del prodotto:

  1. Sviluppa un piano generale. Consideralo come uno scheletro, una struttura di base che guiderà il tuo processo di sviluppo. Lascia da parte i dettagli perché finiranno per trovare la loro collocazione. Potresti persino dover modificare la struttura di base per adattarla ad alcuni dettagli assolutamente essenziali per il tuo prodotto.
  2. Prevedi che il tuo piano possa presentare delle lacune. Non puoi davvero prevedere tutto. Ecco perché il tuo piano dovrebbe avere un margine di sicurezza sufficiente su cui fare affidamento. Elabora delle alternative alla struttura di base che hai già creato.

Articolo correlato: I migliori software per la pianificazione dei prodotti

Considerazioni finali

Non c’è dubbio: agli sviluppatori di prodotti sono affidati alcuni dei lavori più difficili al mondo. L’innovazione richiede tempo e molta sperimentazione. Non puoi trattarla come un processo ordinario, come la fabbricazione o la produzione. In qualità di sviluppatore di prodotti, posso confermare che la maggior parte dei dirigenti non lo capisce. Vivono all’interno di questi miti e qualcuno deve far scoppiare la loro bolla.

Per quanto lo sviluppo dei prodotti sia entusiasmante, può essere altrettanto frustrante e logorante, sia che tu abbia una persona per ogni mansione, sia che tu stia gestendo i prodotti senza una squadra completa. La chiave per mantenerti al meglio è liberarti dei miti sopra elencati. Se sei un nuovo responsabile di prodotto, ti abbiamo appena risparmiato innumerevoli grattacapi e riunioni inutili. Se sei un professionista esperto, non esitare a condividere altri miti sulla gestione dei prodotti nella sezione dei commenti qui sotto.

Per ricevere altri articoli e consigli illuminanti sulla gestione dei prodotti, scritti da esperti del settore per aiutarti a rimanere all’avanguardia, iscriviti alla newsletter di The CPO Club.

Oppure ascolta alcuni dei nostri podcast, come questo: Coltivare lo slancio (con Paul Ortchanian di Bain Public)