Ein Data Product ist kein Dataset mit einem Owner
Aus Tabellen werden Data Products, aus Verantwortlichen Product Owner – oft nur neues Vokabular für eine alte Realität. Was ein Data Product wirklich vom Dataset unterscheidet: Zweck, Konsument, Grenze, Vertrag und Lifecycle.
Viele Unternehmen haben begonnen, ihre Daten anders zu benennen.
Aus Tabellen werden Datenprodukte. Aus Verantwortlichen werden Product Owner. Aus zentralen Datenplattformen werden Data Marketplaces.
Das klingt nach Fortschritt.
Manchmal ist es aber nur neues Vokabular für eine alte Realität.
Ein Team erzeugt weiterhin einen Datensatz. Ein anderes Team soll ihn verwenden. Irgendjemand wird als Owner eingetragen. Eine Beschreibung kommt in den Datenkatalog. Und plötzlich steht dort:
Data Product: Customer 360.
Das Problem ist nur:
Niemand weiß genau, für wen dieses Produkt gebaut wurde. Niemand kann sagen, welches Problem es löst. Änderungen werden vorgenommen, ohne die Konsumenten zu kennen. Bei falschen Daten beginnt die Suche nach dem zuständigen Team. Und ob der Datensatz tatsächlich genutzt wird, interessiert nach dem Go-live kaum noch jemanden.
Das ist kein Produkt.
Das ist ein Dataset mit besserem Marketing.
Der Unterschied ist entscheidend. Denn „Data as a Product“ funktioniert nicht dadurch, dass wir Datenprodukte deklarieren. Es funktioniert erst dann, wenn wir beginnen, Daten tatsächlich wie Produkte zu behandeln – genau das Prinzip, das auch hinter Data Mesh steht.
Und dafür müssen wir zunächst eine überraschend einfache Frage beantworten:
Ein Produkt beginnt nicht beim Produzenten
Stellen Sie sich vor, ein Unternehmen entwickelt eine neue Anwendung.
Das Entwicklungsteam würde vermutlich nicht mit der Frage beginnen:
Welche Datenbanktabellen haben wir bereits?
Es würde fragen:
Bei Daten machen wir erstaunlich häufig das Gegenteil.
Wir beginnen bei den Quellen.
Im ERP existiert eine Kundentabelle. Im CRM ebenfalls. Dazu kommen Bestellungen, Rechnungen, Servicefälle und vielleicht Daten aus einem Webshop.
Diese Daten werden extrahiert, transformiert und in einer Plattform bereitgestellt.
Technisch funktioniert alles.
Dann erhält das Ergebnis einen Namen:
Customer Data Product
Doch damit haben wir noch kein Produkt geschaffen.
Wir haben Daten verarbeitet.
Ein Produkt entsteht erst durch die Beziehung zwischen einem Problem, einem Konsumenten und einem Nutzen.
Das gilt für Software.
Und es gilt genauso für Daten.
Wer ist eigentlich Ihr Kunde?
Bei einem klassischen Produkt ist diese Frage selbstverständlich.
Bei einem Data Product erstaunlicherweise nicht.
Nehmen wir ein vermeintlich einfaches Datenprodukt:
Customer 360.
Wer ist dessen Konsument?
Marketing?
Dann interessiert vielleicht:
- Welche Kampagnen hat ein Kunde erhalten?
- Welche Produkte besitzt er?
- Wann hat er zuletzt reagiert?
- Welchen erwarteten Customer Lifetime Value besitzt er?
- Über welchen Kanal darf er angesprochen werden?
Der Vertrieb?
Dann werden andere Informationen wichtig:
- Wer ist der Account Owner?
- Welche Opportunities sind offen?
- Welche Verträge laufen aus?
- Welche Ansprechpartner entscheiden?
- Welche Aktivitäten fanden zuletzt statt?
Finance?
Dann könnte „Kunde“ wiederum etwas anderes bedeuten:
- Wer ist Rechnungsempfänger?
- Welche Gesellschaft besitzt die Forderung?
- Welche Rechnungen sind offen?
- Wie hoch ist das Kreditrisiko?
- Welche Zahlungsbedingungen gelten?
Drei Konsumenten.
Ein scheinbar identisches Objekt.
Drei unterschiedliche Bedeutungen von „Customer 360“.
Genau hier beginnt Product Thinking.
Nicht mit der Frage:
Welche Kundendaten können wir bereitstellen?
Sondern:
Das verändert die Architektur fundamental – und oft auch die Domänengrenzen. Genau darum geht es beim domänenorientierten Datenmodelldesign.
Ein Data Product braucht einen Zweck
Unser Gegner sind Projekte, die mit perfekten Folien enden — aber ohne verankerte Entscheidung starten.
Wir schaffen Entscheidungen, die nicht nur plausibel wirken, sondern umgesetzt werden.
Ein Dataset kann existieren, weil Daten existieren.
Ein Data Product sollte existieren, weil jemand damit etwas erreichen möchte.
Das klingt banal. In der Praxis trennt genau diese Unterscheidung nützliche Datenprodukte von Datenfriedhöfen.
Ein Data Product mit der Beschreibung
Enthält harmonisierte Kundeninformationen aus CRM, ERP und Webshop.
beschreibt seine technische Entstehung.
Es sagt aber fast nichts über seinen Nutzen.
Interessanter wäre:
Stellt Marketing und Customer Service eine konsistente Sicht auf aktive Kunden, deren Produkte, Interaktionen und Kommunikationsberechtigungen bereit.
Jetzt entstehen sofort weitere Fragen:
Das sind keine nebensächlichen Detailfragen.
Das sind die Fragen, durch die aus Daten ein Produkt wird.
Ownership ist notwendig. Aber Ownership ist noch kein Product Thinking.
Die häufigste Abkürzung lautet:
Wir brauchen für jedes Datenprodukt einen Owner.
Richtig.
Aber unvollständig.
Denn einen Namen neben ein Dataset zu schreiben löst noch kein Verantwortungsproblem.
Die entscheidende Frage lautet:
Und vielleicht die unangenehmste Frage:
Darf dieser Owner Anforderungen auch ablehnen?
Verantwortung ohne Entscheidungsrecht ist keine Ownership.
Es ist Eskalationsmanagement.
Wenn ein Data Product Owner für Qualität verantwortlich gemacht wird, aber weder die Quellsysteme beeinflussen noch Qualitätsregeln durchsetzen kann, besitzt er keine echte Ownership.
Wenn er für Verfügbarkeit verantwortlich ist, aber keinen Einfluss auf Plattform oder Betrieb hat, ebenfalls nicht.
Wenn fünf Fachbereiche unterschiedliche Definitionen verlangen und der Owner keine Entscheidung treffen darf, werdet ihr keinen Owner haben.
Ihr werdet einen Moderator haben.
Das kann eine sinnvolle Rolle sein.
Aber wir sollten sie dann auch so nennen.
In der Entscheidungsarchitektur ist das derselbe Unterschied: Ownership ohne Entscheidungsrecht bleibt Eskalation. Genau das adressiert der Ownership Blueprint – und organisatorisch die Frage, warum genehmigte Entscheidungen nicht umgesetzt werden.
Gute Data Products haben eine Grenze
Eines der schwierigsten Probleme ist nicht die Frage, was in ein Data Product gehört.
Sondern was nicht hineingehört.
Denn sobald Daten als Produkt gedacht werden, entsteht schnell der Wunsch, ein Produkt möglichst universell zu machen.
Customer 360 soll Marketing unterstützen.
Und Sales.
Und Finance.
Und Risk.
Und Customer Service.
Und AI.
Und zukünftige Anwendungsfälle, die wir heute noch gar nicht kennen.
Das klingt effizient.
In Wahrheit entsteht häufig ein Produkt ohne klaren Konsumenten.
Je mehr Anforderungen wir hineinpacken, desto schwieriger wird jede Änderung.
Eine Definition von „Customer“ muss plötzlich für sechs Bereiche funktionieren.
Eine Änderung an einem Feld benötigt Abstimmung mit zwölf Konsumenten.
Qualitätsanforderungen widersprechen sich.
Aktualitätsanforderungen unterscheiden sich.
Zugriffsrechte werden komplizierter.
Und irgendwann besitzt niemand mehr das Produkt wirklich.
Ein gutes Data Product braucht deshalb nicht nur einen Zweck.
Es braucht auch eine Grenze.
Das Produkt muss sagen können:
Dafür bin ich verantwortlich.
Und genauso:
Dafür nicht.
Das ist kein Mangel.
Das ist Produktdesign.
Daten werden nicht zum Produkt, weil sie im Marketplace stehen
Data Marketplaces sind sinnvoll.
Data Catalogs sind sinnvoll.
Eine gute Suche ist sinnvoll.
Aber ein Marketplace erzeugt keine guten Data Products.
Er macht lediglich sichtbar, was bereits existiert.
Wenn Sie schlechte, schlecht dokumentierte oder bedeutungslose Daten in einen schönen Marketplace stellen, besitzen Sie danach keine Datenprodukte.
Sie besitzen einen komfortabler durchsuchbaren Datenfriedhof.
Ein Datenkatalog bleibt unverzichtbar für Auffindbarkeit und Governance – er ersetzt aber weder Zweck noch Ownership noch Produktversprechen.
Das Problem lässt sich gut mit einem App Store vergleichen.
Ein App Store macht Anwendungen auffindbar.
Aber niemand würde behaupten, eine Anwendung sei gut, weil sie dort gelistet ist.
Sie muss funktionieren.
Sie muss verständlich sein.
Sie muss ein Problem lösen.
Sie braucht einen Verantwortlichen.
Sie muss gepflegt werden.
Nutzer müssen wissen, was sie erwarten können.
Updates dürfen nicht willkürlich Funktionen zerstören.
Und wenn sie nicht mehr benötigt wird, sollte sie irgendwann verschwinden.
Warum sollten für Data Products niedrigere Anforderungen gelten?
Ein Data Product muss auffindbar sein
Das klingt zunächst nach einem reinen Katalogproblem.
Ist es aber nicht.
Auffindbarkeit beginnt bereits bei der Benennung.
Stellen Sie sich vor, ein Analyst sucht Daten zum Umsatz.
Er findet:
F_SALES_V3
REV_AGG_MONTHLY
FIN_04
SALES_CURATED
BOOKINGS_FINAL_FINAL
Technisch sind diese Namen vielleicht nachvollziehbar.
Aus Sicht eines Konsumenten sind sie nahezu wertlos.
Ein Produkt muss in der Sprache seiner Nutzer auffindbar sein.
Das betrifft Namen, Beschreibungen, Begriffe, Synonyme und fachliche Zusammenhänge.
Wer nach „Umsatz“ sucht, sollte nicht wissen müssen, dass Finance intern von net_revenue_recognized spricht.
Wer nach „Kunde“ sucht, sollte verstehen können, warum es möglicherweise mehrere Kundenbegriffe gibt.
Und wer ein Produkt findet, sollte erkennen:
Auffindbarkeit bedeutet deshalb nicht nur:
Ich kann das Dataset finden.
Sondern:
Ich kann erkennen, ob dieses Dataset mein Problem löst.
Das ist ein erheblicher Unterschied.
Ein Data Product muss verständlich sein
Stellen Sie sich vor, Sie erhalten folgende Tabelle:
| customer_id | revenue | status | date |
|---|---|---|---|
| 84721 | 182,400 | A | 2026-07-31 |
Die Daten sind sauber.
Keine NULL-Werte.
Datentypen stimmen.
Pipeline erfolgreich.
Ist das ein gutes Produkt?
Keine Ahnung.
Daten können technisch perfekt und fachlich nahezu unbrauchbar sein.
Ein Data Product braucht deshalb nicht nur Schema-Dokumentation.
Es braucht Bedeutung.
Und genau hier wird die Verbindung zu Semantik, Business Glossaries, Knowledge Graphs und AI interessant – und zum Kontextlayer: Bedeutung muss aus dem Unternehmen kommen, nicht aus dem Modell. Beziehungen und Begriffe modellieren wir deshalb explizit, etwa im Knowledge Graph im Unternehmen.
Ein LLM kann Ihnen hervorragend erklären, was revenue wahrscheinlich bedeutet.
Aber „wahrscheinlich“ ist bei Unternehmenskennzahlen keine akzeptable Definition.
Die Bedeutung muss aus dem Unternehmen kommen.
Nicht aus dem Modell.
Ein Data Product muss diese Bedeutung transportieren.
Ein Data Product muss vertrauenswürdig sein
„Data Quality“ wird häufig wie eine binäre Eigenschaft behandelt.
Daten sind entweder gut oder schlecht.
In Wirklichkeit hängt Qualität vom Verwendungszweck ab.
Für einen monatlichen Managementbericht können Daten mit 24 Stunden Verzögerung vollkommen ausreichend sein.
Für Fraud Detection sind sie möglicherweise wertlos.
Eine Kundenadresse kann für eine Marketinganalyse gut genug sein.
Für die Zustellung eines physischen Produkts nicht.
Ein Data Product sollte deshalb nicht einfach behaupten:
Quality: 98 %
Was soll das bedeuten?
Interessanter sind konkrete Erwartungen:
Vertrauen entsteht nicht dadurch, dass Daten fehlerfrei sind.
Das werden sie nie sein.
Vertrauen entsteht dadurch, dass Konsumenten wissen, was sie erwarten können.
Ein Data Product braucht einen Vertrag
Sobald andere Teams ein Data Product produktiv verwenden, entsteht eine Abhängigkeit.
Und Abhängigkeiten brauchen Stabilität.
Angenommen, ein Data Product liefert:
customer_id
country
segment
annual_revenue
Drei Teams bauen darauf Reports.
Ein Machine-Learning-Modell nutzt segment.
Ein operativer Prozess verwendet country.
Dann entscheidet das Produzententeam:
Wir räumen einmal auf.
country wird zu country_code.
annual_revenue wird entfernt.
segment bekommt neue Werte.
Technisch vielleicht eine Verbesserung.
Für vier Konsumenten möglicherweise ein Produktionsproblem.
Genau deshalb sind Data Contracts interessant.
Nicht als weiteres Governance-Dokument, das niemand liest.
Sondern als explizite Vereinbarung zwischen Produzent und Konsument.
Damit verändert sich eine Pipeline von
Hier sind Daten.
zu
Darauf können Sie sich verlassen.
Das ist ein Produktversprechen – derselbe Anspruch, den Evidence-first AI an die Beleggrundlage stellt: erst Vertrag und Evidenz, dann Nutzung und Formulierung.
Self-Service beginnt nicht mit Zugriff
Viele Unternehmen möchten Self-Service Analytics.
Also geben sie mehr Menschen Zugriff auf mehr Daten.
Das Ergebnis ist nicht automatisch Self-Service.
Manchmal ist es einfach nur Self-Service Confusion.
Echter Self-Service bedeutet:
Ein Nutzer findet ein geeignetes Data Product.
Er versteht, was es bedeutet.
Er weiß, wie aktuell es ist.
Er erkennt seine Qualität.
Er kann nachvollziehen, woher es kommt.
Er weiß, wie er Zugriff erhält.
Er kann es verwenden, ohne zuerst drei Data Engineers anzurufen.
Und wenn etwas nicht stimmt, weiß er, wer verantwortlich ist.
Das ist eine hohe Messlatte.
Aber genau das sollte der Anspruch sein.
Technisch helfen Zero-Copy-Ansätze wie Delta Sharing und die Logik hinter Daten teilen statt kopieren – aber nur, wenn das geteilte Objekt bereits ein Produkt mit Versprechen ist, nicht nur ein weiterer Share.
Ein Data Product ist nicht self-service-fähig, wenn sein Owner jede Woche zehn Nachrichten beantworten muss:
Dann ist der Owner kein Product Owner.
Er ist die menschliche Dokumentation des Produkts.
Nutzung ist kein Nebeneffekt
Hier unterscheidet sich Product Thinking besonders deutlich von klassischem Datenplattformdenken.
Bei Pipeline, Projekt und Migration lautet Erfolg häufig:
läuft.
geliefert.
abgeschlossen.
Bei einem Produkt reicht das nicht.
Ein Produkt, das niemand benutzt, ist nicht erfolgreich, nur weil es technisch funktioniert.
Deshalb sollten Data Product Teams wissen:
Das kann unangenehm werden.
Vielleicht stellt sich heraus, dass das „strategische Customer Data Product“, in das sechs Monate investiert wurden, kaum jemand verwendet.
Vielleicht exportieren Analysten weiterhin Daten aus dem alten System.
Vielleicht existieren fünf parallele Revenue-Datasets.
Vielleicht besitzt das offizielle Produkt die höchste Datenqualität, aber niemand versteht seine 180 Spalten.
Das sind keine Adoption-Probleme, die man mit einer Schulung behebt.
Das sind Produktinformationen.
Sie sagen Ihnen etwas über Ihr Produkt.
Und manchmal sollte ein Data Product sterben
Auch das gehört zu Product Thinking.
Datenplattformen haben eine bemerkenswerte Fähigkeit, Dinge für immer aufzubewahren.
Tabellen.
Views.
Pipelines.
Dashboards.
APIs.
Datasets.
Alles könnte schließlich noch jemand benötigen.
Das Ergebnis kennen viele Unternehmen:
Niemand weiß mehr, was offiziell ist.
Alte und neue Versionen existieren nebeneinander.
Konsumenten verwenden versehentlich veraltete Daten.
Kosten steigen.
Abhängigkeiten werden undurchsichtig.
Und niemand traut sich, etwas zu löschen.
Produkte haben einen Lebenszyklus.
Data Products sollten ebenfalls einen haben:
Idee → Entwicklung → Veröffentlichung → Nutzung → Weiterentwicklung → Deprecation → Abschaltung
Wenn ein Produkt keine Konsumenten mehr besitzt, zwei denselben Zweck erfüllen oder eines ersetzt wird, sollten diese Fragen erlaubt sein:
Auch das ist Ownership.
Nicht jedes Dataset muss ein Data Product sein
Vielleicht ist das die wichtigste Konsequenz.
Wenn wir jedes Dataset zum Data Product erklären, verliert der Begriff seine Bedeutung.
Eine temporäre Staging-Tabelle ist kein Produkt.
Ein technisches Zwischenresultat einer Pipeline ist kein Produkt.
Eine Kopie aus einem Quellsystem ist nicht automatisch ein Produkt.
Ein Dataset, das nur von einem einzelnen Prozess intern benötigt wird, muss möglicherweise ebenfalls keines sein.
Und das ist vollkommen in Ordnung.
Nicht alle Daten müssen Produkte sein.
Der Produktgedanke wird gerade dadurch wertvoll, dass wir ihn dort einsetzen, wo mehrere Konsumenten eine verlässliche, verständliche und langfristig gepflegte Datenschnittstelle benötigen.
Sonst erzeugen wir vor allem Verwaltungsaufwand.
Plötzlich brauchen 4.000 Tabellen 4.000 Owner.
4.000 Beschreibungen.
4.000 Qualitätsdefinitionen.
4.000 Produkte im Marketplace.
Das ist keine Demokratisierung von Daten.
Das ist Bürokratie mit Metadaten.
Data Products verändern die Grenze zwischen Business und IT
Traditionell ist die Arbeitsteilung häufig ungefähr so:
Das Business definiert Anforderungen.
IT baut Datenlösungen.
Das Business konsumiert Ergebnisse.
Bei Data Products funktioniert diese Trennung schlecht.
Denn viele Eigenschaften eines Data Products sind weder rein technisch noch rein fachlich.
Was bedeutet „Kunde“?
Fachlich.
Wie wird diese Definition aus sechs Systemen berechnet?
Technisch.
Welche Qualität ist akzeptabel?
Fachlich.
Wie wird sie automatisiert überwacht?
Technisch.
Wer darf die Daten sehen?
Fachlich, rechtlich und technisch.
Wie schnell müssen sie verfügbar sein?
Business Requirement mit technischer und finanzieller Konsequenz.
Ein echtes Data Product zwingt beide Seiten deshalb zu gemeinsamer Verantwortung.
Und vielleicht ist genau das einer der größten Vorteile des Konzepts.
Nicht die neue Architektur.
Nicht der Marketplace.
Nicht das neue Rollenmodell.
Sondern die Erkenntnis:
Daten besitzen erst dann Wert, wenn Produzenten verstehen, was Konsumenten damit tun.
Genau deshalb ist die hybride Business Analytics Plattform kein Selbstzweck: Sie verbindet Quellen so, dass Entscheidungen belastbar werden – nicht so, dass möglichst viele Tabellen im Marketplace stehen.
Data Products sind besonders für AI relevant
Mit generativer AI bekommt diese Diskussion eine neue Dimension.
Bisher konnten schlechte Metadaten und unklare Semantik dadurch kompensiert werden, dass ein erfahrener Analyst wusste, wen er fragen musste.
Ein AI-Agent besitzt dieses informelle Organisationswissen nicht automatisch.
Er sieht Daten.
Beschreibungen.
Metadaten.
Beziehungen.
Policies.
Wenn dort fünf verschiedene Revenue-Datasets existieren, muss er entscheiden, welches davon relevant ist.
Wenn zwei unterschiedliche Definitionen von „aktiver Kunde“ existieren, braucht er Kontext.
Wenn eine Kennzahl nur für bestimmte Länder verwendet werden darf, muss diese Regel explizit sein.
Wenn Daten veraltet sind, muss Aktualität sichtbar sein.
Und wenn eine Quelle nicht autoritativ ist, darf das LLM nicht einfach aus fünf plausiblen Tabellen diejenige auswählen, deren Spaltennamen am besten zur Frage passen.
Genau hier wird Data Product Thinking zur Grundlage für Enterprise AI.
Nicht weil AI zwingend „Data Products“ als Architekturpattern benötigt.
Sondern weil AI explizite Antworten auf Fragen braucht, die Menschen bisher häufig informell gelöst haben:
Ein sauber beschriebenes Data Product beantwortet genau diese Fragen – und liefert damit die Voraussetzung dafür, dass Unternehmenskontext nicht im Prompt landet, sondern in einem prüfbaren Modell. Für den konkreten Einsatzpunkt gilt dasselbe wie bei KI Use Cases für Entscheidungsbeschleunigung: an den Entscheidungstyp koppeln, nicht am Showcase.
Ein einfacher Test für Ihre Data Products
Öffnen Sie Ihren Data Catalog oder Marketplace.
Wählen Sie eines Ihrer wichtigsten „Data Products“.
Und versuchen Sie, ohne den Owner anzurufen, folgende Fragen zu beantworten:
Wer konsumiert dieses Produkt?
Nicht „das Unternehmen“.
Konkrete Rollen, Teams oder Anwendungen.
Welche Entscheidungen oder Prozesse unterstützt es?
Nicht „Analytics“.
Konkreter Nutzen.
Was bedeutet der Inhalt fachlich?
Nicht nur Tabellen- und Spaltenbeschreibungen.
Begriffe und Regeln.
Welche Qualität kann ich erwarten?
Nicht „high“.
Messbare Erwartungen und bekannte Grenzen.
Wie aktuell sind die Daten?
Und entspricht diese Aktualität dem Use Case?
Was darf sich ändern, ohne dass Konsumenten informiert werden?
Gibt es einen Contract oder wenigstens definierte Change-Regeln?
Wer kann fachliche Entscheidungen über das Produkt treffen?
Nicht nur: Wer bekommt das Ticket?
Wer verwendet es tatsächlich?
Nicht: Wer könnte es verwenden?
Was passiert, wenn es morgen ausfällt?
Gibt es kritische Abhängigkeiten?
Wann würden Sie dieses Produkt abschalten?
Wenn die Antwort „nie“ lautet, besitzen Sie wahrscheinlich kein Lifecycle Management.
Wenn Sie die meisten dieser Fragen nicht beantworten können, ist das kein Drama.
Aber vielleicht besitzen Sie noch kein Data Product.
Vielleicht besitzen Sie ein Dataset.
Und genau dort sollten Sie anfangen.
Das Produkt ist nicht die Tabelle
Das ist letztlich der Denkfehler hinter vielen Data-Product-Initiativen.
Wir suchen nach dem technischen Objekt, das wir zum Produkt erklären können.
Eine Tabelle.
Eine View.
Ein Schema.
Eine API.
Ein Dashboard.
Doch das Produkt ist nicht zwingend eines dieser Dinge.
Diese Dinge sind Schnittstellen zum Produkt.
Das eigentliche Produkt ist ein verlässliches Versprechen an einen Konsumenten:
Für diesen Zweck stellen wir Ihnen diese Daten mit dieser Bedeutung, dieser Qualität, dieser Aktualität und diesen Regeln zur Verfügung – und jemand übernimmt Verantwortung dafür, dass dieses Versprechen eingehalten wird.
Das ist deutlich anspruchsvoller, als einen Owner in einen Datenkatalog einzutragen.
Aber genau deshalb ist der Begriff „Product“ überhaupt nützlich.
Wenn Sie lediglich Daten veröffentlichen wollen, brauchen Sie kein Product Thinking.
Wenn Sie möchten, dass andere Teams auf diesen Daten Entscheidungen, Anwendungen, Analytics und AI aufbauen können, schon.
Denn ein Dataset beantwortet die Frage:
Welche Daten haben wir?
Ein gutes Data Product beantwortet eine wesentlich wichtigere:
Über den Autor
Verwandte Artikel
Sie warteten nicht auf Rom
14. August 2026
Unternehmenskontext gehört nicht in den Prompt.
7. August 2026
Das LLM darf antworten. Es darf nicht entscheiden, was wahr ist.
5. August 2026
Das Sparkline-Geheimnis hinter jeder wirksamen Rede
2. August 2026
Knowledge Graph im Unternehmen: Ihr Data Warehouse versteht nichts
27. Juli 2026
Die Entscheidungsvorlage für den Vorstand, die Umsetzung erzwingt
24. Juli 2026