Product Management für Daten

2016 hatten bei Airbnb rund 100 Analysten dieselbe Metrik „market health" in fünfzehn leicht unterschiedlichen Varianten gebaut. Jedes Executive Review begann mit einem Streit darüber, wessen Zahl stimmte. Die Lösung war kein neues Dashboard und kein Governance-Memo, sondern **den Metrics Layer als *Produkt* zu behandeln, mit einem Owner, einer Roadmap, Versionierung und einem Vertrag mit seinen Konsumenten**. Aus diesem Reframing entstand die Metrics-Plattform Minerva. Die Lektion für Sie liegt nicht im Tooling. Sie liegt darin, dass Airbnb aufhörte, Daten-*Artefakte* auszuliefern, und begann, Data Products auszuliefern, und der Unterschied lag fast vollständig in der Disziplin, wer die Sache besaß und wie Entscheidungen darüber getroffen wurden.

Sie wissen konzeptionell schon, was ein Data Product ist. Was die meisten CDOs falsch machen: Sie nehmen an, dass ein domänenorientiertes Dataset mit einem SLA damit ein Produkt sei. Ist es nicht. Ein Produkt definiert sich über **eine *über Zeit gemanagte Beziehung zu einem Konsumenten*, die Discovery des echten Bedarfs, rigorose Priorisierung und einen Lifecycle, der auch die unglamouröse Arbeit der Deprecation umfasst**. In dieser Lektion geht es darum, diese Disziplin zu installieren, und um die Rolle, die sie trägt: den Data Product Manager (DPM).

Warum Product Discipline bricht, wenn Sie sie aus der Software kopieren

Der Reflex ist, Software Product Management unverändert zu übernehmen. Das scheitert auf drei konkrete Weisen, und wer die Failure Modes versteht, weiß, was er stattdessen bauen muss.

Erstens sind Ihre „User" oft Maschinen und Pipelines, keine Menschen, die auf eine UI klicken. Eine Feature-Store-Tabelle, die ein Fraud-Modell versorgt, hat keine User Session, keinen funnel, keine NPS-Umfrage. Discovery kann sich nicht darauf stützen, Menschen bei der Nutzung zu beobachten. Sie müssen die *Consumption* instrumentieren: welche Downstream-Jobs welche Spalten lesen, wie Freshness die Modellperformance beeinflusst, welche Felder abgefragt werden und welche toter Ballast sind. Das Produktsignal steckt in den Query Logs und im Lineage Graph, nicht allein in User Interviews.

Zweitens sind die Kosten eines Breaking Change asymmetrisch und für Sie oft unsichtbar. In der Software: Wenn Sie eine API brechen, crasht die Client-App und jemand schreibt ein Ticket. Bei Daten: Wenn Sie die Semantik einer Spalte still ändern, etwa revenue von brutto auf netto, crasht nichts. Modelle driften, Dashboards lügen leise, und drei Wochen später trifft ein VP eine schlechte Entscheidung. Der Blast Radius eines Data Products ist größer und stiller als der eines Software-Features, was bedeutet: Der *Contract* muss mehr leisten.

Drittens ist der Wert häufig indirekt. Ein Software-Feature lässt sich oft an eine Conversion- oder Retention-Zahl binden. Eine kanonische Customer Entity schafft Wert vielleicht dadurch, dass sie neun Downstream-Produkte ermöglicht, von denen ihr keines Kredit gibt. Das ruiniert naive ROI-basierte Priorisierung und zwingt DPMs, in *Option Value* und *Dependency Leverage* zu denken, nicht nur in direkter Nutzung.

Der DPM ist also kein Software-PM, der die Domäne gewechselt hat. Die Rolle ist ein Hybrid: genug Data-Engineering-Fluency, um einen Lineage Graph zu lesen und ein Schema zu hinterfragen, genug Domänenökonomie, um zu wissen, welche Entscheidungen ein Dataset tatsächlich informiert, und genug politisches Kapital, um einem fordernden VP Nein zu sagen. Wenn Sie für diese Rolle einstellen oder befördern, **gewichten Sie *Urteilsvermögen über Konsumentenbedarf unter Unsicherheit* höher als Tool-Expertise**. Die Tools ändern sich, das Urteilsvermögen verzinst sich.

Was der DPM tatsächlich besitzt

Ziehen Sie die Linie klar, sonst bekommen Sie einen Koordinator, der Meetings bucht. Ein echter DPM besitzt vier Dinge:

Die Problemdefinition, also welche Entscheidung oder welchen Workflow dieses Produkt verbessert, formuliert in der Sprache des Konsumenten.
Die priorisierte Roadmap, also was gebaut wird, was abgelehnt wird, in welcher Reihenfolge.
Den Interface Contract, also Schema, Semantik, SLAs und die Change Policy.
Den Lifecycle, vom Launch über Iteration bis zur Deprecation.

Sie besitzen *nicht* die Implementierung der Pipeline (das ist Data Engineering) oder die Storage-Architektur (behandelt in Ihren Fundamentals). **Der DPM besitzt die *Außenseite* des Produkts, das Versprechen, während Engineering die *Innenseite* besitzt.**

Discovery: das Produkt im Request finden

Jeder CDO bekommt einen Strom von Requests, die wie Produkte klingen: „Wir brauchen ein Churn-Dataset." „Marketing will einen unified customer view." Diese als Specs zu behandeln, führt direkt zum Problem der 15 Versionen von „market health". Discovery ist die Disziplin, einen Request in ein validiertes Problem zu übersetzen, bevor Engineering-Kapazität gebunden wird.

Die besten DPMs fahren eine komprimierte Version der „Jobs to Be Done"-Logik, adaptiert für Daten. Die Frage ist nicht „Welche Daten wollen Sie?". Sie lautet „Welche Entscheidung treffen Sie, wie oft, und was kostet es, falsch zu liegen?" Dieses Reframing leistet drei Dinge: Es zeigt, ob der Request ein echter wiederkehrender Bedarf ist oder eine Einmalanalyse (die überhaupt kein Produkt sein sollte), es leitet die nötige Freshness und Accuracy aus der Ökonomie der *Entscheidung* ab statt aus der Wunschliste des Anfragenden, und es bringt die echten Konsumenten zum Vorschein.

Nehmen Sie einen Request für „Echtzeit-Inventardaten". Discovery zeigt: Die tatsächliche Entscheidung ist eine nächtliche Nachbestellung um 2 Uhr. Echtzeit ist teuer und irrelevant, ein verlässlicher Batch-Snapshot um 23 Uhr ist das Produkt. Sie haben gerade ein Quartal Streaming-Infrastruktur gespart, weil Sie nach der Entscheidung gefragt haben statt nach den Daten.

Ein praktisches Discovery-Artefakt, auf dem ich bestehe, ist ein einseitiges Data Product Brief, das der DPM *vor* jedem Build schreibt:

yaml

product: customer_churn_signals
consumer_decision: "Retention team decides weekly which accounts get intervention"
decision_cadence: weekly
cost_of_error:
  false_positive: "$40 wasted outreach per account"
  false_negative: "avg $2,400 lost LTV per churned account"
required_freshness: "daily, by 6am"
required_accuracy: "recall prioritized over precision"
consumers: [retention_ops, cs_leadership_dashboard, expansion_model_v3]
NOT_in_scope: ["real-time scoring", "prospect data"]

Beachten Sie die Asymmetrie bei cost_of_error: False Negatives kosten 60-mal mehr als False Positives. Diese eine Zeile diktiert das Optimierungsziel des Modells und das SLA. Beachten Sie NOT_in_scope. Die Hälfte der Discovery besteht darin, zu entscheiden, was das Produkt *nicht* sein wird. Airbnbs Minerva war teilweise deshalb erfolgreich, weil es erklärte, nur *zertifizierte* Metriken zu bedienen, nicht jede Ad-hoc-Berechnung.

Priorisierung: das Portfolio-Problem, auf das niemand Sie vorbereitet hat

Hier verlieren CDOs Wert. Weil Data Products indirekten und vernetzten Wert haben, unterbewerten Standard-Priorisierungs-Frameworks (RICE, Weighted Scoring) systematisch genau die Produkte, die am wichtigsten sind: die fundamentalen Entities und Metriken, von denen alles andere abhängt.

Nutzen Sie eine Zwei-Achsen-Linse, die der DPM auf jeden Kandidaten anwendet: Decision Leverage (wie viele Entscheidungen mit hohem Einsatz dieses Produkt berührt, gewichtet nach ihrem Wert) gegen Cost-to-Serve Reliably (Build plus laufende Wartungslast, inklusive On-Call). Die Falle: Fundamentale Produkte, etwa eine kanonische Customer- oder Product-Entity, scoren beim *direkten* Leverage niedrig, weil keine einzelne Entscheidung ihnen „gehört", und sie schalten doch Dutzende Downstream-Produkte frei. Der DPM muss Dependency Leverage explizit modellieren: Der Score eines Produkts erbt einen Bruchteil des Werts von allem, was darauf aufbaut.

Deshalb trennen Sie das Portfolio in drei Tiers, die unterschiedlich finanziert werden:

Platform Products (kanonische Entities, der Metrics Layer, zentrale Feature-Tabellen): finanziert als Infrastruktur, bewertet an Adoption und Reuse, nicht an direktem ROI. Das sind Ihre Assets der Minerva-Klasse.
Decision Products (ein spezifisches Churn-Modell, ein Dataset zur Preiselastizität): finanziert auf Basis der Entscheidungsökonomie, bewertet daran, ob die Entscheidung besser wurde.
Exploratory Products (eine neue experimentelle Segmentierung): finanziert als Optionen, zeitlich begrenzt, schnell eingestellt, wenn sie sich nicht validieren.

Der wertvollste Priorisierungszug eines DPM ist, nicht zu bauen. Jedes Data Product erzeugt eine permanente Wartungssteuer: Schema Drift, Upstream-Änderungen, On-Call, verfallende Dokumentation. Eine Regel, die ich funktionieren gesehen habe: Kein neues Produkt geht live, bis das Team identifiziert hat, welche Kapazität es *dauerhaft* verbrauchen wird, nicht nur für den Build. Ist ein Team an der Wartungssättigung, lautet die Antwort auf einen neuen Request „nein" oder „was deprecaten wir zuerst?", nicht „ja, nächstes Quartal".

Die Wartungssteuer sichtbar machen

Geben Sie Ihrem DPM eine einfache Kennzahl zum Reporting nach oben: Build-Kapazität vs. Run-Kapazität. Wenn Run über etwa 60-70 % der Gesamtkapazität des Teams liegt, sind Sie keine Produktorganisation mehr, sondern eine Wartungsorganisation, und Innovation hat aufgehört. Diese Kennzahl ist Ihr Frühwarnsignal, dass das Portfolio zu viele Produkte und zu wenig Deprecation hat. Sie ist auch die Zahl, die Sie zu Ihrem CFO tragen, um entweder Headcount oder einen Deprecation-Sprint zu begründen. Die meisten CDOs messen sie nie und sind dann ratlos, wenn die Velocity einbricht.

Wissenscheck

1. Was unterscheidet laut Lektion ein Data Product wirklich von einem bloßen Daten-Artefakt?

2. Warum erfordert Discovery für ein Data Product oft die Instrumentierung der Consumption statt sich allein auf User Interviews zu stützen?

3. Die Lektion argumentiert, die Kosten eines Breaking Change bei Daten seien „asymmetrisch und oft unsichtbar". Was ist die zentrale Implikation für die Gestaltung eines Data Products?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Wege, auf denen laut Lektion die unveränderte Übernahme von Software Product Management bei Daten scheitert.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die die Argumentation der Lektion zur Rolle des Data Product Managers (DPM) und zu Product Discipline korrekt wiedergeben.

Wählen Sie alle richtigen Antworten aus.

Lifecycle: die Disziplin von Contracts und Endungen

Software-Teams haben vor Jahrzehnten gelernt, dass das Leben eines Produkts überwiegend *nach* dem Launch stattfindet. Datenteams verhalten sich routinemäßig, als wäre der Launch die Ziellinie. Der dauerhafteste Beitrag des DPM ist das Management des gesamten Lifecycles, besonders der zwei Phasen, die Teams vernachlässigen: der Interface Contract und die Deprecation.

Der Contract ist das echte Interface des Produkts. Weil Breaking Changes still sind und einen großen Blast Radius haben (erinnern Sie sich an das brutto-vs.-netto-Beispiel), muss der Contract explizit und maschinell erzwingbar sein. Hier zahlt sich die moderne Praxis der „Data Contracts" aus. Der DPM besitzt die *Semantik und Change Policy* des Contracts, Engineering erzwingt ihn in der Pipeline. Ein minimaler Contract deklariert das Schema, die semantische Bedeutung jedes Feldes, die SLAs und, entscheidend, die Change Policy: was als Breaking Change gilt, wie viel Vorlauf Konsumenten bekommen und wie Versionen koexistieren.

Die Change Policy ist eine *Produkt*entscheidung, keine technische, denn sie tauscht Konsumentenstabilität gegen Ihre Velocity. Ein Platform Product, das 40 Konsumenten bedient, verspricht vielleicht 90 Tage Deprecation-Vorlauf und parallel laufende Versionen. Ein Exploratory Product verspricht vielleicht nichts. Der DPM legt das bewusst pro Tier fest.

Versionierung muss real sein, nicht Absichtserklärung. Wenn sich Semantik ändert, publizieren Sie v2 neben v1, migrieren Konsumenten nach Plan und nehmen erst dann v1 außer Betrieb. Das ist operativ teuer, und genau deshalb zählen Priorisierung und Verweigerung: Jedes Produkt, das Sie ausliefern, ist eine Versionierungspflicht, die Sie akzeptieren.

Deprecation ist die Phase, die eine Produktorganisation von einer Müllhalde trennt. Die meisten Data Estates bestehen zu 60 % aus verwaisten Tabellen, die niemand zu löschen wagt, weil niemand weiß, wer sie liest. Der DPM fährt Deprecation als gemanagten Prozess: Consumption instrumentieren, Produkte unter einer Nutzungsschwelle identifizieren, Sunset mit Migrationspfad ankündigen, löschen. Das ist unglamourös, und es ist die Hygienemaßnahme mit dem größten Hebel in Ihrem gesamten Estate, denn jedes stillgelegte Produkt gibt Run-Kapazität an die Build-Spalte zurück.

Eine konkrete Betriebskadenz für Ihren DPM: ein Quarterly Portfolio Review, das für jedes Produkt drei Fragen beantwortet, *Nutzt es überhaupt noch jemand? Erfüllt es seinen Contract? Soll es hochgestuft, weiter investiert oder eingestellt werden?* Produkte, die den Nutzungstest nicht bestehen, bekommen auf der Stelle ein Sunset-Datum. Dieses Review ist der Mechanismus, der das Build/Run-Verhältnis gesund hält. Führen Sie es die ersten zwei Quartale selbst, damit die Organisation sieht, dass das Einstellen von Produkten gefeiert und nicht bestraft wird. Das kulturelle Signal, dass ein DPM, der zehn tote Produkte deprecatet, genauso wertgeschätzt wird wie einer, der ein neues ausliefert, kann nur Sie als CDO senden.

Die Health eines Data Products messen

Direkte Nutzung ist notwendig, aber nicht ausreichend. Verfolgen Sie vier Signale pro Produkt: Adoption (unterschiedliche Konsumenten und deren Trend), Reliability (Contract-Einhaltung, erfüllte Freshness- und Quality-SLAs), Decision Impact (hat sich die Zielentscheidung messbar verbessert, das Schwerste und Wichtigste) und Cost-to-Serve (Compute plus menschliche Wartung). Ein Produkt mit hoher Adoption und Reliability, aber unbekanntem Decision Impact ist ein Kandidat für eine tiefere Untersuchung, nicht für automatische Verlängerung, es könnte ein schön gepflegtes Artefakt sein, das keine Entscheidung verändert.

Key Takeaways

Installieren Sie die DPM-Rolle mit einem scharfen Mandat: Sie besitzt Problemdefinition, Roadmap, Interface Contract und Lifecycle, die *Außenseite* des Produkts. Engineering besitzt die *Innenseite*. Verwischen Sie das, und Sie bekommen einen Meeting-Koordinator, keinen Product Owner.

Verankern Sie Discovery in der Entscheidung, nicht im Daten-Request. Verlangen Sie, dass jedes Product Brief die Konsumentenentscheidung, ihre Kadenz und die asymmetrischen Kosten des Falschliegens benennt. Diese eine Disziplin bemisst Freshness, Accuracy und Scope richtig und killt Produkte, die Einmalanalysen hätten sein sollen.

Priorisieren Sie über drei Tiers und mit Dependency Leverage im Blick. Finanzieren Sie Platform Products als Infrastruktur über Reuse, Decision Products über Entscheidungsökonomie und Exploratory Products als zeitlich begrenzte Optionen. Standard-RICE-Scoring wird Ihre fundamentalsten Assets aushungern.

Beobachten Sie das Build/Run-Kapazitätsverhältnis wie eine P&L-Zeile. Wenn Run über ~60-70 % liegt, haben Sie aufgehört zu innovieren. Das ist Ihr quantitativer Trigger für Headcount oder einen Deprecation-Sprint, und die Zahl, die Sie zum CFO mitnehmen.

Behandeln Sie Deprecation als vollwertige, gefeierte Aktivität. Führen Sie ein Quarterly Portfolio Review, das ungenutzten Produkten ein Sunset-Datum gibt. Jedes stillgelegte Produkt gibt Kapazität ans Bauen zurück, und nur Sie können das kulturelle Signal senden, dass das Einstellen toter Produkte genauso wertgeschätzt wird wie das Ausliefern neuer.