Product Management für Daten

# Product Management für Daten

2016 hatte Airbnb rund 100 Analysten, die dieselbe Metrik „market health" in fünfzehn leicht unterschiedlichen Varianten bauten. Jedes Executive Review begann mit einem Streit darüber, wessen Zahl richtig war. Die Lösung war kein neues Dashboard und kein Governance-Memo, sondern der Metrik-Layer als *Product* zu behandeln, mit einem Owner, einer Roadmap, Versionierung und einem Contract mit seinen Konsumenten. Aus dieser Neuausrichtung entstand die Metrics-Plattform Minerva. Die Lehre für Sie liegt nicht im Tooling. Sie liegt darin, dass Airbnb aufhörte, Daten-*Artefakte* auszuliefern, und anfing, 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 bereits, was ein Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → ist. Was die meisten CDOs falsch einschätzen: Sie nehmen an, ein domänenorientiertes Dataset mit einem SLA sei damit ein Product. Ist es nicht. Ein Product definiert sich über eine *gemanagte Beziehung zu einem Konsumenten über Zeit*, über Discovery des echten Bedarfs, kompromisslose Priorisierung und einen Lebenszyklus, der auch die undankbare Arbeit der Deprecation umfasst. In dieser Lektion geht es darum, diese Disziplin zu installieren, und um die Rolle, die sie trägt: den Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → Manager (DPM).

Warum Product-Disziplin bricht, wenn Sie sie aus der Software kopieren

Der Reflex ist, Software Product Management vollständig zu übernehmen. Das scheitert auf drei konkrete Weisen, und wer die Fehlermodi versteht, weiß, was ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → stattdessen aufbauen muss.

Erstens sind Ihre „User" oft Maschinen und Pipelines, keine Menschen, die auf ein UI klicken. Eine Feature-Store-Tabelle, die ein Fraud-Modell versorgt, hat keine User Session, keinen funnelfunnelThe customer journey from awareness to purchase, typically Awareness, Interest, Consideration, Decision, Action, with prospects narrowing at each stage.Vollständige Definition ansehen →, keine NPSNPSNet Promoter Score (NPS) measures customer loyalty by asking how likely customers are to recommend a brand, then subtracting detractors from promoters.Vollständige Definition ansehen →-Umfrage. Discovery kann sich nicht darauf stützen, Menschen bei der Nutzung zuzusehen. Sie müssen *Consumption* instrumentieren: welche Downstream-Jobs welche Spalten lesen, wie Freshness die Modell-Performance beeinflusst, welche Felder abgefragt werden und welche toter Ballast sind. Das Product-Signal 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 stürzt bei einem gebrochenen APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → die Client-App ab und jemand schreibt ein Ticket. Bei Daten stürzt nichts ab, wenn Sie stillschweigend die Semantik einer Spalte ändern, etwa wenn revenue von brutto auf netto wechselt. Modelle driften, Dashboards lügen leise, und drei Wochen später trifft ein VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Vollständige Definition ansehen → eine schlechte Entscheidung. Der Blast Radius eines Data Products ist größererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → und stiller als der eines Software-Features, und das heißt: Der *Contract* muss mehr Arbeit leisten.

Drittens ist Wert häufig indirekt. Ein Software-Feature lässt sich oft an eine Conversion- oder Retention-Zahl binden. Eine kanonische Kundenentität schafft Wert vielleicht dadurch, dass sie neun Downstream-Products ermöglicht, von denen keines sie ihr zurechnet. Das ruiniert naive ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Vollständige Definition ansehen →-basierte Priorisierung und zwingt DPMs, über *Option Value* und *Dependency Leverage* nachzudenken, nicht nur über direkte 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 SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → zu hinterfragen, genug Domänenökonomie, um zu wissen, welche Entscheidungen ein Dataset tatsächlich informiert, und genug politisches Kapital, um einem fordernden VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Vollständige Definition ansehen → 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 Product verbessert, formuliert in der Sprache des Konsumenten.
• Die priorisierte Roadmap, also was gebaut wird, was abgelehnt wird, in welcher Reihenfolge.
• Den Interface-Contract, also SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →, Semantik, SLAs und die Change Policy.
• Den Lebenszyklus, von Launch über Iteration bis zur Deprecation.

Sie besitzen *nicht* die Implementierung der PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → (das ist Data Engineering) oder die Storage-Architektur (behandelt in Ihren Fundamentals). Der DPM besitzt das *Außen* des Products, das Versprechen, während Engineering das *Innen* besitzt.

Discovery: das Product im Request finden

Jeder CDO bekommt einen Strom von Requests, die wie Products klingen: „Wir brauchen ein Churn-Dataset." „Marketing will eine einheitliche Kundensicht." Diese als Specs zu behandeln, ist der Weg zum Problem der 15 Varianten 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, angepasst an Daten. Die Frage ist nicht „welche Daten wollen Sie?". Sie ist: „Welche Entscheidung treffen Sie, wie oft, und was kostet es, falsch zu liegen?" Diese Umformulierung leistet drei Dinge: Sie legt offen, ob der Request ein echter wiederkehrender Bedarf ist oder eine einmalige Analyse (die überhaupt kein Product sein sollte), sie leitet die nötige Freshness und Genauigkeit aus der Ökonomie der *Entscheidung* ab statt aus der Wunschliste des Anfragenden, und sie bringt die echten Konsumenten zum Vorschein.

Nehmen Sie einen Request nach „Echtzeit-Bestandsdaten". Discovery zeigt: Die eigentliche Entscheidung ist eine nächtliche Nachbestellung um 2 Uhr. Echtzeit ist teuer und irrelevant; ein verlässlicher Batch-Snapshot um 23 Uhr ist das Product. Sie haben gerade ein Quartal Streaming-Infrastruktur gespart, indem Sie nach der Entscheidung statt nach den Daten gefragt haben.

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

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 einzige Zeile bestimmt das Optimierungsziel des Modells und das SLA. Beachten Sie NOT_in_scope. Die Hälfte von Discovery besteht darin zu entscheiden, was das Product *nicht* sein will. Airbnbs Minerva war unter anderem deshalb erfolgreich, weil es erklärte, nur *zertifizierte* Metriken zu liefern, 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-Priorisierungsframeworks (RICE, weighted scoring) systematisch genau die Products, die am meisten zählen: die fundamentalen Entitäten und Metriken, von denen alles andere abhängt.

Nutzen Sie eine Zwei-Achsen-Perspektive, die der DPM auf jeden Kandidaten anwendet: Decision Leverage (wie viele Entscheidungen mit hohem Einsatz dieses Product berührt, gewichtet nach deren Wert) gegen Cost-to-Serve Reliably (Build plus laufende Wartungslast, inklusive On-Call). Die Falle: Fundamentale Products, etwa eine kanonische Kunden- oder Produktentität, schneiden bei *direktem* Leverage schlecht ab, weil keine einzelne Entscheidung ihnen „gehört", und dennoch erschließen sie Dutzende Downstream-Products. Der DPM muss Dependency Leverage explizit modellieren: Der Score eines Products erbt einen Anteil am Wert alles dessen, was darauf aufgebaut ist.

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

• Platform Products (kanonische Entitäten, der Metrics-Layer, zentrale Feature-Tabellen): als Infrastruktur finanziert, bewertet nach Adoption und Wiederverwendung, nicht nach direktem ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Vollständige Definition ansehen →. Das sind Ihre Assets der Minerva-Klasse.
• Decision Products (ein bestimmtes Churn-Modell, ein Dataset zur Preiselastizität): finanziert nach Entscheidungsökonomie, bewertet daran, ob die Entscheidung besser wurde.
• Exploratory Products (eine neue experimentelle Segmentierung): als Optionen finanziert, zeitlich begrenzt, schnell eingestellt, wenn sie sich nicht bestätigen.

Der wertvollste Priorisierungsschritt eines DPM ist, nicht zu bauen. Jedes Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → zieht eine permanente Wartungssteuer nach sich: SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →-Drift, Upstream-Änderungen, On-Call, Verfall der Dokumentation. Eine Regel, die ich funktionieren gesehen habe: Kein neues Product geht live, bis das Team benannt hat, welche Kapazität es *dauerhaft* verbraucht, 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 Berichten nach oben: Build-Kapazität vs. Run-Kapazität. Wenn Run etwa 60 bis 70 % der Gesamtkapazität des Teams überschreitet, sind Sie keine Product-Organisation mehr, sondern eine Wartungsorganisation, und Innovation ist gestoppt. Diese Kennzahl ist Ihr Frühwarnsignal, dass das Portfolio zu viele Products und zu wenig Deprecation hat. Sie ist auch die Zahl, mit der Sie zu Ihrem CFO gehen, um entweder Headcount oder einen Deprecation-Sprint zu begründen. Die meisten CDOs messen sie nie und sind dann verblüfft, wenn die Velocity zusammenbricht.

Lebenszyklus: die Disziplin von Contracts und Enden

Software-Teams haben vor Jahrzehnten gelernt, dass das Leben eines Products größtenteils *nach* dem Launch stattfindet. Datenteams handeln routinemäßig so, als wäre der Launch die Ziellinie. Der dauerhafteste Beitrag des DPM ist das Management des gesamten Lebenszyklus, besonders der zwei Phasen, die Teams vernachlässigen: der Interface-Contract und die Deprecation.

Der Contract ist das eigentliche Interface des Products. 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 durchsetzbar sein. Hier verdient sich die moderne Praxis des Data Contract ihren Platz. Der DPM besitzt *Semantik und Change Policy* des Contracts; Engineering setzt ihn in der PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → durch. Ein minimaler Contract erklärt das SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →, die semantische Bedeutung jedes Felds, 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 *Product*-Entscheidung, keine technische, denn sie tauscht Stabilität für Konsumenten gegen Ihre Velocity. Ein Platform Product mit 40 Konsumenten verspricht vielleicht 90 Tage Deprecation-Vorlauf und parallel laufende Versionen. Ein Exploratory Product verspricht vielleicht nichts. Der DPM legt das pro Tier bewusst fest.

Versionierung muss echt sein, nicht bloß angestrebt. Wenn sich Semantik ändert, publizieren Sie v2 neben v1, migrieren Konsumenten nach Plan und ziehen erst dann v1 zurück. Das ist operativ teuer, und genau deshalb zählen Priorisierung und Ablehnung: Jedes Product, das Sie ausliefern, ist eine Versionierungsverpflichtung, die Sie eingehen.

Deprecation ist die Phase, die eine Product-Organisation von einer Müllhalde trennt. Die meisten Datenlandschaften bestehen zu 60 % aus verlassenen Tabellen, die niemand zu löschen wagt, weil niemand weiß, wer sie liest. Der DPM fährt Deprecation als gemanagten Prozess: Consumption instrumentieren, Products unterhalb einer Nutzungsschwelle identifizieren, Sunset mit Migrationspfad ankündigen, löschen. Das ist undankbar, und es ist die Hygienemaßnahme mit dem höchsten Leverage in Ihrer gesamten Landschaft, denn jedes zurückgezogene Product gibt Run-Kapazität an die Build-Spalte zurück.

Eine konkrete Betriebskadenz für Ihren DPM: ein vierteljährliches Portfolio Review, das für jedes Product drei Fragen beantwortet: *Nutzt es noch jemand? Erfüllt es seinen Contract? Sollte es befördert, weiter investiert oder eingestellt werden?* Products, 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 Products gefeiert und nicht bestraft wird. Das kulturelle Signal, dass ein DPM, der zehn tote Products deprecatet, genauso wertvoll ist wie einer, der ein neues ausliefert, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen nur Sie als CDO senden.

Die Gesundheit eines Data Products messen

Direkte Nutzung ist notwendig, aber nicht ausreichend. Verfolgen Sie vier Signale pro Product: Adoption (unterschiedliche Konsumenten und ihr Trend), Reliability (Contract-Einhaltung, erreichte Freshness- und Qualitäts-SLAs), Decision Impact (hat sich die Zielentscheidung messbar verbessert, das Schwerste und Wichtigste) und Cost-to-Serve (Compute plus menschliche Wartung). Ein Product mit hoher Adoption und Reliability, aber unbekanntem Decision Impact ist ein Kandidat für eine tiefere Untersuchung, nicht für automatische Verlängerung; es kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnte ein wunderschö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 Lebenszyklus, also das *Außen* des Products. Engineering besitzt das *Innen*. Verwischen Sie das, bekommen Sie einen Meeting-Koordinator, keinen Product Owner.

• Verankern Sie Discovery in der Entscheidung, nicht im Daten-Request. Erzwingen Sie, dass jedes Product Brief die Entscheidung des Konsumenten, ihre Kadenz und die asymmetrischen Kosten des Falschliegens benennt. Diese einzige Disziplin dimensioniert Freshness, Genauigkeit und Scope richtig und beendet Products, die einmalige Analysen hätten sein sollen.

• Priorisieren Sie über drei Tiers mit Blick auf Dependency Leverage. Finanzieren Sie Platform Products als Infrastruktur nach Wiederverwendung, Decision Products nach Entscheidungsökonomie und Exploratory Products als zeitlich begrenzte Optionen. Standard-RICE-Scoring lässt Ihre fundamentalsten Assets verhungern.

• Beobachten Sie das Build/Run-Kapazitätsverhältnis wie eine P&L-Zeile. Überschreitet Run ~60 bis 70 %, innovieren Sie nicht mehr. Das ist Ihr quantitativer Auslöser für Headcount oder einen Deprecation-Sprint und die Zahl, die Sie zum CFO mitbringen.

• Behandeln Sie Deprecation als gleichwertige, gefeierte Aktivität. Führen Sie ein vierteljährliches Portfolio Review, das ungenutzten Products ein Sunset-Datum gibt. Jedes zurückgezogene Product gibt Kapazität zum Bauen zurück, und nur Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen das kulturelle Signal senden, dass das Einstellen toter Products genauso viel wert ist wie das Ausliefern neuer.