Il deliverable non è più il capitale

Per molto tempo ho considerato il deliverable come il risultato principale del lavoro.

Un documento è finito. Una presentazione è inviata. Una spec è condivisa. Un articolo è pubblicato. Una risposta a un bando è tornata al cliente.

Qualcosa è stato prodotto.

Quindi il lavoro sembra concluso.

Ma più uso l'IA con dei contesti, più questa evidenza mi sembra incompleta.

Il deliverable è visibile.

È necessario.

Ma non è sempre il vero capitale.

Il documento finale consuma un pensiero

Un deliverable nasce per un uso.

Risponde a un pubblico, a un momento, a un vincolo di forma. Una spec parla agli sviluppatori. Un pitch parla a un CPO. Una documentazione di supporto parla a un team che deve rispondere in fretta. Un articolo parla a lettori che non conoscono ancora il tema. Una risposta a un bando parla a un cliente con le sue caselle, la sua numerazione, il suo vocabolario.

Ogni deliverable seleziona, semplifica, riformula e ordina il materiale per un bisogno preciso.

È normale. È anzi il suo ruolo.

Ma questa messa in forma ha un costo: una parte del pensiero che ha permesso di produrre il deliverable scompare dietro di esso.

Vedi il documento finale.

Non vedi più sempre le fonti, le esitazioni, le alternative scartate, gli esempi lasciati fuori, le decisioni intermedie, le contraddizioni, le sfumature che hai tenuto in testa ma non nella versione inviata.

Il deliverable porta il risultato.

Non porta necessariamente il ragionamento.

Il problema comincia al secondo deliverable

Questo resta discreto finché c'è un solo output da produrre.

Lavori un materiale. Scrivi un documento. Lo invii. Fine.

Ma nella vita reale la stessa sostanza deve spesso servire più volte.

A partire dallo stesso materiale, forse bisognerà produrre:

• una spec funzionale;
• delle user story;
• un pitch per la direzione;
• una nota per il commerciale;
• una documentazione di supporto;
• un piano di test;
• una risposta a un bando;
• un articolo;
• una sintesi breve per una riunione.

In un workflow classico ogni nuovo formato dà l'impressione di ricominciare.

Riapri il documento precedente. Copi e incolli. Riformuli. Togli ciò che non parla al nuovo pubblico. Aggiungi ciò che manca. A volte dimentichi una sfumatura. Due versioni cominciano a divergere.

Non è soltanto faticoso.

È pericoloso.

Il supporto può ricevere una spiegazione diversa da quella data al commerciale. La spec può contenere un'ipotesi che non c'è più nel pitch. La risposta al bando può riutilizzare una vecchia formulazione che non è più vera. L'articolo può appiattire una distinzione importante perché il materiale disponibile è già troppo orientato.

Il problema non è produrre più documenti.

Il problema è prendere un deliverable come fonte principale del deliverable successivo.

Un output non è una fonte di verità

Un documento finale è un output.

Può essere molto buono.

Ma è stato scritto per un contesto d'uso preciso.

Contiene quindi scelte che non appartengono sempre alla conoscenza in sé: il tono, il livello di dettaglio, gli esempi, l'ordine, il grado di prudenza, il modo di nominare le cose, ciò che rivela e ciò che no, ciò che presuppone già noto.

Se parti da questo documento per produrre tutto il resto, erediti le sue scelte.

A volte è utile.

Spesso ti chiude.

Una frase scritta per rassicurare un cliente non è necessariamente una buona base per una documentazione interna. Una slide di direzione non è una buona base per una user story. Una risposta breve in una tabella non è una buona base per capire la decisione di prodotto.

Il deliverable è orientato.

La conoscenza di lavoro dovrebbe restare più neutra.

Il mondo delle idee

Per questo trovo utile aggiungere uno strato intermedio tra le fonti e i deliverable.

Lo chiamo il mondo delle idee.

Non è un nome molto tecnico.

Ma dice bene ciò che deve fare.

Il mondo delle idee raccoglie ciò che è stato compreso, prima di trasformarlo per un pubblico particolare.

Ci puoi trovare:

• note atomiche;
• note tematiche;
• definizioni;
• ipotesi;
• contraddizioni;
• decisioni;
• esempi;
• limiti;
• relazioni tra idee;
• punti da verificare.

Questo materiale non parla ancora a un cliente, a uno sviluppatore o a un lettore.

Parla al lavoro stesso.

Il suo ruolo non è essere elegante.

Il suo ruolo è essere riutilizzabile.

Una nota non deve diventare un gancio

Questo punto è più sottile di quanto sembri.

Quando scrivi un articolo, hai voglia di trasformare un'idea direttamente in frase.

Quando prepari una presentazione, hai voglia di trasformare un'idea direttamente in bullet di slide.

Quando scrivi una spec, hai voglia di trasformare un'idea direttamente in requisito.

Il problema è che la nota diventa così, già, un frammento del deliverable.

Perde la sua neutralità.

Una buona nota deve tenere la conoscenza a un livello in cui potrà essere riespressa in altro modo.

Può contenere una distinzione, una prova, un'ipotesi, un arbitraggio, una sfumatura. Ma non deve restare prigioniera dell'articolo, della slide o della spec del momento.

Il build è ciò che produce.

La nota serve a conservare ciò che potrà produrre più tardi.

La differenza sembra piccola.

Cambia tutto quando torni tre settimane dopo.

L'IA rende questa separazione molto più utile

Prima dell'IA, mantenere questo strato intermedio poteva sembrare pesante.

Si potevano già prendere note pulite, conservare fonti, creare sintesi. Ma produrre poi più deliverable restava un lavoro manuale considerevole.

Con l'IA questa separazione conviene molto di più.

Se il materiale è bene organizzato, l'IA può aiutare a ricomporlo.

Può produrre una versione lunga, una versione breve, una versione commerciale, una versione tecnica, una versione prudente, una versione didattica.

Può adattare la stessa conoscenza a più pubblici.

Ma per farlo correttamente deve partire dallo strato giusto.

Non solo dall'ultimo documento inviato.

Non solo da una chat.

Non solo da un PDF finale.

Deve poter tornare alle fonti, alle note, alle decisioni, ai limiti, agli elementi ancora incerti.

Allora il lavoro cambia natura.

Non produci più soltanto un documento.

Costruisci un materiale che può produrre.

Il capitale è ciò che resta dopo l'output

Una buona domanda da porsi dopo ogni deliverable è semplice:

cosa resta?

Non solo: dov'è il file?

Ma:

• quali idee sono state stabilizzate?
• quali fonti sostengono queste idee?
• quali decisioni sono state prese?
• quali alternative sono state scartate?
• quali formulazioni sono state validate?
• quali punti restano fragili?
• quali elementi potranno servire a un altro pubblico?

Se la risposta è «niente, tranne il documento finale», allora una gran parte del lavoro è stata consumata.

Il deliverable è stato prodotto.

Ma il capitale non è stato costruito.

Al contrario, se il lavoro lascia dietro di sé note, fonti collegate, decisioni, domande aperte, formulazioni testate, livelli di fiducia, allora il prossimo deliverable non ripartirà da zero.

Il risultato visibile è il documento.

Il capitale è la capacità di rifare, adattare, spiegare, difendere e prolungare.

Questo cambia il modo di lavorare

L'idea può sembrare astratta.

Diventa molto concreta nell'arco di una settimana di lavoro.

Un'intervista con un utente non serve solo a scrivere un resoconto. Può alimentare una nota di prodotto, una decisione, un'ipotesi, un esempio per una futura presentazione.

Un bando non serve solo a rispondere a un potenziale cliente. Può arricchire una memoria di domande ricorrenti, risposte validate, prove e limiti di divulgazione.

Un articolo non serve solo a pubblicare un pensiero. Può stabilizzare idee che più tardi alimenteranno un libro, una formazione, un metodo, una discussione di prodotto.

Una spec non serve solo a sviluppare una funzionalità. Può conservare la traccia degli arbitraggi che permetteranno di capire, sei mesi dopo, perché il prodotto funziona così.

In tutti questi casi il deliverable non è inutile.

Resta indispensabile.

Ma diventa un output tra gli altri.

Non esaurisce più il valore del lavoro.

Il documento giusto al posto giusto

Non credo che si debbano disprezzare i deliverable.

Al contrario.

Un buon deliverable è spesso ciò che rende il lavoro trasmissibile. Obbliga a chiarire, a scegliere, a tagliare, a formulare. Mette il pensiero a contatto con un pubblico reale.

Ma bisogna smettere di chiedergli di portare tutto.

Il documento finale non deve contenere tutte le fonti.

Non deve conservare tutte le alternative.

Non deve esporre tutte le incertezze.

Non deve diventare la memoria completa del tema.

Deve fare il suo lavoro di deliverable.

E la memoria del lavoro deve esistere altrove.

È esattamente ciò che permette un contesto.

Il contesto conserva il materiale.

Il build produce gli output.

L'umano tiene il giudizio.

L'IA aiuta a ricomporre.

Lo spostamento di valore

Lo spostamento mi sembra importante.

Prima capitalizzavamo soprattutto i documenti.

Conservavamo le spec, le presentazioni, le note di riunione, i resoconti, i bandi a cui avevamo risposto.

Da qui in avanti bisognerà capitalizzare di più il materiale che permette di produrli.

Non è la stessa cosa.

Capitalizzare un deliverable significa conservare una forma passata.

Capitalizzare un contesto significa conservare una capacità futura.

Il deliverable dice: ecco cosa abbiamo inviato.

Il contesto dice: ecco cosa abbiamo capito, deciso, verificato, scartato, e cosa possiamo ancora produrre a partire da lì.

Per questo il deliverable non è più il capitale principale.

Resta la parte visibile.

Ma il valore che dura si sposta verso ciò che permette di produrre più volte senza perdere la sostanza.

Il documento parte.

Il pensiero organizzato resta.

Per saperne di più

Il PM come architetto del Contesto Fonte di sessione: ciò che i tuoi documenti non catturano Sotto il cofano del mio motore di contesto: come un'IA ricorda una missione Il secondo cervello è un vicolo cieco per il product management Nel software, il vantaggio non sarà più la tecnologia. Sarà la comprensione del contesto.