Quante volte usando un nuovo prodotto, ad esempio un elettrodomestico o un nuovo smartphone, ci siamo sentiti confusi e disorientati davanti alla miriade di opzioni e feature proposte, mentre volevamo semplicemente scaldare una pietanza, lavare rapidamente il bucato o impostare il navigatore satellitare? In questo caso abbiamo toccato con mano gli effetti di un fenomeno tanto esteso quanto ancora poco studiato, la feature fatigue, ovvero la difficoltà (la fatica) sperimentata dall’utente nell’uso di prodotti, ma anche di servizi, che sono “caricati” con un numero eccessivo di feature, risultando, di fatto, difficoltosi da usare per svolgere il compito principale per cui sono stati progettati. Perché quindi includere una miriade di feature aggiuntive quando l’utente, nella maggioranza dei casi di utilizzo, richiede lo svolgimento di un compito basilare? Le motivazioni possono essere molte, consapevoli ed inconsapevoli. Infatti, la feature fatigue è solo uno degli effetti di un fenomeno che ha origine ben prima, durante il processo di sviluppo di un nuovo prodotto, quando forze contrastanti spingono per l’inclusione di feature aggiuntive che spesso portano ad un beneficio marginale per l’utilizzatore finale. Tale fenomeno prende il nome di beyond pathologies per indicare uno stato patologico del processo di sviluppo prodotti in cui l’estensione delle feature offerte va al di là di quanto è richiesto dagli utenti, oltre quanto era stato pianificato inizialmente nella scheda prodotto, o al di là delle effettive risorse allocate al progetto.
Un fenomeno complesso
Il fenomeno delle beyond pathologies è complesso e origina dal concorso di molti fattori, spesso legati tra loro. Questo stato patologico può generarsi consapevolmente durante le fasi iniziali di definizione del concept e delle specifiche di prodotto, quando vengono programmate caratteristiche aggiuntive e incluse tecnologie non strettamente necessarie, magari per anticipare una traiettoria tecnologica e creare un margine di tolleranza per futuri re-design o re-styling del prodotto. La letteratura accademica ci riporta, tra gli altri, l’esempio di Philips che ha commercializzato prodotti con caratteristiche silenti e/o non completamente sviluppate per lasciare le porte aperte a future estensioni qualora le esigenze di mercato lo richiedessero. Avere quindi un prodotto in cui è presente un certo margine di manovra per il futuro è sicuramente positivo, tuttavia, qual è il costo in termini di complessità aggiuntiva e tempi di sviluppo più lunghi? Un altro aspetto interessante delle beyond pathologies, speculare al precedente, è che queste possono originarsi in maniera inconsapevole, spesso frutto delle buone intenzioni di chi è coinvolto nello sviluppo di un nuovo prodotto. Infatti, diverse componenti cognitive ed emotive posso concorrere nell’influenzare il processo decisionale di project manager, ingegneri, sviluppatori e responsabili R&D. Tipici esempi sono l’attaccamento emotivo e irrazionale a un progetto, a una specifica tecnologia o a un particolare set di feature poiché si è direttamente coinvolti nel processo di creazione e sviluppo di un prodotto. Ne è esemplificativo l’effetto Ikea con il quale si tende a sovrastimare il valore reale di un progetto o di una feature poiché si è stati direttamente coinvolti nella sua realizzazione. Un semplice bias cognitivo che però si ripercuote duramente sul progetto di sviluppo di nuovi prodotti, ed è solo la punta dell’iceberg.
Le conseguenze
Quali possono essere le conseguenze sia per chi sviluppa sia per chi poi dovrà utilizzare quei prodotti? Il prezzo da pagare è alto: basti solo pensare che la Nasa ha inserito l’eccesso di feature in fase di progettazione tra le 10 principali cause di fallimento nel processo di sviluppo di nuovi prodotti. La letteratura manageriale ci ha ancora dato poche risposte, ma ha sicuramente sottolineato un drastico crollo della componente ergonomica del prodotto legato all’accresciuta complessità di utilizzo. Abbiamo poi tempi di sviluppo più lunghi, costi di sviluppo più alti e, infine, un rischio maggiore di difettosità dovuto al numero elevato di funzioni con un conseguente aggravio su tutti i processi di supporto post-vendita. Perché quindi decidere di includere così tante feature in un prodotto? Spesso c’è anche una ragione di marketing: i prodotti ricchi di funzionalità sono seducenti quando vengono presentati al consumatore, salvo dimostrarsi poco funzionali nella vita di tutti i giorni.
Cosa possono fare manager e professionisti del settore? Ad oggi sfortunatamente non esiste uno strumento che sia capace di misurare, e quindi evitare, il proliferare di feature durante il processo di sviluppo prodotti o servizi. Gli approcci Stage-Gate, Agile o Ibridi gestiscono in maniera differente il processo di sviluppo, presentando tutti e tre vantaggi e svantaggi, costi di coordinamento diversi e applicabilità varie secondo il contesto e l’oggetto di sviluppo. In altre parole, non esiste un approccio migliore o peggiore, molto si gioca sul lato umano, spesso inconscio, del processo di sviluppo di nuovi prodotti. Stage-Gate, Agile o sistemi Ibridi permettono di limitare la problematica delle beyond pathologies attraverso un’accurata gestione del processo di sviluppo, senza, tuttavia, riconoscere e trattare in maniera puntuale il rischio derivante dalle beyond pathologies. Nell’attesa che sia data una maggior attenzione a queste tematiche a livello sia accademico che consulenziale, manager e sviluppatori possono comunque porre maggiore attenzione nel definire i confini di un progetto di sviluppo di nuovi prodotti, consapevoli di come un aggravio di feature potrebbe portare il progetto verso il fallimento. In particolare, l’irrazionale sottovalutazione della complessità di utilizzo di un prodotto e il disallineamento tra quanto è davvero utile per l’utente e quanto viene offerto dal prodotto in termini di feature sono tra le principali, ma non le uniche, cause di fallimento o scarse performance dei nuovi prodotti.
