Silo di dati tra Engineering e Prodotto
PM e ingegneri usano strumenti, linguaggi e tempi diversi. Ecco come si forma il silo – e cosa lo risolve davvero.
By Ellis Keane · 2026-03-16
A un certo punto, «l'allineamento prodotto-engineering» è diventato un titolo di lavoro invece di qualcosa che accadeva semplicemente quando persone competenti lavoravano insieme. Le aziende ora assumono persone dedicate il cui unico scopo è assicurarsi che due gruppi di persone intelligenti – che si trovano nello stesso spazio di lavoro Slack, partecipano agli stessi standup e lavorano teoricamente verso gli stessi obiettivi – possano davvero capire cosa sta facendo l'altro gruppo. I silo di dati tra engineering e prodotto che rendono necessario tutto ciò non sono un problema di persone. Sono un problema di strumenti.
PM e ingegneri comunicano abbastanza. Il problema è che lavorano in sistemi completamente diversi, e i silo che si formano tra quei sistemi sono strutturali – incorporati nell'architettura di come i team moderni scelgono i loro strumenti. Nessun livello di «allineamoci più spesso» risolve un problema in cui gli strumenti stessi non hanno consapevolezza gli uni degli altri.
Le due realtà
Qui mi baso sulla nostra esperienza diretta nella costruzione di Sugarbug, perché lo viviamo ogni giorno e penso che i dettagli specifici siano più utili della versione astratta.
Il lato PM (che nel nostro caso sono principalmente io) vive in Notion. Le spec vengono scritte lì, le priorità tracciate, le conversazioni con i clienti registrate, le richieste di funzionalità catalogate in liste che crescono settimana dopo settimana. Notion è dove vive il «perché» – perché stiamo costruendo qualcosa, cosa ha detto davvero il cliente, quale contesto strategico c'è dietro una determinata decisione. È disordinato, è vasto, ed è dove avviene il pensiero più importante prima che venga scritta una singola riga di codice.
Nel frattempo, i nostri ingegneri vivono in Linear e GitHub. Linear contiene i task, i cicli di sprint, le catene di dipendenze e gli issues bloccanti. GitHub ha il codice, le pull request, i thread di revisione in cui le persone discutono costruttivamente (si spera) sui dettagli di implementazione. Lì vivono il «come» e il «quando» – come viene costruita qualcosa, quando verrà consegnata, cosa c'è nel mezzo.
Entrambe le realtà sono accurate, entrambe essenziali, e sono completamente disconnesse tra loro. Il divario tra di esse è dove i requisiti diventano obsoleti e il lavoro da rifare inizia ad accumularsi.
Come si formano davvero i silo di dati tra engineering e prodotto
È allettante pensare che questa sia una scelta deliberata – che qualcuno abbia deciso di tenere le informazioni separate. In pratica, il silo si forma attraverso un comportamento del tutto ragionevole che nessuno intendeva come dannoso.
Un PM scrive una spec in Notion, la collega su Slack al canale engineering e considera il passaggio di consegne fatto. Un ingegnere legge la spec, crea tre issues Linear da essa e inizia a costruire. Finora tutto funziona.
Ma poi la spec cambia – una conversazione con un cliente sposta la priorità, o il contesto aziendale si evolve. Il PM aggiorna il documento Notion e lascia una nota su Slack riguardo al cambiamento. L'ingegnere, immerso in una sessione di codifica, non vede il messaggio Slack per ore. A quel punto ha già costruito due delle tre funzionalità secondo la vecchia spec, e il terzo issue in Linear fa ancora riferimento a requisiti che non esistono più.
Nessuno è stato negligente qui. Nessuno ha «mancato di comunicare». Le informazioni vivevano in un sistema e il lavoro è avvenuto in un altro, e il tessuto connettivo tra di essi era un messaggio Slack che è stato sepolto sotto altri thread prima che la persona giusta lo vedesse.
Questo accade ripetutamente – a ogni spec, ogni sprint, ogni trimestre – e la deriva si accumula. Il divario tra ciò che il prodotto pensa stia accadendo e ciò che l'engineering sta effettivamente costruendo si allarga a ogni passaggio di consegne che si basa su qualcuno che nota un messaggio al momento giusto.
Perché «comunicare meglio» non risolve il problema
Ho partecipato a retrospettivi in cui l'azione era «comunicare i cambiamenti in modo più proattivo», e (affettuosamente) questo è l'equivalente organizzativo di dire a qualcuno di essere semplicemente più organizzato. Suona azionabile, fa sembrare produttiva la pagina Confluence, e non cambia assolutamente nulla del sistema che ha causato il problema. Abbiamo eseguito quello stesso punto di azione del retrospettivo tre volte – ho verificato.
Il motivo per cui una migliore comunicazione non risolve i silo di dati tra engineering e prodotto è che la comunicazione sta già avvenendo – i dati esistono, le decisioni vengono prese e registrate. Vengono semplicemente registrate in strumenti che non hanno consapevolezza gli uni degli altri.
Notion non sa che una spec è stata scomposta in tre issues Linear. Linear non sa che i requisiti dietro un issue sono cambiati in Notion due ore fa. GitHub non ha idea che il PR in revisione implementi una funzionalità la cui priorità è appena stata declassata nel Notion board del PM. Ogni strumento funziona esattamente come è stato progettato – sono stati semplicemente progettati per non funzionare insieme.
«C'è una certa commedia oscura nel passare il lunedì mattina a confermare che gli strumenti per cui paghi non si sono silenziosamente discostati dalla realtà nel corso del fine settimana.» – Ellis Keane
Quindi quello che succede è che i PM rispecchiano manualmente le modifiche da Notion a Linear quando le spec cambiano, gli ingegneri contattano i PM su Slack per chiedere «è ancora questo il piano?», e i lead trascorrono i loro lunedì mattina a incrociare i board per verificare le derive. Abbiamo osservato come bruciamo diverse ore a settimana su quella che è essenzialmente una sincronizzazione manuale dei dati tra strumenti che, in teoria, dovrebbero già conoscersi a vicenda.
Come appare davvero una soluzione sistemica
L'istinto quando si vede un divario tra due strumenti è costruire un ponte – un'automazione Zapier, un webhook, uno script di sincronizzazione. Per flussi di lavoro semplici e prevedibili (quando un issue Linear passa a «Fatto», aggiornare uno stato in Notion), funziona bene.
Ma i silo di dati tra engineering e prodotto implicano contesto, non solo stato. Il PM non ha semplicemente cambiato un campo di stato; ha riscritto un paragrafo nella spec che cambia il significato di «fatto» per due dei tre issues Linear. I semplici webhook di stato mancano i cambiamenti a livello di requisiti a meno che non si aggiunga la logica di diff e il mapping semantico, cosa che la maggior parte dei team non riesce mai a costruire.
Ciò di cui hai davvero bisogno è qualcosa che comprenda le relazioni tra i dati attraverso gli strumenti – non solo «questa pagina Notion è collegata a questo issue Linear», ma «questa sezione della spec descrive i requisiti per questo issue, e quella sezione è appena cambiata». L'obiettivo è mappare automaticamente le modifiche alle spec agli issues impattati, piuttosto che affidarsi a qualcuno che noti e propaghi il cambiamento.
Questa è la differenza tra uno strato di sincronizzazione e un grafo della conoscenza. Uno strato di sincronizzazione copia i dati tra gli strumenti. Un grafo della conoscenza traccia come i dati si relazionano, rileva quando quelle relazioni cambiano, e mostra i cambiamenti alle persone che devono saperlo.
Stiamo costruendo Sugarbug per funzionare in questo modo – collegando gli strumenti che PM e ingegneri usano già (Notion, Linear, GitHub, Slack, Figma) in un grafo della conoscenza che mantiene le relazioni tra spec, task, codice e conversazioni. Siamo ancora agli inizi (onestamente, c'è ancora molto che non abbiamo capito su come rendere il rilevamento semantico delle differenze affidabile su larga scala), ma il grafo centrale funziona e ha già catturato situazioni di deriva delle spec che si sarebbero trasformate in lavoro da rifare.
I silo di dati tra engineering e prodotto si formano perché gli strumenti sono strutturalmente disconnessi, non perché le persone comunicano male. La soluzione è connettere i dati a livello di relazioni, non aggiungere altri canali di comunicazione.
Cosa puoi fare questa settimana
Non farò finta che l'unica risposta sia «usa Sugarbug». Ci sono cose che puoi fare adesso, con qualsiasi strumento tu stia già usando, per ridurre gli effetti peggiori del silo di dati prodotto-engineering.
Rendi i riferimenti incrociati espliciti, bidirezionali e con un responsabile assegnato. Ogni spec Notion dovrebbe avere una sezione «Issues Linear» in fondo che collega agli issues che ha generato, e ogni issue Linear dovrebbe ricollegarsi alla sua spec sorgente. Assegna una persona per spec responsabile dei riferimenti incrociati – non l'intero team, una persona, con il suo nome. Abbiamo provato la versione «tutti sono responsabili» e (come prevedibile) non lo era nessuno. I link si sfaseranno comunque nel tempo, ma avere un responsabile nominato significa che c'è qualcuno da contattare quando viene rilevata la deriva.
Stabilisci un rituale di «cambio spec» con un trigger, non un promemoria. Quando una spec cambia in modo sostanziale (non errori di battitura – veri cambiamenti di requisiti), il PM aggiorna gli issues Linear collegati prima di chiudere il tab di Notion. Non dopo, non «quando avrò tempo» – prima di chiudere il tab. Il commento su ogni issue interessato dovrebbe essere di una riga: cosa è cambiato, link alla sezione aggiornata, e se i criteri di accettazione dell'issue sono ancora validi. Abbiamo scoperto che collegare l'aggiornamento a un'azione fisica (chiudere il tab) funziona meglio che affidarsi alla memoria di qualcuno, perché la memoria è esattamente il modo in cui si è formato il silo in primo luogo.
Esegui una verifica di corrispondenza delle priorità di 15 minuti il venerdì. Una persona (rotazione settimanale) visualizza le prime 5 priorità del PM in Notion e le prime 5 dello sprint engineering in Linear, affiancate. La domanda non è «sono identiche?» – non lo saranno, ed è normale. La domanda è «ce ne sono alcune che si contraddicono attivamente?» Se la priorità numero 1 del PM non compare da nessuna parte nello sprint, questa è la conversazione da fare lunedì, non un aggiornamento di stato.
Questi sono processi manuali, e hanno una durata limitata. Con cinque ingegneri e due PM, sono noiosi ma funzionano. Con quindici ingegneri, tre PM e un team di design che aggiunge Figma al mix, le relazioni tra strumenti si moltiplicano più velocemente di quanto chiunque possa tracciare manualmente. Ma ti insegneranno dove si trovano davvero le tue peggiori lacune di allineamento prodotto-engineering – e quel valore diagnostico vale lo sforzo anche se alla fine automatizzi tutto.
Che la soluzione a lungo termine sia Sugarbug o qualcos'altro (ovviamente pensiamo di stare costruendo la cosa giusta, ma sono di parte), il problema di collaborazione tra product management e ingegneria si risolve solo quando gli strumenti stessi sono connessi a livello semantico, e le persone possono concentrarsi sul prendere decisioni piuttosto che trasportare contesto tra applicazioni.
Se i tuoi riferimenti incrociati manuali reggono, sfruttali finché durano. Se continui ad avere gli stessi punti di azione dei retrospettivi sulla comunicazione, il problema non sono le tue persone. È la tua architettura dei dati.
Connetti Notion, Linear, GitHub e Slack in un unico grafo della conoscenza – così le modifiche alle spec arrivano automaticamente agli ingegneri giusti.
Q: Quanto tempo ci vuole per configurare Sugarbug per un team prodotto-engineering? A: La connessione iniziale richiede pochi minuti per strumento – si autenticano Linear, GitHub, Notion, Slack e Figma tramite OAuth, e Sugarbug inizia immediatamente a costruire il grafo della conoscenza. Il grafo diventa significativamente utile nel giro di uno o due giorni mentre acquisisce i dati esistenti e inizia a mappare le relazioni tra spec, issues e conversazioni. Stiamo ancora perfezionando il flusso di onboarding, ma l'obiettivo è che non sia necessario configurare nulla oltre a connettere i propri account.
Q: Sugarbug sostituisce Linear, Notion o uno qualsiasi dei nostri strumenti esistenti? A: No. Sugarbug affianca i tuoi strumenti esistenti e li connette – non ne sostituisce nessuno. I tuoi PM continuano a scrivere le spec in Notion, i tuoi ingegneri continuano a lavorare in Linear e GitHub, e Sugarbug mantiene le relazioni tra di essi affinché il contesto non vada perso in transito. Consideralo come il tessuto connettivo tra gli strumenti che già utilizzi.
Q: Sugarbug può rilevare quando una spec Notion cambia e avvisare gli ingegneri giusti? A: Questa è una parte centrale di ciò che stiamo costruendo. Quando una spec cambia in Notion, Sugarbug identifica quali issues Linear sono collegati ad essa e mostra il cambiamento agli ingegneri che lavorano su quegli issues. Stiamo ancora iterando sulla parte di rilevamento semantico (capire quali cambiamenti sono sostanziali rispetto a cosmetici), ma il collegamento tra strumenti e il rilevamento di base dei cambiamenti funzionano.
Q: Qual è la differenza tra uno strumento di sincronizzazione e un grafo della conoscenza per questo problema? A: Uno strumento di sincronizzazione copia i cambiamenti di stato tra applicazioni – quando un issue Linear passa a «Fatto», aggiorna una casella di controllo in Notion. Un grafo della conoscenza traccia come i dati si relazionano: questa spec descrive i requisiti per questi tre issues, e i criteri di accettazione sono cambiati, il che riguarda i due issues che non sono ancora stati consegnati. La differenza conta di più quando i cambiamenti sono semantici, non solo a livello di stato.
Q: L'allineamento prodotto-engineering è un problema di comunicazione o un problema di dati? A: Dalla nostra esperienza, è quasi sempre un problema di dati mal diagnosticato come problema di comunicazione. I team comunicano – lo fanno semplicemente attraverso strumenti che non hanno consapevolezza gli uni degli altri. Correggere il flusso di dati tra quegli strumenti tende a risolvere i problemi di allineamento che nessun numero di retrospettivi o riunioni di sincronizzazione riusciva a risolvere.