L’intelligenza artificiale generativa sta ridisegnando non solo i prodotti che le aziende costruiscono, ma anche il modo in cui si decide cosa costruire. Oggi, con la diffusione capillare degli strumenti generativi e la proliferazione di applicazioni basate su modelli linguistici, la disciplina si è aperta a un pubblico molto più ampio. Sempre più Project Manager, anche quelli senza una formazione tecnica specifica, si trovano a dover padroneggiare pratiche che fino a ieri erano appannaggio degli ingegneri.
Requisiti e funzionalità? Meglio degli esempi
Quando un product manager propone di costruire “un assistente AI per supportare il team commerciale nelle trattative”, questa formulazione lascia aperta una quantità enorme di interrogativi. Deve suggerire contro-offerte in tempo reale? Deve analizzare lo storico del cliente? Deve generare bozze di contratto? Senza rispondere a queste domande, il team può facilmente partire nella direzione sbagliata.
La pratica che si sta affermando è specificare il prodotto attraverso esempi concreti: una serie di conversazioni o situazioni ideali (tra 20 e 50) che illustrano esattamente cosa ci si aspetta dal sistema.
Lo stesso vale per i sistemi di analisi visiva. “Monitorare l’affollamento nelle aree comuni dell’ufficio” è ambiguo. Si considera affollato con 5 persone o con 20? Vale anche per i corridoi? Funziona in condizioni di scarsa illuminazione? Ma se il PM raccoglie un piccolo dataset di immagini annotate con i risultati desiderati, la specifica diventa inequivocabile. Un ingegnere può valutarne la fattibilità tecnica e lavorare verso un obiettivo definito. C’è però una dimensione di questa pratica che viene spesso sottovalutata: la raccolta di esempi concreti è anche una strategia di comunicazione e co-definizione con il cliente.
Chi si occupa di sviluppare prodotti o progetti su commessa conosce bene il problema: il cliente raramente sa descrivere con precisione ciò che vuole. Non per negligenza, ma perché è genuinamente difficile articolare un bisogno astratto senza avere davanti qualcosa di concreto su cui ragionare. Chiedere al cliente di portare esempi cambia radicalmente la natura della conversazione. Invece di discutere di funzionalità in astratto, si ragiona su situazioni concrete: “In questo caso, cosa vorresti che il sistema facesse?”, “Questo risultato ti soddisferebbe, o manca qualcosa?”. È un dialogo molto più produttivo, e spesso rivela sorprese: priorità che non emergono mai nei briefing formali, casistiche che il cliente dava per scontate e non aveva pensato di menzionare, aspettative implicite che avrebbero generato conflitti in fase di collaudo.
La bacchetta magica
Un ulteriore esercizio, meno efficace ma più veloce rispetto alla generazione di esempi, che può essere utilizzato per aumentare la fluidità della comunicazione con i clienti (o tra PM e team di sviluppo) è il metodo della “bacchetta magica”: si chiede al cliente di immaginare di avere a disposizione un sistema perfetto, costruito esattamente come lo vorrebbe, senza vincoli tecnologici o di budget. La domanda è semplice e diretta: “Se potessi creare qualsiasi sistema tu voglia con una bacchetta magica, cosa gli daresti in input e cosa vorresti ricevere in output?”
È una domanda apparentemente ingenua, ma produce effetti sorprendenti. Togliendo dal tavolo i vincoli tecnici si libera la descrizione del bisogno reale. La differenza tra una richiesta tradizionale e una formulata con il metodo della bacchetta magica è spesso sorprendente.
- Caso 1 — Supporto commerciale
Prima: “Vorremmo un’app che aiuti i nostri commerciali durante le trattative, magari con qualche suggerimento intelligente.”
Con la bacchetta magica: “Input: la trascrizione di una chiamata con il cliente e il suo storico acquisti. Output: un riepilogo dei segnali di interesse emersi, tre possibili obiezioni che potrebbe sollevare e le controargomentazioni consigliate.” - Caso 2 — Gestione documentale
Prima: “Ci serve qualcosa per gestire meglio i nostri contratti, oggi perdiamo troppo tempo a cercare le informazioni.”
Con la bacchetta magica: “Input: il testo di un contratto in PDF. Output: una scheda strutturata con le date chiave, le clausole di penale, il valore economico e un semaforo che segnala eventuali condizioni fuori standard rispetto ai nostri template.” - Caso 3 — Supporto clienti
Prima: “Vogliamo automatizzare una parte del customer care, soprattutto per le richieste più ripetitive.”
Con la bacchetta magica: “Input: l’e-mail di un cliente. Output: la categoria del problema, il livello di urgenza, la risposta bozza pronta da inviare e l’indicazione se è necessario l’intervento umano.”
La bacchetta magica impone un pensiero diretto e operativo. Costringe chi risponde a ragionare in termini di flusso reale: cosa entra nel sistema, cosa deve uscire, in quale forma. Non c’è spazio per l’ambiguità perché non c’è spazio per l’astrazione.
Conclusioni
In genere è consigliabile usare entrambi i metodi. Prima la bacchetta magica per una ricognizione preliminare delle specifiche e poi gli esempi per definire la lista di funzionalità. Lo svantaggio è che impone al cliente o al PM un esercizio mentale nuovo a cui spesso non è abituato e che richiede uno sforzo. Tuttavia, questo cambio di prospettiva utilizzando gli esempi come specifiche e il metodo della bacchetta magica ha degli effettivi positivi immediati e pratici: spariscono le discussioni su funzionalità ipotetiche e si entra subito nel merito di ciò che il sistema deve concretamente fare. Le aspettative diventano verificabili e il successo del progetto smette di essere una questione di interpretazione.
