Quasi ogni giorno, su Slack, mi arriva la domanda di prodotto.

Non una domanda astratta. Non una grande riflessione sulla visione a cinque anni. Una domanda concreta, sul campo.

Si può fare questa cosa?

Cosa succede se il cliente configura il prodotto in questo modo?

Qual è il limite?

Questa regola vale anche in questo caso?

Perché il prodotto blocca qui?

Possiamo promettere questo al cliente?

Alcune di queste domande sono strategiche. Richiedono di capire il mercato, il cliente, il posizionamento, la direzione che vogliamo prendere. Lì serve un product manager. Serve un giudizio. A volte bisogna dire no, a volte decidere tra due opzioni, a volte prendersi la responsabilità di un orientamento.

Ma molte domande non sono di questo tipo.

Riguardano il comportamento reale del prodotto.

Una regola. Un limite. Un'eccezione. Un vincolo. Un caso d'uso. Una configurazione. L'interazione tra due funzionalità.

E lì, in teoria, la risposta dovrebbe essere semplice.

Il problema è che non sempre lo è.

Il costo nascosto della domanda di prodotto

Quando la domanda è puntuale, aprire la documentazione non sempre basta.

Intanto perché la documentazione non sempre esiste.

Poi perché a volte esiste, ma non si sa se sia ancora aggiornata.

Infine perché la vera domanda riguarda spesso un caso limite che nessuno ha documentato in modo esplicito.

Allora si fa quello che fanno tutti — PM, CSM, supporto o sviluppatori — quando hanno un dubbio: si prova.

Si apre un ambiente di test.

Si prepara un set di dati.

Si riproduce lo scenario.

Si controlla se il prodotto blocca, accetta, calcola, mostra, nasconde, scatena, invia, rifiuta.

Ed è passata mezz'ora.

A volte un'ora.

A volte di più.

Questo tempo non compare da nessuna parte. Non è su Jira. Non è nella roadmap. Non è nelle stime. Viene semplicemente assorbito dal normale funzionamento dell'organizzazione.

C'è poi un altro costo, ancora più invisibile: il cambio di contesto.

La domanda arriva di rado al momento giusto. Arriva perché un cliente aspetta. Perché un commerciale è in riunione con un cliente. Perché un CSM sta preparando un incontro. Perché il supporto deve rispondere entro sera.

Così si interrompe quello che si stava facendo. Si entra nell'argomento. Si prova. Si risponde. Poi si cerca di tornare a dove si era rimasti.

Non è solo tempo perso. È continuità intellettuale persa.

Ed è esattamente il tipo di lavoro che l'IA dovrebbe assorbire.

Il problema non è la domanda. È la fonte.

Si potrebbe obiettare: basta avere una documentazione migliore.

In teoria, sì.

In pratica, no.

La documentazione di prodotto è quasi sempre in ritardo sul prodotto reale. Non è un problema di disciplina personale. Non dipende solo dal fatto che qualcuno si è dimenticato di aggiornare una pagina.

È qualcosa di più strutturale.

Una spec descrive un intento. Un PRD descrive un obiettivo, le regole attese, gli scenari. Un mockup descrive l'interfaccia desiderata. Ma tra quell'intento e la produzione succede sempre qualcosa.

Si fanno compromessi.

Si aggiustano dettagli.

Emergono casi limite.

Si prendono decisioni durante lo sviluppo.

Vincoli tecnici costringono a modificare leggermente il comportamento.

Si discute dentro una pull request o una merge request.

E quelle scelte non sempre risalgono fino alla documentazione iniziale.

Non è necessariamente grave. È anzi piuttosto normale: un prodotto vivo non si costruisce come un documento statico.

Ma ne deriva una conseguenza semplice: la spec non è la verità del prodotto.

È un'approssimazione utile in un dato momento.

La verità è quello che gira.

E quello che gira è il codice.

Il codice come fonte di verità del prodotto

La produzione è la realtà.

Non la spec.

Non il PRD.

Non la pagina Notion.

Non i ricordi del PM.

Non la conversazione su Slack di tre settimane fa.

Per sapere come si comporta davvero il prodotto bisogna guardare quello che è stato rilasciato. E quello che è stato rilasciato sta nel codice sorgente.

Detta così, la cosa può sembrare brutale. Si potrebbe intendere come un «buttate via tutta la documentazione».

Non è questo il punto.

La distinzione giusta non è tra «codice» e «documentazione».

La distinzione giusta è tra ciò che spiega e ciò che descrive.

Quello che spiega si conserva.

Quello che descrive si rigenera.

I contesti vanno conservati. Contengono le discussioni, le fonti, i ragionamenti, le idee che hanno portato a una scelta. Sono blocchi riutilizzabili.

Le decisioni vanno conservate. Quando un'azienda imbocca una direzione, il perché va tenuto. Perché questa scelta? Quali alternative sono state scartate? Perché questa decisione ne sostituisce una precedente?

È il ruolo dei Product Decision Record, i PDR. Ne ho già scritto: un PDR non descrive una funzionalità, tiene traccia di una decisione di prodotto strutturante.

Anche alcuni vincoli devono restare accessibili: vincoli contrattuali, normativi, documenti esterni, impegni specifici. Non tutto si deduce dal codice.

Ma la documentazione che descrive il comportamento del prodotto dovrebbe, per quanto possibile, essere rigenerata a partire dal codice.

Perché il codice è la verità del comportamento implementato.

Quello che l'IA rende possibile

Finora questa idea aveva un limite evidente.

Il codice è codice.

Non sempre è leggibile per il supporto. Non sempre lo è per chi lavora nelle vendite. Non sempre lo è per un C-level. Non sempre lo è nemmeno per un PM, soprattutto se non ha una cultura tecnica.

A lungo è servito quindi uno strato intermedio. Spec. Documenti per il supporto. Pagine di prodotto. Changelog. Tabelle. Schemi.

L'IA cambia l'equazione.

Può diventare l'interfaccia tra una domanda del business e il codice sorgente.

Il supporto può chiedere: «Cosa succede se il cliente annulla questo elemento dopo la validazione?»

Un CSM può chiedere: «In quali condizioni questo workflow si blocca?»

Un commerciale può chiedere: «Possiamo promettere questa configurazione a questo prospect?»

Un PM può chiedere: «Dove è implementata questa regola e quali casi restano scoperti?»

E l'IA può andare a cercare nel codice, nella storia Git, nelle merge request, nei feature flag, nei contesti del business, e poi produrre una risposta comprensibile.

Non una risposta magica.

Una risposta ancorata.

Una buona risposta di prodotto deve mostrare le prove

Il punto chiave è questo.

Se l'IA risponde senza prove, diventa una nuova documentazione approssimativa. Più rapida, più elegante, ma non per forza più affidabile.

Bisogna quindi obbligarla ad ancorare la risposta.

Quando afferma che una regola esiste, deve dire perché.

Non solo: «il prodotto funziona così».

Ma: «il prodotto funziona così perché questa funzione applica questa regola, perché questa eccezione blocca questo caso, perché questa merge request ha introdotto questo comportamento, perché questo test copre questo scenario».

Le prove non devono per forza stare al centro della risposta. Per il supporto o per le vendite possono benissimo stare in fondo al documento: non tutti hanno bisogno di leggere i dettagli tecnici.

Ma devono esserci.

La loro presenza cambia il comportamento dell'IA. Non può più rispondere solo per verosimiglianza. Deve agganciare le sue affermazioni a elementi fattuali.

È la stessa logica dell'analisi di un testo. Se chiedo a un'IA di analizzare un corpus, preferisco che per ogni conclusione mi dia la frase o il paragrafo su cui si appoggia. Riduce moltissimo le allucinazioni.

Per una domanda di prodotto vale lo stesso.

La prova può essere un file.

Una funzione.

Un'eccezione.

Un test.

Un commit.

Una merge request.

Una pull request.

Un feature flag.

Una decisione di prodotto.

Una fonte del business.

Senza questo, il problema viene solo spostato. Si sostituisce la memoria imperfetta del PM con la memoria probabilistica di un modello.

Non basta.

Bisogna anche dire quello che non si sa

Una buona risposta di prodotto non deve solo rispondere.

Deve anche dire dove si ferma.

È una direttiva essenziale.

L'IA deve poter scrivere:

«Non ho trovato nessun test che copra questo caso.»

«Il codice mostra due comportamenti possibili a seconda dello stato del feature flag.»

«Non posso stabilire il comportamento esatto per questo cliente senza accedere alla sua configurazione.»

«Il PDR indica una regola, ma il codice sembra implementare qualcos'altro.»

«La documentazione di supporto attuale contraddice il comportamento che si osserva nel codice.»

È scomodo, ma è prezioso.

Una persona seria fa lo stesso. Quando non sa, lo dice. Quando ha un dubbio, lo segnala. Quando deve provare, prova.

L'obiettivo non è far credere che l'IA sappia tutto.

L'obiettivo è ridurre il costo della ricerca aumentando la tracciabilità.

Non tutti hanno bisogno della stessa lettura

Una domanda di prodotto può interessare più funzioni aziendali.

Il supporto vuole di solito una risposta spendibile davanti al cliente.

Il CSM vuole capire l'uso e gli impatti.

Chi vende vuole sapere cosa può promettere, e quale valore mettere in primo piano.

Il PM vuole verificare la regola, il limite, l'eccezione.

La direzione può volerne capire la posta in gioco strategica.

Si potrebbe quindi immaginare una risposta diversa per ogni destinatario.

Ma non è per forza necessario.

Una stessa risposta può essere organizzata secondo più angolature. Una parte breve che risponde alla domanda. Una parte supporto. Una parte uso. Una parte valore. Una parte limiti. Una parte prove.

Ognuno legge quello che gli serve.

E a volte è proprio utile che un commerciale veda un limite del prodotto, o che un CSM capisca l'origine tecnica di un comportamento. Dipende dalla cultura aziendale. Certe organizzazioni preferiscono contenere l'informazione. Altre crescono in maturità condividendola.

Non è una questione puramente tecnica.

È una questione di cultura.

I blocchi necessari

Sul piano tecnico non basta collegare un LLM a un repository Git e sperare che funzioni tutto.

Servono strumenti diversi, che si completano a vicenda.

Il RAG permette di ritrovare i frammenti giusti. Spesso è molto efficace per far emergere i pezzi pertinenti dentro una grande massa documentale o un codice voluminoso.

Ma il RAG non sempre basta. Ritrova. Non necessariamente si sposta.

Un grafo semantico può aiutare a esplorare gli elementi vicini: concetti collegati, moduli vicini, regole connesse, eventi che ne scatenano altri.

Anche percorrere il filesystem resta indispensabile. Una volta individuata una zona, a volte bisogna leggere la directory, aprire i file vicini, capire la struttura locale. È meno elegante di una ricerca vettoriale, ma spesso funziona benissimo.

Git offre un'altra dimensione: il tempo.

Il codice attuale dice cosa esiste. La sua storia dice come ci si è arrivati. I commit, le pull request o le merge request possono rivelare l'intento, le discussioni, i compromessi, le correzioni.

I feature flag aggiungono un'ulteriore sfumatura. Il codice può contenere più comportamenti possibili, e quello reale dipende dallo stato del flag.

Se l'IA non ha accesso a quello stato, deve rispondere in modo condizionale: se il flag è attivo il comportamento è questo, altrimenti è un altro.

Se invece ha accesso all'ambiente, può spingersi oltre: per questo cliente, in questa configurazione, il comportamento attivo è quello.

Il passaggio è importante. La domanda di prodotto non riguarda sempre il codice in astratto. A volte riguarda il prodotto così come lo vive un cliente preciso.

La condizione: un codice che parla la lingua del business

C'è però una condizione di partenza.

Il codice deve rappresentare il business.

Se il codice è un groviglio, se i concetti del dominio sono nascosti dietro nomi tecnici, se le regole sono sparpagliate, se le eccezioni non portano il vocabolario del dominio, l'IA farà fatica.

Ma non è un limite nuovo.

Farà fatica anche uno sviluppatore in carne e ossa.

Farà fatica anche un PM tecnico.

Farà fatica anche un team che vuole far evolvere il prodotto.

Un codice che non rappresenta il business non è un buon codice. Obbliga a tradurre in continuazione tra il bisogno del business e la meccanica del software. Ogni evoluzione impone di ricostruire mentalmente quel legame. Ogni debug costa di più. Ogni regola diventa più difficile da ritrovare.

È esattamente per questo che approcci come il DDD esistono da molto tempo. L'idea non è nata con l'IA.

L'IA rende semplicemente l'esigenza più visibile.

Se vogliamo interrogare il codice come fonte di verità del prodotto, il codice deve parlare la lingua del prodotto.

Le entità devono portare i nomi del dominio.

Le azioni devono essere leggibili.

Gli eventi devono raccontare quello che è successo.

Le eccezioni devono esprimere regole, non solo errori tecnici.

Le policy devono rendere visibili le reazioni a catena.

I moduli devono avere una struttura prevedibile.

Un'eccezione come ElementAnnuléNonModifiable non è solo un messaggio di errore. È una regola del business scritta in codice.

È questo il tipo di codice che diventa interrogabile.

Non perché l'IA sia magica.

Perché il business è già dentro la materia che legge.

Dalla risposta puntuale alla documentazione rigenerata

Rispondere a una domanda su Slack è il primo caso d'uso.

Ma non è l'unico.

Se dal codice si può rispondere a una domanda di prodotto, dal codice si può anche rigenerare una parte della documentazione di prodotto.

Si può produrre una FAQ per il supporto.

Aggiornare un articolo vivo su una funzionalità.

Generare un changelog.

Ricostruire una spec a partire dallo stato attuale del prodotto.

Produrre una documentazione commerciale più affidabile su quello che si può promettere e quello che non si può.

La logica è sempre la stessa: non mantenere a mano artefatti che descrivono il comportamento reale, se quel comportamento si può ricostruire dalla fonte di verità.

Le spec non spariscono del tutto.

Cambiano status.

Prima della produzione servono al dialogo.

Permettono di discutere, esplorare, inquadrare, decidere.

Dopo la produzione non devono più pretendere di essere la verità duratura del prodotto.

Diventano rigenerabili.

Non è una regola religiosa

Un po' di pragmatismo, ovviamente, va tenuto.

Non tutte le aziende possono applicare tutto questo al millimetro.

Alcune si portano dietro una documentazione storica pesante.

Alcune hanno un legacy difficile.

Alcune hanno vincoli normativi forti.

Alcune non hanno ancora una cultura tecnica sufficiente.

Alcune hanno decisioni di prodotto tracciate male.

Alcune non possono esporre le stesse informazioni a tutte le funzioni aziendali.

Non si tratta quindi di dire: da domani mattina cancellate tutta la documentazione.

Sarebbe assurdo.

Si tratta di spostare il centro di gravità.

Smettere di considerare la documentazione descrittiva come la fonte di verità.

Smettere di chiedere al PM di verificare a mano, ancora e ancora, quello che il prodotto già fa.

Smettere di mantenere a mano artefatti destinati a divergere.

E iniziare a costruire un sistema in cui il codice, le decisioni, i contesti e le fonti si parlano.

Più di un metodo di prodotto

In fondo, la domanda di prodotto è solo un caso particolare.

Rivela una trasformazione più ampia.

Per molto tempo il sistema informativo dell'azienda è stato fatto di database, archivi documentali, wiki, ticket, tabelle, cartelle, documenti.

Si cercava.

Si leggeva.

Si ricopiava.

Si aggiornava.

Ci si dimenticava.

Con l'IA si può cominciare a fare altro.

Si può dialogare con il sistema informativo.

Si può fare una domanda.

Si può chiedere una prova.

Si possono esplorare le idee vicine.

Si può risalire la storia.

Si può individuare una contraddizione.

Si può rigenerare un artefatto.

La domanda di prodotto è un buon punto di ingresso perché è concreta. Costa tempo ogni giorno. Interrompe il lavoro. Mette in evidenza lo scarto tra documentazione e produzione.

Ma dietro c'è qualcosa di più profondo.

Non si tratta solo di aiutare il supporto a rispondere più in fretta.

Si tratta di rendere l'azienda interrogabile a partire dalle sue vere fonti.

E nel caso del prodotto, la vera fonte del comportamento è il codice.