Platform as a Product

Lernziele

Nach dieser Lektion kannst du erklären, was interne Plattformen vom Ticket-Dienstleister unterscheidet und welche Produkt-Artefakte ein Plattform-Team braucht: Roadmap, Release Notes, Support-Tiers, Deprecation-Regeln und interne SLOs. Du kannst eine Priorisierungsentscheidung mit einem Framework wie RICE begründen und im Interview zeigen, dass du Stakeholder-Management nicht für ein Soft-Skill-Anhängsel hältst, sondern für Kernarbeit.

Das Problem: die Ticket-Fabrik

So sieht der Alltag vieler Infrastruktur-Teams aus: Ein Backlog voller Anfragen — „Bitte Namespace anlegen”, „Brauchen Zugriff auf die Registry”, „Könnt ihr das Quota erhöhen?”. Das Team arbeitet hart, die Warteschlange wächst trotzdem, und niemand ist zufrieden: Entwickler warten Tage auf Standardvorgänge, das Infra-Team kommt nie zu struktureller Arbeit, weil das Tagesgeschäft alles frisst.

Das ist kein Fleißproblem, sondern ein Betriebsmodell-Problem. Im Ticket-Modell ist jede Anfrage ein Unikat, das menschliche Arbeitszeit kostet — der Durchsatz skaliert linear mit der Teamgröße. Im Produkt-Modell wird die zehnte gleichartige Anfrage zum Anlass, einen Self-Service zu bauen: Die Investition kostet einmal, der Durchsatz skaliert danach mit der Nachfrage statt mit dem Team. „Platform as a Product” ist die konsequente Umsetzung dieses Gedankens — mit allem, was zu einem Produkt gehört.

Was ein Produkt von einem Dienst unterscheidet

Ein internes Produkt erkennst du an konkreten Artefakten, nicht an Absichtserklärungen:

Eine Person mit Roadmap-Verantwortung. Ob sie Platform Product Manager oder Platform Lead heißt, ist zweitrangig — entscheidend ist, dass jemand Nutzerfeedback einsammelt, Prioritäten gegeneinander abwägt und auch Nein sagt. Ohne diese Rolle priorisiert faktisch, wer am lautesten eskaliert.

Release Notes und Versionierung. Plattform-Änderungen erreichen dutzende Teams gleichzeitig. Wer ein CI-Template ändert, ohne es anzukündigen, produziert an einem Vormittag fünfzig rote Pipelines. Versionierte Capabilities („Golden Path web-api v3”) plus angekündigte Änderungen sind keine Bürokratie, sondern Blast-Radius-Kontrolle.

Support-Tiers. Nicht alles, was technisch möglich ist, wird gleich unterstützt. Ein bewährtes Modell: Der Golden Path ist voll supported (das Plattform-Team hilft bei Problemen), dokumentierte Escape Hatches sind best-effort, und alles jenseits davon ist explizit unsupported. Diese Abstufung schützt das Team davor, für jede Sonderlocke jedes Teams haftbar zu sein.

Deprecation Policy. Produkte haben einen Lebenszyklus. Ohne geregelte Abkündigung — Ankündigungsfrist, Migrationspfad, Enddatum — sammelt die Plattform Altlasten an, bis das Team nur noch Legacy pflegt. Wer „Capability v1” nie abschalten darf, kann „v2” nicht ernsthaft weiterentwickeln.

Priorisieren mit System statt nach Lautstärke

Die Roadmap-Frage im Interview lautet selten „Was würdest du bauen?”, sondern „Wie entscheidest du, was du baust?”. Eine belastbare Antwort hat zwei Teile: Datenquellen und ein Bewertungsraster.

Datenquellen: Developer-Interviews und Office Hours, Auswertung der Support-Anfragen (die Top-10-Tickets sind eine fertige Backlog-Liste), Telemetrie (wo brechen Pipelines ab, wie lange dauert Provisioning) und Umfragen. Wichtig ist die Mischung — Umfragen allein erfassen nur, was Leuten bewusst ist.

Bewertungsraster: RICE ist der bekannteste Ansatz: Reach (wie viele Teams betrifft es), Impact (wie stark), Confidence (wie sicher ist die Einschätzung), Effort (Aufwand). Ein Beispiel macht den Wert sichtbar: Ein lautes Team fordert Multi-Region-Support (Reach: 1 Team, Effort: riesig), während dreißig Teams still unter einer flaky CI leiden (Reach: 30, Effort: moderat). RICE macht offensichtlich, was zuerst dran ist — und gibt dir gegenüber dem lauten Team eine begründbare Absage statt eines Bauchgefühls. Für die Kommunikation nach außen reicht oft ein einfaches Now / Next / Later, sichtbar für alle im Portal.

Daneben braucht die Roadmap einen festen Anteil für Platform Health — Upgrades, Tech Debt, Security. Diese Arbeit hat nie einen lauten Fürsprecher und wird ohne reservierten Anteil immer verdrängt.

Interne SLOs und Error Budgets

Verbindlichkeit ist die Währung, in der Plattformen Vertrauen aufbauen. Wer Self-Service verspricht, muss sagen, wie zuverlässig der Service ist — sonst bauen sich Teams wieder eigene Lösungen, „um sicherzugehen”. Typische interne Service-Ziele:

Service	SLI	Beispiel-Ziel
Plattform-API / Portal	Verfügbarkeit	99,9 %
CI-Strecke	Erfolgsrate (ohne Code-Fehler)	99 %
Environment-Provisioning	Dauer bis nutzbar	< 15 min

Dazu gehört das Error-Budget-Prinzip aus dem SRE-Umfeld: Ist das Budget eines Quartals aufgebraucht, pausiert Feature-Arbeit zugunsten von Stabilisierung. Das diszipliniert in beide Richtungen — das Team verschleppt Stabilität nicht, und Stakeholder verstehen, warum Features warten. Eine ehrliche Einschränkung gehört dazu: Interne SLAs ohne Konsequenzen sind Dekoration. Wirksam werden sie erst, wenn Verstöße sichtbar gemacht und in der Priorisierung berücksichtigt werden.

Praxis: Roadmap und SLO für eine fiktive Plattform

Szenario: Du übernimmst ein Plattform-Team in einer Firma mit 40 Entwicklungsteams. Aus Interviews kennst du fünf Schmerzpunkte: (a) Neues Service-Setup dauert 3 Tage, (b) CI-Pipeline bricht bei ~5 % der Läufe ohne Code-Ursache ab, (c) ein Team will GPU-Workloads, (d) Logs sind über drei Systeme verstreut, (e) Secrets werden per Chat geteilt.

Aufgaben:

1. Bewerte alle fünf Punkte mit RICE (schätze Reach in Teams, Impact 1–3, Confidence in %, Effort in Personenwochen) und sortiere danach.
2. Erstelle daraus ein Now/Next/Later-Board mit je 1–2 Einträgen und einem Satz Begründung pro Eintrag.
3. Formuliere für deinen Now-Eintrag ein SLO im Format „SLI, gemessen als Messmethode, Ziel Wert” — z. B. für (a): „Time-to-First-Deploy, gemessen vom Scaffolding bis zum ersten erfolgreichen Staging-Deploy, Ziel < 1 Tag”.
4. Schreibe die Absage an das GPU-Team (c) in drei Sätzen — freundlich, begründet, mit Verweis auf die Kriterien.

Punkt 4 ist bewusst dabei: Nein sagen mit Begründung ist die am meisten unterschätzte Produkt-Fähigkeit.

Typische Stolperfallen

Feature-Fabrik statt Produkt. Auch ein Produkt-Team kann in den Reaktionsmodus rutschen — es baut dann eben Features statt Tickets auf Zuruf. Der Test: Gibt es dokumentierte Entscheidungen gegen Anfragen?

Roadmap als Geheimwissen. Wenn Teams nicht sehen, was wann kommt, bauen sie Übergangslösungen, die nie wieder verschwinden. Roadmap-Transparenz ist billig und wirkt stark.

SLOs versprechen, die niemand misst. Ein SLO ohne Dashboard und ohne Review-Termin ist ein Marketing-Satz. Erst Messung, dann Versprechen.

Deprecation aufschieben. Jede nicht abgekündigte Alt-Capability bindet dauerhaft Wartungskapazität. Die Migrationskosten der Nutzer verschwinden nicht durch Warten — sie wachsen.

Interview-Vorbereitung

Auf „Was bedeutet Platform as a Product?” antwortest du am stärksten so: Kontrast (Ticket-Modell skaliert mit Teamgröße, Produkt-Modell mit Nachfrage) → Artefakte (Roadmap-Ownership, Release Notes, Support-Tiers, Deprecation) → Priorisierung (Datenquellen plus RICE/Now-Next-Later) → Verbindlichkeit (interne SLOs mit Error Budget).

Rechne mit diesen Follow-ups:

• „Wie priorisierst du, wenn zwei wichtige Teams Gegensätzliches wollen?” — Kriterien offenlegen (Reach, Impact, strategische Deadlines), Entscheidung dokumentieren, Verlierer-Team mit Begründung und Ausblick abholen.
• „Wie verhinderst du, dass die Plattform wieder zum Ticket-System wird?” — Jede wiederkehrende Anfrage als Produktlücke behandeln; Anteil Self-Service-Vorgänge vs. manuelle Vorgänge als Metrik führen.
• „Braucht ein Plattform-Team einen eigenen Product Manager?” — Ab nennenswerter Größe ja; vorher muss die Rolle explizit bei einer Person liegen, sonst priorisiert die Eskalationslautstärke.
• „Welche SLAs würdest du intern anbieten?” — Zwei, drei konkrete nennen (Portal-Verfügbarkeit, Provisioning-Dauer, CI-Erfolgsrate) und das Error-Budget-Prinzip erwähnen.

Zusammenfassung

Platform as a Product heißt: ein Betriebsmodell, in dem wiederkehrende Anfragen zu Self-Service-Capabilities werden, eine Person Roadmap-Verantwortung trägt, Änderungen versioniert und angekündigt werden, Support-Tiers und Deprecation-Regeln gelten und interne SLOs mit Error Budgets Verbindlichkeit schaffen. Priorisiert wird mit Daten und einem Raster wie RICE — transparent genug, dass auch Absagen nachvollziehbar sind.

Welche Teams eine solche Plattform bauen, wer ihre Kunden sind und wie die Zusammenarbeit organisatorisch geschnitten wird, beschreibt die nächste Lektion mit dem Team-Topologies-Modell.