Datensilos zwischen Engineering und Produkt
PMs und Ingenieure nutzen unterschiedliche Tools, Sprache und Timelines. So entsteht das Silo – und was es wirklich löst.
By Ellis Keane · 2026-03-16
Irgendwann wurde „Produkt-Engineering-Alignment" ein Stellentitel, statt etwas, das einfach passiert, wenn kompetente Menschen zusammenarbeiten. Unternehmen stellen heute dedizierte Mitarbeiter ein, deren einziger Zweck es ist, sicherzustellen, dass zwei Gruppen intelligenter Menschen – die im selben Slack-Workspace sitzen, die gleichen Standup-Meetings besuchen und theoretisch auf die gleichen Ziele hinarbeiten – tatsächlich verstehen können, was die jeweils andere Gruppe tut. Die Datensilos zwischen Engineering und Produkt, die das notwendig machen, sind kein Menschenproblem. Sie sind ein Tooling-Problem.
PMs und Ingenieure kommunizieren ausreichend. Das Problem ist, dass sie in völlig unterschiedlichen Systemen arbeiten, und die Silos, die sich zwischen diesen Systemen bilden, sind strukturell – in die Architektur eingebaut, wie moderne Teams ihre Tools auswählen. Kein Maß an „Lass uns öfter abstimmen" behebt ein Problem, bei dem die Tools selbst kein Bewusstsein füreinander haben.
Die zwei Realitäten
Ich beziehe mich hier auf unsere eigene Erfahrung beim Aufbau von Sugarbug, weil wir das täglich erleben und ich denke, die konkreten Details sind nützlicher als die abstrakte Version.
Die PM-Seite (das bin in unserem Fall hauptsächlich ich) lebt in Notion. Spezifikationen werden dort geschrieben, Prioritäten verfolgt, Kundengespräche protokolliert, Feature-Anfragen in wachsenden Listen katalogisiert. Notion ist der Ort, wo das „Warum" lebt – warum wir etwas bauen, was der Kunde tatsächlich gesagt hat, welcher strategische Kontext hinter einer bestimmten Entscheidung steckt. Es ist unordentlich, es ist weitläufig, und hier findet das wichtigste Denken statt, bevor eine einzige Zeile Code geschrieben wird.
Unsere Ingenieure hingegen leben in Linear und GitHub. Linear hält die Aufgaben, die Sprint-Zyklen, die Abhängigkeitsketten und blockierenden Issues. GitHub hat den Code, die Pull Requests, die Review-Threads, in denen Menschen konstruktiv (hoffentlich) über Implementierungsdetails diskutieren. Hier lebt das „Wie" und das „Wann" – wie etwas gebaut wird, wann es geliefert wird, was im Weg steht.
Beide Realitäten sind korrekt, beide unverzichtbar, und sie sind vollständig voneinander getrennt. Die Lücke zwischen ihnen ist der Ort, an dem Anforderungen veralten und Nacharbeit sich ansammelt.
Wie Datensilos zwischen Engineering und Produkt tatsächlich entstehen
Es ist verlockend zu denken, dies sei eine bewusste Entscheidung – dass jemand beschlossen hat, die Informationen getrennt zu halten. In der Praxis entsteht das Silo durch völlig vernünftiges Verhalten, das niemand als schädlich beabsichtigt hat.
Ein PM schreibt eine Spezifikation in Notion, verlinkt sie in Slack im Engineering-Channel und betrachtet die Übergabe als erledigt. Ein Ingenieur liest die Spezifikation, erstellt drei Linear-Issues daraus und beginnt zu bauen. Bisher funktioniert alles.
Dann ändert sich die Spezifikation – ein Kundengespräch verschiebt die Priorität, oder der Geschäftskontext entwickelt sich. Der PM aktualisiert das Notion-Dokument und hinterlässt eine Notiz in Slack über die Änderung. Der Ingenieur, tief in einer Coding-Session, sieht die Slack-Nachricht stundenlang nicht. Bis dahin hat er zwei der drei Features nach der alten Spezifikation gebaut, und das dritte Issue in Linear referenziert noch immer Anforderungen, die nicht mehr existieren.
Niemand war hier unachtsam. Niemand hat „die Kommunikation versäumt." Die Information lebte in einem System, und die Arbeit fand in einem anderen statt, und das Bindegewebe zwischen ihnen war eine Slack-Nachricht, die unter anderen Threads begraben war, bevor die richtige Person sie sah.
Dies passiert wiederholt – bei jeder Spezifikation, jedem Sprint, jedem Quartal – und die Abweichung kumuliert. Die Lücke zwischen dem, was Produkt denkt, was passiert, und dem, was Engineering tatsächlich baut, wird mit jeder Übergabe größer, die darauf angewiesen ist, dass ein Mensch eine Nachricht zum richtigen Zeitpunkt bemerkt.
Warum „bessere Kommunikation" das nicht behebt
Ich habe in Retrospektiven gesessen, wo der Action Item war „Änderungen proaktiver kommunizieren", und (liebevoll gesagt) das ist das organisatorische Äquivalent dazu, jemandem zu sagen, einfach organisierter zu sein. Es klingt handlungsfähig, es lässt die Confluence-Seite produktiv aussehen, und es ändert absolut nichts an dem System, das das Problem verursacht hat. Wir haben diesen gleichen Retrospektiven-Action-Item dreimal ausgeführt – ich habe nachgeprüft.
Der Grund, warum bessere Kommunikation Datensilos zwischen Engineering und Produkt nicht löst, ist, dass Kommunikation bereits stattfindet – die Daten existieren, die Entscheidungen werden getroffen und aufgezeichnet. Sie werden nur in Tools aufgezeichnet, die kein Bewusstsein füreinander haben.
Notion weiß nicht, dass eine Spezifikation in drei Linear-Issues zerlegt wurde. Linear weiß nicht, dass sich die Anforderungen hinter einem Issue vor zwei Stunden in Notion geändert haben. GitHub hat keine Ahnung, dass der PR, der gerade reviewed wird, ein Feature implementiert, dessen Priorität soeben im Notion-Board des PMs herabgestuft wurde. Jedes Tool funktioniert genau so, wie es konzipiert wurde – sie wurden nur nicht dafür konzipiert, zusammenzuarbeiten.
„Es gibt eine gewisse dunkle Komödie darin, seinen Montagmorgen damit zu verbringen zu bestätigen, dass die Tools, für die man bezahlt, über das Wochenende nicht still von der Realität abgewichen sind." – Ellis Keane
Was also passiert, ist, dass PMs Änderungen aus Notion manuell in Linear spiegeln, wenn sich Spezifikationen ändern, Ingenieure PMs auf Slack anschreiben, um zu fragen „ist das noch der Plan?", und Leads ihre Montagmorgen damit verbringen, Boards zu quervergleichen, um auf Abweichungen zu prüfen. Wir haben beobachtet, wie wir mehrere Stunden pro Woche mit dem verbrennen, was im Grunde manuelle Datensynchronisation zwischen Tools ist, die theoretisch bereits voneinander wissen sollten.
Wie eine System-Lösung tatsächlich aussieht
Der Instinkt, wenn man eine Lücke zwischen zwei Tools sieht, ist, eine Brücke zu bauen – eine Zapier-Automatisierung, einen Webhook, ein Sync-Skript. Für einfache, vorhersehbare Flows (wenn ein Linear-Issue auf „Erledigt" geht, Notion-Status aktualisieren) funktioniert das gut.
Aber Datensilos zwischen Engineering und Produkt beinhalten Kontext, nicht nur Status. Der PM hat nicht einfach ein Statusfeld geändert; er hat einen Absatz in der Spezifikation neu geschrieben, der ändert, was „erledigt" für zwei der drei Linear-Issues bedeutet. Einfache Status-Webhooks verpassen Änderungen auf Anforderungsebene, es sei denn, man fügt Diff-Logik und semantisches Mapping hinzu – was die meisten Teams nie dazu kommen, zu bauen.
Was man tatsächlich braucht, ist etwas, das die Beziehungen zwischen den Daten über Tools hinweg versteht – nicht nur „diese Notion-Seite ist mit diesem Linear-Issue verknüpft", sondern „dieser Abschnitt der Spezifikation beschreibt die Anforderungen für dieses Issue, und dieser Abschnitt hat sich gerade geändert." Das Ziel ist, Spezifikationsänderungen automatisch betroffenen Issues zuzuordnen, anstatt darauf zu vertrauen, dass jemand die Änderung bemerkt und weitergibt.
Das ist der Unterschied zwischen einer Sync-Schicht und einem Wissensgraphen. Eine Sync-Schicht kopiert Daten zwischen Tools. Ein Wissensgraph verfolgt, wie die Daten zusammenhängen, erkennt, wenn sich diese Beziehungen ändern, und zeigt die Änderungen den Menschen, die sie kennen müssen.
Wir bauen Sugarbug, um auf diese Weise zu funktionieren – die Tools verbindend, die PMs und Ingenieure bereits verwenden (Notion, Linear, GitHub, Slack, Figma) in einen Wissensgraphen, der die Beziehungen zwischen Spezifikationen, Aufgaben, Code und Gesprächen pflegt. Wir sind noch früh darin (ehrlich gesagt gibt es noch viel, was wir noch nicht herausgefunden haben, wie man semantische Diff-Erkennung zuverlässig im Maßstab macht), aber der Kern-Graph funktioniert und hat bereits Spezifikationsabweichungs-Situationen aufgefangen, die zu Nacharbeit geführt hätten.
Datensilos zwischen Engineering und Produkt entstehen, weil die Tools strukturell getrennt sind, nicht weil Menschen schlecht kommunizieren. Die Lösung besteht darin, die Daten auf der Beziehungsebene zu verbinden, nicht darin, mehr Kommunikationskanäle hinzuzufügen.
Was Sie diese Woche tun können
Ich werde nicht so tun, als ob die einzige Antwort „Sugarbug verwenden" ist. Es gibt Dinge, die Sie jetzt sofort tun können, mit welchen Tools Sie auch immer bereits nutzen, um die schlimmsten Auswirkungen des Produkt-Engineering-Datensilos zu reduzieren.
Machen Sie Querverweise explizit, bidirektional und zugeordnet. Jede Notion-Spezifikation sollte unten einen Abschnitt „Linear Issues" haben, der auf die daraus entstandenen Issues verlinkt, und jedes Linear-Issue sollte zurück auf seine Quellspezifikation verlinken. Weisen Sie einer Person pro Spezifikation zu, die Querverweise zu pflegen – nicht das gesamte Team, eine Person, mit ihrem Namen darauf. Wir haben die Version „alle sind verantwortlich" ausprobiert und (vorhersehbarerweise) war niemand es. Die Links werden im Laufe der Zeit trotzdem abdriften, aber einen benannten Eigentümer zu haben bedeutet, dass es jemanden zu kontaktieren gibt, wenn die Abweichung bemerkt wird.
Etablieren Sie ein „Spezifikationsänderungs"-Ritual mit einem Auslöser, nicht einer Erinnerung. Wenn sich eine Spezifikation wesentlich ändert (keine Tippfehler – tatsächliche Anforderungsänderungen), aktualisiert der PM die verknüpften Linear-Issues, bevor er den Notion-Tab schließt. Nicht später, nicht „wenn ich Zeit habe" – bevor der Tab geschlossen wird. Der Kommentar bei jedem betroffenen Issue sollte eine Zeile sein: was sich geändert hat, Link zum aktualisierten Abschnitt, und ob die Akzeptanzkriterien des Issues noch gültig sind. Wir haben festgestellt, dass das Verknüpfen der Aktualisierung mit einer physischen Handlung (Schließen des Tabs) besser funktioniert als sich auf jemandes Gedächtnis zu verlassen, weil Gedächtnis genau der Grund ist, warum das Silo sich überhaupt gebildet hat.
Führen Sie einen 15-minütigen Freitagsabend-Prioritätsabgleich durch. Eine Person (wöchentliche Rotation) zieht die Top-5-Prioritäten des PMs in Notion und die Top-5 des Engineering-Sprints in Linear nebeneinander heraus. Die Frage ist nicht „Sind diese identisch?" – das werden sie nicht sein, und das ist in Ordnung. Die Frage ist „Widersprechen sich hier welche aktiv?" Wenn die #1-Priorität des PMs nirgends im Sprint auftaucht, ist das das Gespräch für Montag, keine Status-Aktualisierung.
Dies sind manuelle Prozesse, und sie haben ein Haltbarkeitsdatum. Bei fünf Ingenieuren und zwei PMs sind sie mühsam, aber sie funktionieren. Bei fünfzehn Ingenieuren, drei PMs und einem Design-Team, das Figma in den Mix einbringt, multiplizieren sich die Cross-Tool-Beziehungen schneller, als jemand manuell verfolgen kann. Aber sie werden Ihnen zeigen, wo Ihre schlimmsten Produkt-Engineering-Alignment-Lücken tatsächlich liegen – und dieser diagnostische Wert ist den Aufwand wert, auch wenn man das Ganze irgendwann automatisiert.
Ob die langfristige Lösung Sugarbug oder etwas anderes ist (wir denken offensichtlich, dass wir das Richtige bauen, aber ich bin befangen), das Produkt-Engineering-Collaboration-Problem löst sich nur, wenn die Tools selbst auf semantischer Ebene verbunden sind und Menschen sich auf das Treffen von Entscheidungen konzentrieren können, anstatt Kontext zwischen Apps zu transportieren.
Wenn Ihre manuellen Querverweise funktionieren, nutzen Sie das so lange es geht. Wenn Sie immer wieder die gleichen Retrospektiven-Action-Items über Kommunikation haben, liegt das Problem nicht an Ihren Menschen. Es liegt an Ihrer Datenarchitektur.
Verbinden Sie Notion, Linear, GitHub und Slack in einen Wissensgraphen – damit Spezifikationsänderungen automatisch den richtigen Ingenieuren angezeigt werden.
Q: Wie lange dauert es, Sugarbug für ein Produkt-Engineering-Team einzurichten? A: Die initiale Verbindung dauert wenige Minuten pro Tool – Sie authentifizieren Linear, GitHub, Notion, Slack und Figma via OAuth, und Sugarbug beginnt sofort, den Wissensgraphen aufzubauen. Der Graph wird innerhalb eines bis zwei Tage bedeutungsvoll nützlich, während er Ihre bestehenden Daten aufnimmt und beginnt, Beziehungen zwischen Spezifikationen, Issues und Gesprächen zu kartieren. Wir verfeinern noch den Onboarding-Flow, aber das Ziel ist, dass Sie nichts konfigurieren müssen, außer Ihre Accounts zu verbinden.
Q: Ersetzt Sugarbug Linear, Notion oder eines unserer bestehenden Tools? A: Nein. Sugarbug sitzt neben Ihren bestehenden Tools und verbindet sie – es ersetzt keine davon. Ihre PMs schreiben weiterhin Spezifikationen in Notion, Ihre Ingenieure arbeiten weiterhin in Linear und GitHub, und Sugarbug pflegt die Beziehungen zwischen ihnen, damit Kontext nicht auf dem Weg verloren geht. Betrachten Sie es als das Bindegewebe zwischen den Tools, die Sie bereits verwenden.
Q: Kann Sugarbug erkennen, wenn sich eine Notion-Spezifikation ändert, und die richtigen Ingenieure benachrichtigen? A: Das ist ein Kernbestandteil dessen, was wir aufbauen. Wenn sich eine Spezifikation in Notion ändert, identifiziert Sugarbug, welche Linear-Issues damit verknüpft sind, und zeigt die Änderung den Ingenieuren an, die an diesen Issues arbeiten. Wir iterieren noch an dem semantischen Erkennungsteil (herausfinden, welche Änderungen wesentlich gegenüber kosmetisch sind), aber die Cross-Tool-Verknüpfung und grundlegende Änderungserkennung funktionieren.
Q: Was ist der Unterschied zwischen einem Sync-Tool und einem Wissensgraphen für dieses Problem? A: Ein Sync-Tool kopiert Statusänderungen zwischen Apps – wenn ein Linear-Issue auf „Erledigt" geht, aktualisiere ein Notion-Kontrollkästchen. Ein Wissensgraph verfolgt, wie die Daten zusammenhängen: diese Spezifikation beschreibt die Anforderungen für diese drei Issues, und die Akzeptanzkriterien haben sich geändert, was die zwei Issues betrifft, die noch nicht ausgeliefert wurden. Der Unterschied ist am wichtigsten, wenn die Änderungen semantisch sind, nicht nur auf Statusebene.
Q: Ist Produkt-Engineering-Alignment ein Kommunikationsproblem oder ein Datenproblem? A: In unserer Erfahrung ist es fast immer ein Datenproblem, das als Kommunikationsproblem fehldiagnostiziert wird. Die Teams kommunizieren – sie tun es nur durch Tools, die kein Bewusstsein füreinander haben. Die Behebung des Datenflusses zwischen diesen Tools löst in der Regel die Alignment-Probleme, die kein Maß an Retrospektiven oder Sync-Meetings beheben konnte.