Interne Datenplattformen als Produkt

2019 stellte das Data-Platform-Team von Airbnb etwas Unangenehmes fest: Es hatte eine schöne, technisch elegante Dateninfrastruktur gebaut, der fast niemand vertraute. Analysten pflegten still und leise Schatten-Pipelines. Produktteams zogen Metriken aus drei verschiedenen Quellen und bekamen drei verschiedene Antworten. Das Plattformteam mamaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ß Erfolg in eingelesenen Tabellen und beantworteten Queries, aber die Leute, auf die es ankam, die internen Konsumenten, gingen an ihm vorbei. Airbnbs Antwort bestand darin, die Plattform nicht als Leitungsnetz zu behandeln, sondern als Produkt mit Nutzern, einem Value Proposition und einem Churn-Problem. Diese Neurahmung, später festgehalten in „Data QualityData QualityDer Grad, in dem Daten für ihren Zweck geeignet sind: korrekt, vollständig, konsistent, aktuell, valide und eindeutig. Schlechte Datenqualität untergräbt Analytics, Reporting und KI.Vollständige Definition ansehen → at Airbnb" und der Arbeit an der Metrik-Ebene Minerva, ist die Disziplin, um die es in dieser Lektion geht.

Die Falle ist verführerisch, weil sie sich nach Fortschritt anfühlt. Sie liefern ein neues LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen →, einen Feature StoreFeature StoreEin zentrales Repository zur Verwaltung von ML-Features, das Konsistenz zwischen Training und Serving sicherstellt.Vollständige Definition ansehen →, eine Self-Service-BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Schicht. Die Infrastruktur ist real. Aber Infrastruktur auszuliefern ist nicht dasselbe wie Wert zu schaffen, und ein CDO, der beides verwechselt, finanziert eine Plattform, die gebaut, in Architektur-Reviews bewundert und von den Analysten und Produktmanagern, denen sie dienen sollte, verlassen wird.

Vom Infrastruktur-Owner zum Product Owner

Die zentrale Verschiebung betrifft die Frage, wer „fertig" definiert. Wenn Sie Infrastruktur verantworten, heißt fertig: das System läuft, das SLASLAFormale Zusage, die das von einem Anbieter garantierte Serviceniveau definiert, mit messbaren Zielen und Konsequenzen bei Nichteinhaltung.Vollständige Definition ansehen → ist erfüllt, die PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → ist durchgelaufen. Wenn Sie ein Produkt verantworten, heißt fertig: ein interner Kunde hat eine Aufgabe schneller oder besser erledigt als vorher und wäre verärgert, wenn Sie ihm das Tool wegnähmen.

Das ist keine semantische Aufhübschung derselben Arbeit. Es verändert vier konkrete Dinge daran, wie Sie das Plattformteam führen.

Es verändert, was Sie finanzieren. Infrastruktur-Roadmaps sind nach Komponenten geordnet: „Warehouse migrieren", „Orchestrierung upgraden", „Streaming ergänzen". Produkt-Roadmaps sind nach Nutzeraufgaben geordnet: „Ein Marketing-Analyst soll ein Attributionsmodell bauen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, ohne ein Ticket zu eröffnen", „Ein Data Scientist soll ein Feature an einem Tag in Produktion bringen können, nicht in einem Sprint". Jede technische Initiative muss auf eine benannte Aufgabe eines benannten Nutzersegments einzahlen. Tut sie das nicht, ist sie Kosten, keine Investition.

Es verändert, wen Sie einstellen. Produktgeführte Plattformen haben Produktmanager, also Leute, deren Job es ist, mit internen Nutzern zu sprechen, rücksichtslos zu priorisieren und Nein zu sagen. Das Fehlen eines Data-Platform-PM ist der zuverlässigste Indikator dafür, dass eine Plattform als Infrastruktur geführt wird. Engineers optimieren auf den eleganten allgemeinen Fall; PMs optimieren auf die konkrete Aufgabe, die die wertvollsten Nutzer entblockt.

Es verändert Ihr Verhältnis zu den Konsumenten. Infrastruktur-Owner bearbeiten Tickets. Product Owner betreiben Discovery. Der Unterschied zeigt sich in einer Frage: Wenn ein Team ein neues Dataset anfragt, erfüllen Sie den Request, oder fragen Sie, welche Entscheidung das Team treffen will? Die zweite Frage bringt regelmäßig zutage, dass das angefragte Dataset die falsche Lösung ist und dass eine kuratierte Metrik oder ein Self-Service-Template zehn Teams statt einem dienen würde.

Es verändert, wie Sie sich selbst messen, und das ist der Kern dieser Lektion.

Segmentieren Sie Ihre internen Kunden

Sie würden nie ein externes Produkt für „alle" bauen. Bauen Sie Ihre interne Plattform nicht für „das Business". Ihre Nutzer gruppieren sich in erkennbare Segmente mit deutlich unterschiedlichen Bedürfnissen:

• Data Engineers und plattformnahe Builder, die Primitives, APIs und Kontrolle brauchen.
• Analysten und Analytics Engineers, die kuratierte, vertrauenswürdige Tabellen und einen Semantic Layer brauchen, keine Rohlogs.
• Data Scientists, die reproduzierbare Umgebungen, Feature-Zugang und einen schnellen Weg in die Produktion brauchen.
• Business Power User (Ops-Manager, Marketer, Finance), die governed Self-Service brauchen, Dashboards und Metriken, die sie ohne SQL slicen können.
• Executives, die konsumieren und meist eine Zahl brauchen, der sie vertrauen.

Jedes Segment hat eine andere Definition eines guten Tages. Die Plattform-Builder mit mehr Primitives zu bedienen, während die Business Power User bei governed Self-Service hungern, ist eine häufige und teure Fehlallokation, es fühlt sich nach tiefer technischer Arbeit an, während die größte Nutzergruppe zu Spreadsheets churnt.

Adoption und Zufriedenheit messen, nicht Output

Hier wird die Neurahmung operativ. Hören Sie auf, Ihren Peers in der Führung Infrastruktur-Output-Metriken zu berichten, eingelesene Tabellen, Uptime, gespeicherte Petabytes. Das sind Gesundheitsmetriken für Ihre Engineers, keine Wertmetriken für das Business. Berichten Sie eine Produkt-Scorecard.

Die vier Metrikfamilien

1. Adoption. Wer nutzt die Plattform tatsächlich, und kommen diese Leute wieder? Übernehmen Sie die SaaS-Unterscheidung zwischen registrierten und aktiven Nutzern. Ein Team, das sich vor sechs Monaten Zugang eingerichtet und seither keine Query laufen lassen hat, ist kein Nutzer. Tracken Sie:

• Wöchentlich und monatlich aktive Nutzer je Segment.
• Breite: Anteil der berechtigten Teams, die onboarded sind.
• Tiefe: Nutzen sie Kernfunktionen oder nur ein Dashboard?

2. Retention und Stickiness. Die ehrlichste Plattformmetrik ist, ob Leute freiwillig wiederkommen. Kohorten-Retentionskurven, sind die in Q1 onboardeten Analysten in Q3 noch aktiv?, zeigen, ob Sie etwas Wertvolles gebaut oder es lediglich verordnet haben. Eine Plattform, die nur überlebt, weil ihre Nutzung Pflicht ist, hat ein Zufriedenheitsproblem, das sie versteckt.

3. Time-to-Value. Wie lange dauert es von „ein Team will eine Frage beantworten" bis „es hat eine vertrauenswürdige Antwort"? Das ist die zentrale Durchsatzmetrik Ihrer Plattform. Zwei Teilgrößen sind enorm wichtig:

• Time-to-First-Insight für einen neuen Nutzer (Onboarding-Friktion).
• Time-to-Production für ein neues Datenprodukt oder Modell (Delivery-Friktion).

Wenn das Onboarding eines neuen Analysten drei Wochen Zugriffsanträge und Umgebungseinrichtung kostet, wird Ihre Adoption-Obergrenze von dieser Friktion bestimmt, nicht von Ihren Fähigkeiten.

4. Zufriedenheit und Vertrauen. Erheben Sie einen internen NPS oder CSAT zur Plattform, segmentiert nach Nutzertyp. Aufschlussreicher ist aber die Vertrauensmetrik: Wenn eine Zahl auf Ihrer Plattform erscheint, handeln die Konsumenten danach, oder verifizieren sie sie woanders erneut? Die Existenz von Schatten-Pipelines und Abstimmungs-Spreadsheets ist ein direktes, messbares Vertrauenssignal. Zählen Sie sie.

Eine nützliche Synthese ist eine einzige quartalsweise Platform Product Scorecard, die Sie neben dem Infrastruktur-Health-Dashboard präsentieren:

Die sinkende Retention bei den Data Scientists in diesem Beispiel ist genau die Art von Signal, das ein reines Output-Dashboard nie sichtbar machen würde, und genau dorthin sollte ein CDO die Investition des nächsten Quartals lenken.

Instrumentieren Sie die Plattform so, dass sie diese Metriken erzeugt

Sie können keine Adoption berichten, die Sie nicht messen. Behandeln Sie die Telemetrie der Plattform als erstklassige Produktanforderung, nicht als Nachgedanken. Loggen Sie Nutzungsereignisse so, wie ein SaaS-Unternehmen seine App instrumentiert, jede Query, jedes Dashboard-Laden, jedes Model-Deployment und jeden Dataset-Zugriff, verknüpft mit einem Nutzer und einem Team.

# Platform usage event schema — emitted on every meaningful interaction
event:
  user_id: analyst_4471
  team: growth-marketing
  segment: business_power_user
  action: dashboard_view      # query_run | model_deploy | dataset_access
  asset_id: attribution_v3
  latency_ms: 820
  success: true
  timestamp: 2024-11-04T14:22:00Z

Dieser Event-Stream speist Ihre Kohorten-Retention, Ihre Time-to-Value-Messung und Ihre Fähigkeit, ein leise churnendes Segment zu erkennen. Er lässt Sie außerdem Ihre Power User finden und Ihre verwaisten Assets, die Datasets, die seit neunzig Tagen niemand angefasst hat und deren Pflege Sie weiter bezahlen.

Die Plattform wie ein Produktteam führen

Metriken ohne operativen Rhythmus sind nur Dashboards. Die Produkt-Neurahmung muss verändern, wie das Team Woche für Woche tatsächlich arbeitet.

Behandeln Sie interne Teams als Kunden, die Sie verlieren können

Die stärkste Disziplin ist Wahlfreiheit. Wenn interne Teams ihre eigene Pipeline bauen oder eine Punktlösung kaufen *können*, muss sich Ihre Plattform ihre Nutzung verdienen. Manche CDOs sträuben sich dagegen, sie verordnen die Plattform, um Adoption zu garantieren. Aber verordnete Adoption verdeckt genau das Signal, das Sie brauchen. Die gesündeste Haltung lautet: Die Plattform sollte so offensichtlich besser sein, dass Teams sie wählen. Wo Sie verordnen (meist aus Governance- oder Compliance-Gründen), erkennen Sie an, dass Sie das Zufriedenheitssignal unterdrückt haben, und gleichen das aus, indem Sie es direkt über Interviews und Vertrauensmetriken messen.

Priorisieren Sie mit einer Value-versus-Reach-Brille

Sie werden immer mehr Requests als Kapazität haben. Priorisieren Sie, indem Sie jede Investitionskandidatin zwei Dinge fragen: Wie viele Nutzer in wie wertvollem Segment entblockt das (reach), und wie viel Friktion nimmt es weg (value)? Ein Self-Service-Semantic-Layer, der 200 Business User entblockt, schlägt meist eine maßgeschneiderte Streaming-Pipeline für ein einzelnes statushohes Team, auch wenn das Streaming-Projekt technisch interessanter ist. Der Job des PM ist es, diese Disziplin gegen die Anziehungskraft des lautesten internen Stakeholders zu verteidigen.

Veröffentlichen Sie SLAs und einen Kontrakt, und halten Sie sie ein

Externe Produkte machen Versprechen. Ihres sollte das auch. Veröffentlichen Sie Daten-SLAs (Aktualität, Verfügbarkeit, Qualitätsschwellen) je kritischem Dataset und behandeln Sie einen Bruch als Incident mit Postmortem. Das verwandelt Vertrauen von einer Hoffnung in eine Selbstverständlichkeit. Ein Finance-Team, das weiß, dass die Revenue-Tabelle garantiert um 6 Uhr aktuell ist, mit 99,5% Zuverlässigkeit, hört auf, sein Abstimmungs-Spreadsheet zu pflegen. Dieses aufgegebene Spreadsheet ist Ihr ROI.

Dogfooding und Discovery

Setzen Sie Ihre Plattform-PMs einen Tag im Monat zu den Analysten. Beobachten Sie, wie ein neuer Mitarbeiter onboardet, und stoppen Sie die Zeit. Die Teams, die großartige interne Plattformen betreiben, kennen die Workflows ihrer Nutzer bis ins Körperliche, sie haben die zwanzig Minuten Wartezeit auf eine Query und die Verwirrung durch drei widersprüchliche Metriken selbst gespürt. Discovery ist keine Umfrage; es ist das Beobachten echter Arbeit und das Finden der Friktion.

Die Plattform steuern, ohne Adoption zu töten

Der subtile Fehlermodus für einen produktorientierten CDO ist das Gegenteil der Infrastrukturfalle: Überoptimierung auf Adoption und Zufriedenheit bei gleichzeitiger Erosion der Governance. Eine Plattform, die alle lieben, weil sie ihnen alles erlaubt, ist ein Compliance-Vorfall im Wartestand.

Die Auflösung besteht darin, den governed Pfad zum einfachen Pfad zu machen. Governance sollte in die Produkterfahrung eingebettet sein, nicht als Schranke davorgesetzt. Konkret:

• Machen Sie die konforme Option zur Default-Option. Wenn der schnellste Weg zu einer zertifizierten Metrik über den Semantic Layer führt, nutzen die Leute den Semantic Layer und erben automatisch dessen Lineage und Zugriffskontrollen. Friktion steuert Verhalten zuverlässiger als Policy.
• Zertifizieren Sie Assets sichtbar. Ein „Gold-zertifiziert"-Badge an einem Dataset, mit benanntem Owner und veröffentlichtem SLA, tut mehr für Vertrauen und governed Adoption als ein Governance-Memo. Es erlaubt Ihnen außerdem, in Ihrer Nutzungstelemetrie freigegebene Assets vom experimentellen Wildwuchs zu unterscheiden.
• Nutzen Sie dieselbe Telemetrie für Governance und Produkt. Der Event-Stream, der Ihnen Adoption zeigt, zeigt Ihnen auch Zugriffsmuster, wer sensible Daten anfasst, welche nicht zertifizierten Assets unautorisiert an Zugkraft gewinnen. Produkt-Observability und Governance-Observability sind dasselbe Instrument.

Die Ermessensfrage für den CDO ist die Kalibrierung des Trade-offs je Segment. Data Scientists brauchen eine permissive Sandbox; Business Power User brauchen Leitplanken, die so eng sind, dass sie nicht versehentlich eine falsche Zahl an den CEO publizieren. One-size-Governance erdrosselt entweder die Builder oder gefährdet die Konsumenten. Segmentieren Sie Ihre Governance so, wie Sie Ihr Produkt segmentieren.

Key Takeaways

1. Ordnen Sie die Roadmap nach Nutzeraufgaben, nicht nach Komponenten. Jede technische Initiative muss auf eine benannte Aufgabe eines benannten internen Segments einzahlen; tut sie das nicht, ist sie Kosten, keine Investition. Stellen Sie einen Plattform-PM ein, dessen Fehlen ist das sicherste Zeichen dafür, dass Sie Infrastruktur betreiben, kein Produkt.

1. Ersetzen Sie Output-Metriken durch eine Produkt-Scorecard. Berichten Sie Ihren Peers in der Führung Adoption, Retention, Time-to-Value und Vertrauen, segmentiert nach Nutzertyp. Behalten Sie Uptime und Durchsatz als interne Engineering-Gesundheitsmetriken, nicht als Wertmetriken.

1. Machen Sie die Instrumentierung der Plattformnutzung zur erstklassigen Anforderung. Sie können keine Adoption steuern, die Sie nicht messen; ein Event-Telemetrie-Stream speist Kohorten-Retention, Time-to-Value und frühe Churn-Erkennung und dient zugleich als Ihre Governance-Observability.

1. Zählen Sie die Schatten-Pipelines und Abstimmungs-Spreadsheets. Sie sind das ehrlichste Maß für Plattformvertrauen. Sie abzuschaffen, indem Sie Dataset-SLAs veröffentlichen und einhalten, ist eine konkrete, belastbare ROI-Story.

1. Machen Sie den governed Pfad zum einfachen Pfad und segmentieren Sie Governance nach Nutzer. Betten Sie Compliance in die Default-Produkterfahrung ein, geben Sie Buildern eine permissive Sandbox und Konsumenten enge Leitplanken, und nutzen Sie einen Telemetrie-Stream für Produkt- wie Governance-Entscheidungen.