Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Quasi ogni giorno, su Slack, mi arriva la domanda prodotto.
Non una domanda astratta. Non una grande riflessione sulla visione a cinque anni. Una vera domanda di campo.
Si può fare questo?
Cosa succede se il cliente configura il prodotto così?
Qual è il limite?
Questa regola si applica anche in questo caso?
Perché il prodotto blocca qui?
Si può promettere questo al cliente?
Alcune di queste domande sono strategiche. Richiedono di capire il mercato, il cliente, il posizionamento, la direzione che si vuole prendere. In questi casi, serve un product manager. Serve un giudizio. A volte bisogna dire no, a volte arbitrare, a volte assumersi un orientamento.
Ma molte domande non sono di quest'ordine.
Riguardano il comportamento reale del prodotto.
Una regola. Un limite. Un'eccezione. Un vincolo. Un caso d'uso. Una configurazione. Un'interazione tra due funzionalità.
E lì, in teoria, la risposta dovrebbe essere semplice.
Il problema è che non lo è sempre.
Il costo nascosto della domanda prodotto
Quando la domanda è precisa, aprire la documentazione non basta sempre.
Prima perché la documentazione non esiste sempre.
Poi perché esiste a volte, ma non si sa se è ancora aggiornata.
Infine perché la vera domanda riguarda spesso un caso limite che nessuno ha documentato esplicitamente.
Allora si fa ciò che fanno tutti i PM, CSM, supporti o sviluppatori quando hanno un dubbio: si testa.
Si apre un ambiente di test.
Si prepara un set di dati.
Si riproduce lo scenario.
Si verifica se il prodotto blocca, accetta, calcola, mostra, nasconde, scatta, invia, rifiuta.
E è passata una mezz'ora.
A volte un'ora.
A volte di più.
Questo tempo non appare da nessuna parte. Non è in Jira. Non è nella roadmap. Non è nelle stime. È semplicemente assorbito dal funzionamento normale dell'organizzazione.
C'è anche un altro costo, ancora più invisibile: il cambio di contesto.
La domanda arriva raramente al momento giusto. Arriva perché un cliente aspetta. Perché un commerciale è in appuntamento. Perché un CSM sta preparando un punto. Perché il supporto deve rispondere entro fine giornata.
Quindi si interrompe ciò che si stava facendo. Si entra in un argomento. Si testa. Si risponde. Poi si cerca di tornare a ciò che si faceva prima.
Non è solo una perdita di tempo. È una perdita di continuità intellettuale.
Ed è precisamente il tipo di compito che l'IA dovrebbe assorbire.
Il problema non è la domanda. È la fonte.
Si potrebbe rispondere: basta avere una documentazione migliore.
In teoria, sì.
In pratica, no.
Una documentazione prodotto è quasi sempre in ritardo sul prodotto reale. Non è un problema di disciplina individuale. Non è solo perché qualcuno ha dimenticato di aggiornare una pagina.
È più strutturale.
Una spec descrive un'intenzione. Un PRD descrive un obiettivo, delle regole attese, degli scenari. Un mockup descrive un'interfaccia desiderata. Ma tra questa intenzione e la produzione, succede sempre qualcosa.
Si fanno dei compromessi.
Si aggiustano dei dettagli.
Compaiono dei casi limite.
Vengono prese delle decisioni durante lo sviluppo.
Dei vincoli tecnici obbligano a modificare leggermente il comportamento.
Degli scambi avvengono in una pull request o una merge request.
Degli arbitraggi non risalgono sempre nella documentazione iniziale.
Non è necessariamente grave. È anche abbastanza normale. Un prodotto vivo non si costruisce come un documento fisso.
Ma questo crea una conseguenza semplice: la spec non è la verità del prodotto.
È un'approssimazione utile in un dato momento.
La verità è ciò che gira.
E ciò che gira è il codice.
Il codice come fonte di verità prodotto
La produzione è la realtà.
Non la spec.
Non il PRD.
Non la pagina Notion.
Non il ricordo del PM.
Non la discussione Slack di tre settimane fa.
Per sapere come si comporta davvero il prodotto, bisogna guardare ciò che è consegnato. E ciò che è consegnato è portato dal codice sorgente.
Detto così, può sembrare brutale. Si potrebbe credere che equivalga a dire: «buttate tutta la documentazione».
Non è l'idea.
La buona distinzione non è tra «codice» e «documentazione».
La buona distinzione è tra ciò che spiega e ciò che descrive.
Si conserva ciò che spiega.
Si rigenera ciò che descrive.
I contesti devono essere conservati. Contengono le discussioni, le fonti, i ragionamenti, le idee che hanno permesso di arrivare a una scelta. Sono blocchi riutilizzabili.
Le decisioni devono essere conservate. Quando un'azienda sceglie una direzione, bisogna conservare il perché. Perché questa scelta? Quali alternative sono state scartate? Perché questa decisione sostituisce una decisione precedente?
È il ruolo dei Product Decision Record, i PDR. Ho già scritto su questo argomento: un PDR non descrive una feature, traccia una decisione prodotto strutturante.
Certi vincoli devono anche restare accessibili: vincoli contrattuali, regolamentari, documenti esterni, impegni specifici. Non tutto può essere dedotto dal codice.
Ma la documentazione che descrive il comportamento prodotto dovrebbe, per quanto possibile, essere rigenerata dal codice.
Perché il codice è la verità del comportamento implementato.
Cosa rende possibile l'IA
Fino a qui, questa idea aveva un limite evidente.
Il codice è codice.
Non è sempre leggibile per il supporto. Non è sempre leggibile per le sales. Non è sempre leggibile per un C-level. Non è nemmeno sempre facilmente leggibile per un PM, soprattutto se non ha una cultura tecnica.
Per molto tempo, era quindi necessario uno strato intermedio. Delle spec. Dei documenti di supporto. Delle pagine prodotto. Dei changelog. Delle tabelle. Degli schemi.
L'IA cambia questa equazione.
Può diventare l'interfaccia tra una domanda di business e il codice sorgente.
Un supporto può chiedere: «Cosa succede se il cliente annulla questo elemento dopo la validazione?»
Un CSM può chiedere: «In quali condizioni si blocca questo workflow?»
Un commerciale può chiedere: «Si può promettere questa configurazione a questo prospect?»
Un PM può chiedere: «Dove è implementata questa regola e quali casi non sono coperti?»
E l'IA può andare a cercare nel codice, nella cronologia Git, nelle merge request, nei feature flag, nei contesti di business, poi produrre una risposta comprensibile.
Non una risposta magica.
Una risposta ancorata.
Una buona risposta prodotto deve mostrare le sue prove
Il punto chiave è qui.
Se l'IA risponde senza prove, diventa una nuova documentazione approssimativa. Più veloce, più elegante, ma non necessariamente più affidabile.
Bisogna quindi obbligare l'IA ad ancorare la sua risposta.
Quando afferma che una regola esiste, deve dire perché.
Non solo: «il prodotto funziona così».
Ma: «il prodotto funziona così perché tale funzione applica questa regola, perché tale eccezione blocca questo caso, perché tale merge request ha introdotto questo comportamento, perché tale test copre questo scenario».
Le prove non devono necessariamente essere al centro della risposta. Per il supporto o le sales, possono essere in fondo al documento. Non tutti hanno bisogno di leggere i dettagli tecnici.
Ma devono esistere.
La loro presenza cambia il comportamento dell'IA. Non può più rispondere solo per verosimiglianza. Deve collegare le sue affermazioni a elementi fattuali.
È la stessa logica dell'analisi di testo. Se chiedo a un'IA di analizzare un corpus, preferisco che mi dia, per ogni conclusione, la frase o il paragrafo su cui si basa. Questo limita fortemente le allucinazioni.
Per una domanda prodotto, è 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 prodotto.
Una fonte di business.
Senza questo, non si fa che spostare il problema. Si sostituisce la memoria imperfetta del PM con la memoria probabilistica di un modello.
Non è sufficiente.
Bisogna anche dire ciò che non si sa
Una buona risposta prodotto non deve solo rispondere.
Deve anche dire dove si blocca.
È una direttiva essenziale.
L'IA deve poter scrivere:
«Non ho trovato un test che copra questo caso.»
«Il codice mostra due comportamenti possibili a seconda dello stato del feature flag.»
«Non posso determinare 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 osservato nel codice.»
È scomodo, ma è prezioso.
Un umano serio fa la stessa cosa. Quando non sa, lo dice. Quando ha un dubbio, lo segnala. Quando deve testare, testa.
L'obiettivo non è far credere che l'IA sappia tutto.
L'obiettivo è ridurre il costo di ricerca, aumentando allo stesso tempo la tracciabilità.
Non tutti i pubblici hanno bisogno della stessa lettura
Una domanda prodotto può interessare più ruoli.
Il supporto vuole spesso una risposta utilizzabile di fronte al cliente.
Il CSM vuole capire l'uso e gli impatti.
Le sales vogliono sapere cosa possono promettere, e quale valore mettere in evidenza.
Il PM vuole verificare la regola, il limite, l'eccezione.
La direzione può voler capire la posta strategica.
Si potrebbe quindi immaginare una risposta diversa per ogni pubblico.
Ma non è necessariamente indispensabile.
Una stessa risposta può essere strutturata in più angoli. Una parte breve per rispondere alla domanda. Una parte supporto. Una parte uso. Una parte valore. Una parte limiti. Una parte prove.
Ognuno legge ciò di cui ha bisogno.
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 dell'azienda. Alcune organizzazioni preferiscono limitare l'informazione. Altre guadagnano in maturità condividendola.
Non è una questione puramente tecnica.
È una questione di cultura.
I blocchi necessari
Tecnicamente, non basta collegare un LLM a un repository Git e sperare che tutto funzioni.
Diversi strumenti sono complementari.
Il RAG permette di ritrovare i frammenti giusti. È spesso molto efficace per far emergere i pezzi pertinenti in una grande massa documentale o in un codice voluminoso.
Ma il RAG non basta sempre. Ritrova. Non viaggia necessariamente.
Un grafo semantico può aiutare a esplorare gli elementi vicini: concetti collegati, moduli contigui, regole connesse, eventi che scatenano altri eventi.
Il percorso del filesystem resta anche indispensabile. Quando si è identificata una zona, a volte bisogna leggere la directory, aprire i file vicini, capire la struttura locale. È meno elegante di una ricerca vettoriale, ma spesso molto efficace.
Git apporta un'altra dimensione: il tempo.
Il codice attuale dice ciò che esiste. La cronologia dice come ci si è arrivati. I commit, le pull request o le merge request possono rivelare l'intenzione, le discussioni, i compromessi, le correzioni.
I feature flag aggiungono ancora una sfumatura. Il codice può contenere più comportamenti possibili. Il comportamento reale dipende allora dallo stato del flag.
Se l'IA non ha accesso a questo stato, deve rispondere in modo condizionale: se il flag è attivato, allora il comportamento è questo; altrimenti, è diverso.
Se ha accesso all'ambiente, può andare più lontano: per questo cliente preciso, in questa configurazione precisa, il comportamento attivo è quello.
Questo passaggio è importante. La domanda prodotto non riguarda sempre il codice astratto. A volte riguarda il prodotto così come lo vive un cliente preciso.
La condizione: un codice che parla business
C'è tuttavia una condizione di base.
Il codice deve rappresentare il business.
Se il codice è un groviglio, se i concetti di business sono nascosti dietro nomi tecnici, se le regole sono disperse, se le eccezioni non portano il vocabolario del dominio, allora l'IA avrà difficoltà.
Ma non è un limite nuovo.
Uno sviluppatore umano avrà anche difficoltà.
Un PM tecnico avrà anche difficoltà.
Un team che vuole far evolvere il prodotto avrà anche difficoltà.
Un codice che non rappresenta il business non è un buon codice. Impone in permanenza una traduzione tra il bisogno di business e la meccanica del software. Ogni evoluzione richiede di ricostruire mentalmente questo collegamento. Ogni debug diventa più costoso. Ogni regola diventa più difficile da ritrovare.
È esattamente per questo che approcci come il DDD esistono da tempo. L'idea non è nata con l'IA.
L'IA rende semplicemente questa esigenza più visibile.
Se si vuole interrogare il codice come fonte di verità prodotto, il codice deve parlare il linguaggio del prodotto.
Le entità devono portare i nomi del business.
Le azioni devono essere leggibili.
Gli eventi devono raccontare ciò che è successo.
Le eccezioni devono esprimere delle regole, non solo degli errori tecnici.
Le politiche devono rendere visibili le reazioni a cascata.
I moduli devono avere una struttura prevedibile.
Un'eccezione come ElementoAnnullatoNonModificabile non è solo un messaggio di errore. È una regola di business scritta in codice.
È questo tipo di codice che diventa interrogabile.
Non perché l'IA sia magica.
Perché il business è già presente nella materia che legge.
Dalla risposta puntuale alla documentazione rigenerata
Rispondere a una domanda Slack è il primo caso d'uso.
Ma non è l'unico.
Se si può rispondere a una domanda prodotto dal codice, si può anche rigenerare una parte della documentazione prodotto.
Si può produrre una FAQ di supporto.
Aggiornare un articolo vivo su una funzionalità.
Generare un changelog.
Ricostituire una spec a partire dallo stato attuale del prodotto.
Produrre una documentazione commerciale più affidabile su ciò che può essere promesso o meno.
La logica è sempre la stessa: non mantenere a mano degli artefatti che descrivono il comportamento reale se questo comportamento può essere ricostruito dalla fonte di verità.
Le spec non scompaiono del tutto.
Cambiano di 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
Bisogna ovviamente mantenere un po' di pragmatismo.
Non tutte le aziende possono applicare questo al millimetro.
Alcune hanno una storia documentale pesante.
Alcune hanno un legacy difficile.
Alcune hanno vincoli regolamentari forti.
Alcune non hanno ancora una cultura tecnica sufficiente.
Alcune hanno decisioni prodotto mal tracciate.
Alcune non possono esporre le stesse informazioni a tutti i ruoli.
Non si tratta quindi di dire: domani mattina, eliminate tutta la vostra documentazione.
Sarebbe assurdo.
Si tratta di cambiare il centro di gravità.
Smettere di considerare la documentazione descrittiva come la fonte di verità.
Smettere di chiedere al PM di verificare manualmente, ancora e ancora, ciò che il prodotto fa già.
Smettere di mantenere a mano degli artefatti che divergono meccanicamente.
E iniziare a costruire un sistema dove il codice, le decisioni, i contesti e le fonti dialogano.
Più di un metodo prodotto
In fondo, la domanda prodotto è solo un caso particolare.
Rivela una trasformazione più ampia.
Per molto tempo, il sistema informativo dell'azienda era composto da basi di dati, basi documentali, wiki, ticket, tabelle, cartelle, documenti.
Si cercava.
Si leggeva.
Si ricopiava.
Si aggiornava.
Si dimenticava.
Con l'IA, si può iniziare a fare altro.
Si può dialogare con il sistema informativo.
Si può porre una domanda.
Si può chiedere una prova.
Si possono esplorare le idee vicine.
Si può risalire la cronologia.
Si può rilevare una contraddizione.
Si può rigenerare un artefatto.
La domanda prodotto è un buon punto di ingresso perché è concreta. Costa tempo ogni giorno. Interrompe il lavoro. Rivela la divergenza tra documentazione e produzione.
Ma dietro di essa, il soggetto è più profondo.
Non si tratta solo di aiutare il supporto a rispondere più velocemente.
Si tratta di rendere l'azienda interrogabile dalle sue vere fonti.
E nel caso del prodotto, la vera fonte del comportamento è il codice.
Per saperne di più
Code centric Product Decision Record: tracciare le decisioni di prodotto che strutturano l'azienda Wiki IA: perché ho costruito una base di conoscenza mantenuta da un'IA