In un mondo in cui una funzionalità può essere progettata, programmata e rilasciata più velocemente che mai, il problema principale non è più la velocità di sviluppo. Il problema diventa decidere cosa valga davvero la pena costruire.
C'è un momento nella vita di quasi ogni sistema in sviluppo in cui la lista delle funzionalità comincia a vivere di vita propria.
"Il cliente l'ha chiesto."
"La concorrenza ce l'ha."
"Non dovrebbe essere difficile."
"Dato che abbiamo già questo modulo, aggiungiamo anche..."
"L'IA lo farà in fretta."
E all'improvviso un'altra funzionalità finisce nel backlog. Poi un'altra. E un'altra ancora. Dopo qualche anno l'azienda ha un'app che sa fare quasi tutto. Peccato però che per l'utente sia sempre più difficile trovare ciò di cui ha veramente bisogno.
Non è solo un problema di UX. È un problema di business.
Quando più funzionalità non significano un prodotto migliore
Per anni lo sviluppo software ha seguito una logica abbastanza semplice: se gli utenti hanno bisogno di nuove capacità, aggiungiamo nuove funzionalità. Suona sensato.
Il problema inizia quando lo sviluppo del prodotto viene ridotto al numero di funzionalità consegnate. A quel punto il team inizia a ottimizzare non per il valore per l'utente, ma per il conteggio delle cose che è riuscito a "consegnare".
Nasce la cosiddetta Feature Factory — un'organizzazione che produce nuove funzionalità, ma non misura necessariamente se risolvono davvero i problemi dei clienti.
Questo fenomeno non è nuovo. Nuova è la velocità con cui oggi può svilupparsi.
L'IA accorcia significativamente il percorso dall'idea al prototipo funzionante. Atlassian descrive la trasformazione chiaramente: con gli agenti di sviluppo la strada dal "sapere cosa vogliamo costruire" a un prototipo funzionante può ridursi da settimane a ore.
È un'enorme opportunità. Ma anche una trappola.
Perché se costruire diventa più economico e più veloce, è più facile iniziare a creare cose che prima nessuno avrebbe osato ordinare.
"Se possiamo, allora facciamolo"
Questa è una delle frasi più costose nei progetti IT. Non perché ogni funzionalità aggiuntiva costi una fortuna. Il problema è che una funzionalità non termina la sua vita al momento del rilascio.
Ogni nuovo modulo va poi mantenuto. Va testato. Va considerato nelle modifiche successive. Va documentato. Vanno gestiti i bug. Va formato l'utente. Va considerato nel flusso UX. Va garantita la sua sicurezza. Va verificato che i cambiamenti successivi non lo rompano.
Perciò il costo di una funzionalità non è solo il costo della sua creazione. È anche il costo della sua esistenza futura.
Ed è proprio questo costo che molto spesso non si vede quando qualcuno dice:
"Allora aggiungiamo anche questo..."
La funzionalità più costosa può essere quella che nessuno usa
Immaginiamo un'azienda che sviluppa un pannello B2B.
I clienti possono effettuare ordini, controllare la cronologia acquisti, scaricare documenti e contattare il loro account manager.
Appare l'idea di un sistema di reporting esteso. Il team lo progetta. Gli sviluppatori lo costruiscono. Nascono grafici, filtri, esportazioni, report e dozzine di parametri aggiuntivi. La funzionalità viene rilasciata in produzione.
E allora si scopre che la maggior parte dei clienti vuole semplicemente sapere: quanto ho comprato, cosa è in arrivo e qual è il prezzo.
Il resto era supposizione. Non ne avevano bisogno. C'è una differenza importante.
Un cliente può chiedere una funzionalità. Non significa necessariamente che quella funzionalità risolva il suo problema.
"La concorrenza ce l'ha"
Questo è il secondo classico.
L'azienda analizza la concorrenza. Vede un nuovo modulo.
E comincia il refrain: "Dobbiamo averlo anche noi."
Solo che la concorrenza potrebbe avere un modello di business completamente diverso, un altro target di clienti, processi di vendita diversi e una strategia di prodotto differente.
La funzionalità che ha senso in un sistema può essere completamente inutile in un altro.
Questo è particolarmente importante nei progetti su misura. Non esiste un insieme universale di funzionalità che renda ogni applicazione buona.
Un sistema per un produttore industriale non dovrebbe essere progettato come una piattaforma per una società di formazione.
Un CRM per venditori non dovrebbe funzionare come un pannello B2B per clienti abituali.
Un e-commerce che vende prodotti premium potrebbe necessitare di un'esperienza d'acquisto completamente diversa rispetto a un negozio il cui principale argomento è il prezzo.
Il software dovrebbe derivare dal modello di business, non dal catalogo di funzionalità della concorrenza.
L'IA qui cambia davvero tanto
Ed è proprio per questo che oggi questo tema è particolarmente interessante.
Solo pochi anni fa l'idea di una nuova funzionalità doveva attraversare molte fasi prima che l'utente potesse vederla.
Analisi.
Progettazione.
UX.
Sviluppo.
Test.
Rilascio.
Oggi parte di queste fasi può essere notevolmente accelerata dall'IA. Possiamo creare prototipi più velocemente. Preparare interfacce più in fretta. Scrivere codice più rapidamente. Generare test più velocemente. Analizzare i dati più rapidamente.
Ed è per questo che la sola velocità di sviluppo smette di essere un vantaggio sufficiente.
Se chiunque può costruire qualcosa più in fretta, il vantaggio passa a chi sceglie meglio cosa costruire.
Atlassian, nel suo studio sul futuro del product management, sottolinea questo paradosso: l'IA aumenta la velocità di lavoro, ma l'aumento di velocità non garantisce automaticamente prodotti migliori. Allo stesso tempo l'89% dei manager intervistati da Atlassian dichiarava un incremento della velocità grazie all'IA, mentre solo il 6% si sentiva sicuro nel misurare un ROI specifico dell'IA a livello organizzativo.
Questo mostra bene la differenza tra fare più in fretta e ottenere risultati migliori.
Prima il problema. Poi, più tardi, la funzionalità
Un buon processo di prodotto dovrebbe iniziare con la domanda: Quale problema stiamo cercando di risolvere?
Non: "Quale funzionalità dobbiamo aggiungere?"
Sembra una differenza sottile. In pratica cambia tutto.
Se il cliente dice: "Abbiamo bisogno di un'app mobile",
vale la pena chiedere: Perché?
Forse davvero serve un'app. Ma potrebbe darsi che il problema sia la mancanza di accesso comodo al pannello da telefono. Forse basta un'interfaccia responsive ben progettata. Forse una PWA. Forse un modulo mobile per un singolo processo. E magari l'app è necessaria, ma per ragioni completamente diverse da quelle inizialmente indicate dal cliente.
Lo stesso vale per le funzionalità.
"Abbiamo bisogno di report automatici." — Perché?
"Perché i commerciali perdono tempo." — Su cosa?
"A trascrivere dati dal sistema."
E all'improvviso si scopre che il problema non è l'assenza del report. Il problema è la mancanza di integrazione.
Una buona analisi può far risparmiare mesi di sviluppo.
A volte la migliore funzionalità è non avere funzionalità
Suona paradossale, ma proprio questo dovrebbe essere il ruolo di un partner tecnologico esperto.
Non solo eseguire. Anche mettere in discussione le assunzioni, quando c'è motivo per farlo.
Se un cliente arriva con una lista di venti funzionalità, lo software house non dovrebbe trattarla automaticamente come una specifica tecnica scolpita nella pietra.
Dovrebbe chiedere: Quali di queste funzionalità risolvono un problema reale? Quali sono critiche? Quali aumentano le vendite? Quali riducono il lavoro? Quali migliorano il servizio clienti? Quali sono richieste dal punto di vista legale o operativo? Quali sono solo "un bel complemento"?
E soprattutto: come capiremo che una funzionalità è stata un successo?
Senza quest'ultima domanda è facile creare un prodotto che cresce continuamente, ma senza che sia chiaro se stia davvero diventando migliore.
Il prodotto deve saper dire "no"
In un buon product development è importante tanto l'elenco delle cose da costruire quanto l'elenco delle cose che non costruiamo. Ci vuole coraggio.
Perché è facile dire: "Sì, lo faremo."
È più difficile dire: "Sulla base di ciò che sappiamo, non vediamo ancora un motivo per pagare per questo."
È ancora più difficile dirlo al cliente che è appena arrivato con un'idea pronta.
Ma è proprio lì che inizia la collaborazione di vero partner.
Lo software house non dovrebbe essere solo un team che trasforma ordini in codice. Dovrebbe aiutare il cliente a prendere decisioni tecnologiche.
A volte significa progettare la funzionalità.
A volte semplificarla.
A volte sostituirla con un'altra soluzione.
E a volte rinunciare completamente all'idea.
Come riconoscere una funzionalità che probabilmente non ti serve?
Non esiste un test magico, ma alcune domande possono raffreddare rapidamente l'entusiasmo.
Chi esattamente la userà?
Se la risposta è "tutti", vale la pena approfondire.
Quale problema risolviamo?
Se la risposta è "sarà più comodo", probabilmente serve un'analisi più approfondita.
Quanto frequentemente l'utente la userà?
Una volta l'anno? Una volta al mese? Ogni giorno?
Esiste un modo più semplice per risolvere lo stesso problema?
Questa domanda è particolarmente importante.
Come misureremo l'effetto?
Più vendite? Meno lavoro? Processo più breve? Meno errori? Più retention?
Cosa succede se non costruiamo questa funzionalità?
Se la risposta è "praticamente nulla", forse abbiamo trovato una funzionalità che non vale la pena costruire.
Non ogni richiesta utente dovrebbe finire nel backlog
Questo è anche un cambiamento mentale importante.
Il feedback degli utenti è prezioso. Ma il feedback non è una specifica di prodotto automatica.
L'utente parla del suo problema attraverso la lente della sua esperienza personale.
Potrebbe dire: "Ho bisogno del pulsante X."
Il ruolo del team di prodotto non è creare ciecamente il pulsante X.
Il ruolo del team è comprendere: perché l'utente ne ha bisogno.
Solo allora si può decidere se la soluzione migliore sia davvero il pulsante X.
Potrebbe essere l'automazione.
Potrebbe essere un'integrazione.
Potrebbe essere un cambiamento di processo.
Potrebbe essere una migliore interfaccia.
Potrebbe essere l'educazione dell'utente.
E a volte davvero una nuova funzionalità.
Questa è la differenza tra feature delivery e product development.
I dati possono anche dire: "eliminiamola"
Lo sviluppo del prodotto non dovrebbe limitarsi all'aggiunta.
Bisogna anche guardare a ciò che già esiste.
Quali funzionalità vengono usate?
Quali vengono ignorate?
Dove gli utenti abbandonano?
Quali processi richiedono più tempo?
Quali elementi generano più segnalazioni al supporto?
Quali funzionalità aumentano la conversione?
E quali complicano solo l'interfaccia?
A volte il miglior progetto di sviluppo non è aggiungere un altro modulo. È rimuovere tre cose inutili. Questo può migliorare la UX più di un altro mese di sviluppo.
L'IA può aiutare anche qui
Curiosamente, l'IA non deve servire solo a creare funzionalità.
Può aiutare anche ad analizzare se le funzionalità hanno senso.
Può analizzare il feedback degli utenti.
Raggruppare le segnalazioni.
Individuare problemi ricorrenti.
Analizzare i dati del supporto.
Riassumere le conversazioni con i clienti.
Aiutare il team a confrontare ipotesi.
Preparare varianti di soluzione.
Supportare l'analisi del comportamento degli utenti.
Quindi, paradossalmente, il miglior uso dell'IA nel product development può talvolta non essere che ci permetta di costruire più velocemente un'altra funzionalità.
Ma che ci aiuti più rapidamente a scoprire che non dovremmo costruirla.
Web24: prima chiediamo "perché?"
Ogni progetto software inizia da un bisogno.
A volte il cliente sa esattamente cosa vuole.
A volte ha già una specifica pronta.
A volte viene solo con un problema: "Questo processo ci prende tre ore al giorno."
E questo è un ottimo punto di partenza.
Perché allora possiamo chiederci non come codificare la soluzione proposta, ma come risolvere al meglio il problema.
Questo è ciò che distingue lo sviluppo di software su misura dall'assemblare un prodotto da funzionalità preconfezionate.
In Web24 non si tratta di dotare ogni applicazione del maggior numero possibile di funzioni.
Si tratta di dotarla delle funzionalità che sono davvero necessarie per quel business.
Per questo due sistemi simili possono apparire e funzionare in modo completamente diverso.
Perché i processi sono diversi.
Gli utenti sono diversi.
Gli obiettivi sono diversi.
Il modo di vendere è diverso.
Il modo di assistere il cliente è diverso.
E diverso è il problema che il software deve risolvere.
Il backlog più costoso è quello che nessuno mette in discussione
Nel mondo dell'IA possiamo entrare in una fase molto interessante dello sviluppo del software.
La tecnologia risponderà sempre meglio alla domanda: "Come lo costruiamo?"
E l'essere umano dovrà rispondere sempre meglio alla domanda: "Dovremmo proprio costruirlo?"
Questa potrebbe essere una delle più importanti trasformazioni nella creazione del software.
Perché se il costo e il tempo per realizzare una nuova funzionalità diminuiscono, la tentazione di aggiungerle cresce.
E con essa cresce l'importanza del Product Discovery, della UX, dell'analisi dati, delle conversazioni con gli utenti e di un approccio strategico allo sviluppo del prodotto. Gartner segnala che lo sviluppo rapido di prodotti spinto dall'IA può portare, tra le altre cose, a problemi di allineamento strategico e all'aumento del debito tecnico se il ritmo tecnologico non è accompagnato da una governance di prodotto adeguata.
Perciò il futuro non apparterrà solo alle aziende che sanno costruire più in fretta. Apparterrà anche a quelle che sanno scegliere meglio cosa costruire.
Perché a volte la migliore decisione tecnologica non è: "Facciamo ancora una funzionalità."
Ma: "Verifichiamo prima se ne abbiamo davvero bisogno."
