+180 XP

Interne Datenplattformen als Produkt

# Interne Datenplattformen als Produkt

2019 machte das Data-Platform-Team von Airbnb eine unangenehme Entdeckung: Es hatte eine schöne, technisch elegante Dateninfrastruktur gebaut, der fast niemand vertraute. Analysten pflegten still und leise ihre eigenen Shadow Pipelines. Produktteams zogen Metriken aus drei verschiedenen Quellen und erhielten drei verschiedene Antworten. Das Plattformteam maß seinen Erfolg in eingelesenen Tabellen und ausgeführten Queries, aber die Menschen, auf die es ankam, die internen Konsumenten, umgingen es. Airbnbs Antwort war, die Plattform nicht als Leitungsnetz zu behandeln, sondern als Produkt mit Nutzern, einem Value Proposition und einem Churn-Problem. Genau diese Umdeutung, später dokumentiert in „Data Quality at Airbnb" und der Arbeit an der Minerva-Metrikebene, ist die Disziplin, um die es in dieser Lektion geht.

Die Falle ist verführerisch, weil sie sich wie Fortschritt anfühlt. Sie liefern ein neues Lakehouse, einen Feature Store, eine Self-Service-BI-Ebene. Die Infrastruktur ist real. Aber Infrastruktur zu liefern ist nicht dasselbe wie Wert zu schaffen, und ein CDO, der beides verwechselt, finanziert eine Plattform, die gebaut wird, in Architektur-Reviews bewundert wird und von den Analysten und Produktmanagern, für die sie gedacht war, aufgegeben wird.

Von der Infrastrukturverantwortung zur Produktverantwortung

Die zentrale Verschiebung besteht darin, wer definiert, was „fertig" heißt. Wenn Sie Infrastruktur verantworten, heißt fertig: Das System läuft, das SLA ist erfüllt, die Pipeline 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 wegnehmen würden.

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

Es ändert, was Sie finanzieren. Infrastruktur-Roadmaps sind nach Komponenten organisiert: „Warehouse migrieren", „Orchestrierung upgraden", „Streaming ergänzen". Produkt-Roadmaps sind nach Nutzeraufgaben organisiert: „Ein Marketing-Analyst soll ein Attributionsmodell bauen kö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 für ein benanntes Nutzersegment einzahlen. Wenn nicht, ist sie Kosten, keine Investition.

Es ändert, wen Sie einstellen. Produktgeführte Plattformen haben Produktmanager, Leute, deren Job es ist, mit internen Nutzern zu sprechen, rigoros 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 ändert Ihr Verhältnis zu den Konsumenten. Infrastrukturverantwortliche bearbeiten Tickets. Produktverantwortliche machen Discovery. Der Unterschied zeigt sich in einer Frage: Wenn ein Team einen neuen Datensatz anfragt, erfüllen Sie die Anfrage, oder fragen Sie, welche Entscheidung das Team treffen will? Die zweite Frage offenbart regelmäßig, dass der angefragte Datensatz die falsche Lösung ist und dass eine kuratierte Metrik oder ein Self-Service-Template zehn Teams statt einem dienen würde.

Es ä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 klar erkennbare Segmente mit deutlich unterschiedlichen Bedürfnissen:

  • Data Engineers und plattformnahe Builder, die Primitive, 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-Zugriff 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.
  • Führungskräfte, die konsumieren und meist nur eine Zahl brauchen, der sie vertrauen.

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

Adoption und Zufriedenheit messen, nicht Output

Hier wird die Umdeutung operativ. Hören Sie auf, Ihren Peers im Leadership Infrastruktur-Output-Metriken zu berichten: eingelesene Tabellen, Uptime, gespeicherte Petabyte. Das sind Health-Metriken 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 hat und seither keine Query ausgeführt hat, ist kein Nutzer. Messen Sie:

  • Weekly und Monthly Active Users pro Segment.
  • Breite: Anteil der infrage kommenden Teams, die onboarded sind.
  • Tiefe: Nutzen sie Kernfunktionen oder nur ein Dashboard?

2. Retention und Stickiness. Die ehrlichste Plattformmetrik ist, ob Leute freiwillig wiederkommen. Cohort-Retention-Kurven, sind die in Q1 onboardeten Analysten in Q3 noch aktiv?, zeigen, ob Sie etwas Wertvolles gebaut oder lediglich verordnet haben. Eine Plattform, die nur überlebt, weil die Nutzung verpflichtend 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 Untermaße 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 Zugangsanfragen und Environment-Setup 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. Aussagekräftiger ist aber die Vertrauensmetrik: Wenn eine Zahl auf Ihrer Plattform erscheint, handeln die Konsumenten danach, oder verifizieren sie sie anderswo nochmal? Die Existenz von Shadow Pipelines und Abstimmungs-Spreadsheets ist ein direktes, messbares Vertrauenssignal. Zählen Sie sie.

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

| Metrik | Segment | Ziel | Trend |

|---|---|---|---|

| MAU / infrage kommende Teams | Analysten | 80 % | ↑ |

| 90-Tage-Retention | Data Scientists | 70 % | ↓ |

| Time-to-First-Insight | Business User | < 3 Tage | flach |

| Trust NPS | Alle | > 30 | ↑ |

| Anzahl Shadow Pipelines | Alle | sinkend | ↓ |

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

Data as a Product - Zhamak Dehghani on Data Mesh Principles

Watch on YouTube

Instrumentieren Sie die Plattform, damit sie diese Metriken liefert

Sie können nicht über Adoption berichten, die Sie nicht messen. Behandeln Sie die Telemetrie der Plattform als Produktanforderung erster Klasse, nicht als Nachgedanken. Loggen Sie Nutzungsereignisse so, wie ein SaaS-Unternehmen seine App instrumentiert, jede Query, jedes Laden eines Dashboards, jedes Modell-Deployment und jeden Datensatzzugriff, verknüpft mit einem Nutzer und einem Team.

yaml
# 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 Cohort Retention, Ihre Time-to-Value-Messung und Ihre Fähigkeit, ein still churnendes Segment zu erkennen. Er lässt Sie außerdem Ihre Power User finden und Ihre verwaisten Assets, die Datensätze, die seit neunzig Tagen niemand angefasst hat und für deren Pflege Sie noch zahlen.

Die Plattform wie ein Produktteam führen

Metriken ohne Arbeitsrhythmus sind nur Dashboards. Die Umdeutung zum Produkt 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 wirksamste Disziplin ist Wahlfreiheit. Wenn interne Teams ihre eigene Pipeline bauen oder eine Punktlösung kaufen *können*, muss Ihre Plattform ihre Nutzung verdienen. Manche CDOs sperren sich dagegen, sie verordnen die Plattform, um Adoption zu garantieren. Aber verordnete Adoption verdeckt genau das Signal, das Sie brauchen. Die gesündeste Haltung: 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 kompensieren, indem Sie es direkt über Interviews und Vertrauensmetriken messen.

Priorisieren Sie mit einer Value-versus-Reach-Brille

Sie werden immer mehr Anfragen als Kapazität haben. Priorisieren Sie, indem Sie jeder Investitionsoption zwei Fragen stellen: Wie viele Nutzer in wie wertvollem Segment entblockt sie (Reach), und wie viel Friktion entfernt sie (Value)? Ein Self-Service-Semantic-Layer, der 200 Business User entblockt, schlägt meist eine maßgeschneiderte Streaming-Pipeline für ein 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 Vertrag, und halten Sie sie ein

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

Dogfooding und Discovery

Setzen Sie Ihre Plattform-PMs einen Tag im Monat zu den Analysten. Beobachten Sie das Onboarding eines neuen Mitarbeiters und messen Sie die Zeit. Die Teams, die großartige interne Plattformen betreiben, kennen die Workflows ihrer Nutzer in schmerzhaftem Detail, sie haben die zwanzig Minuten Wartezeit auf eine Query und die Verwirrung über drei widersprüchliche Metriken selbst erlebt. Discovery ist keine Umfrage; es ist das Beobachten echter Arbeit und das Finden der Friktion.

Wissenscheck

1. Was ist laut Lektion die zentrale Verschiebung beim Übergang davon, eine Plattform als Infrastruktur zu führen, hin dazu, sie als Produkt zu führen?

2. Wie sollte ein Plattformteam in der produktorientierten Sicht entscheiden, ob eine technische Initiative als Investition und nicht als Kosten gilt?

3. Die Lektion beschreibt Airbnbs frühes Problem, bei dem Analysten Shadow Pipelines pflegten und Teams widersprüchliche Metriken erhielten. Welches zugrunde liegende Versagen illustriert das?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die zutreffend beschreiben, wie sich eine produktgeführte Datenplattform von einer infrastrukturgeführten unterscheidet.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Anzeichen dafür, dass eine Datenplattform laut Lektion als Infrastruktur und nicht als Produkt geführt wird.

Wählen Sie alle richtigen Antworten aus.

Die Plattform steuern, ohne die Adoption zu töten

Der subtile Fehlermodus für einen produktorientierten CDO ist das Gegenteil der Infrastrukturfalle: Adoption und Zufriedenheit überoptimieren und dabei die Governance aushöhlen. Eine Plattform, die alle lieben, weil sie alles erlaubt, ist ein Compliance-Vorfall im Wartestand.

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

  • Machen Sie die konforme Option zur Standardoption. Wenn der schnellste Weg zu einer zertifizierten Metrik über den Semantic Layer führt, nutzen die Leute den Semantic Layer und übernehmen automatisch dessen Lineage und Zugriffskontrollen. Friktion steuert Verhalten zuverlässiger als Policy.
  • Zertifizieren Sie Assets sichtbar. Ein „Gold-zertifiziert"-Badge auf einem Datensatz, mit benanntem Owner und veröffentlichtem SLA, bringt für Vertrauen und governed Adoption mehr als ein Governance-Memo. Es erlaubt Ihnen außerdem, in Ihrer Nutzungstelemetrie freigegebene Assets von der experimentellen Wildwuchsmasse 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 Traktion gewinnen. Produkt-Observability und Governance-Observability sind dasselbe Instrument.

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

Wichtigste Erkenntnisse

1. Organisieren Sie die Roadmap nach Nutzeraufgabe, nicht nach Komponente. Jede technische Initiative muss auf eine benannte Aufgabe für ein benanntes internes Segment einzahlen; wenn nicht, ist sie Kosten, keine Investition. Stellen Sie einen Plattform-PM ein, dessen Fehlen ist das sicherste Zeichen, dass Sie Infrastruktur führen, kein Produkt.

2. Ersetzen Sie Output-Metriken durch eine Produkt-Scorecard. Berichten Sie Ihren Leadership-Peers Adoption, Retention, Time-to-Value und Vertrauen, segmentiert nach Nutzertyp. Behalten Sie Uptime und Durchsatz als interne Engineering-Health-Metriken, nicht als Wertmetriken.

3. Instrumentieren Sie die Nutzung der Plattform als Anforderung erster Klasse. Sie können Adoption nicht steuern, die Sie nicht messen; ein Telemetrie-Stream auf Eventebene speist Cohort Retention, Time-to-Value und frühe Churn-Erkennung und dient gleichzeitig als Ihre Governance-Observability.

4. Zählen Sie die Shadow Pipelines und Abstimmungs-Spreadsheets. Sie sind das ehrlichste Maß für das Vertrauen in die Plattform. Sie abzuschaffen, durch veröffentlichte und eingehaltene Datensatz-SLAs, ist eine konkrete, belastbare ROI-Geschichte.

5. Machen Sie den governed Path zum einfachen Path und segmentieren Sie Governance nach Nutzer. Verankern Sie Compliance in der Standard-Produkterfahrung, geben Sie Buildern eine permissive Sandbox und Konsumenten enge Guardrails, und nutzen Sie einen Telemetrie-Stream für Produkt- und Governance-Entscheidungen gleichermaßen.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.